没有统计数据就是耍流氓：为什么开发人员要强调统计和定量
发表于2016-08-09
在技术开发、个人发展上，是不是强调统计和定量，对工作结果会有非常重要的区别，会带来完全不同的结果。
可惜，我们是一个不喜欢太精确的民族。
在黄仁宇先生的《万历十五年》中，有一个很著名的历史论断，就是中国并不是一个依靠精确数字管理的国家，历史上一直不强调数字和精确，这是为什么近代工业科技革命都没有起源在中国的重要原因。
在万维钢的《万万没想到～用理工思维看世界》中也提到，欧美人从小习惯用数字来说明问题，不像我们用模糊的观念来论述观点。
虽然我不会做菜，但中餐菜谱也是见到过的，通篇写着盐少许，糖适量，更多需要依赖厨师的经验来决定用量。
不精确带来了很多负面问题。 比如在游戏开发优化的领域中，数据无法量化，就无法测试改进程度，不利于进一步改善。看看具体的例子：
由于工作关系，我经常需要面试很多技术候选人。在面试的时候，一个很常聊的话题，就是优化。这是一个比较容易鉴别出知识深度的课题，至少在常见的编程从入门到精通一类的傻瓜书中就不会提到优化的话题，不容易提前准备。另外，做优化的能力，也可以很好的辨别出候选人钻研的能力，解决问题的思路，因为每一个优化问题，往往都是很独特的案例，可以用不同的思路解决同类问题，也可以在同类问题中用不同的思路处理。聊得深入就追问一番，聊得悻悻就转换话题，对于面试官，这是进可攻退可守的高级话题。
性能优化有一个很重要的判断依据，就是性能提升幅度。非常遗憾，相当多的候选者，其实并没有在游戏中建立过一个性能测量体系，根本不知道自己的优化能带来多大的性能提升；还有一部分候选者，只用一个非常粗略的数据，比如做完这个优化，帧数从多少变提高到多少。在我看来这两者都是相当初步阶段的优化，很多小幅度优化根本无法在帧数上直接反映出来。如果放弃这些微小的优化，只关注那些所谓的low hanging fruits（就是比较好处理的性能问题），这当然也是优化，但程度一般不会太深。
仅仅通过数据一个纬度，就可以把技术人员能力做一个初步区分。没有数据支撑，你的优化质量是无法评估，你的自我吹嘘也无法证伪，和迷信无异。
合理的优化，应该是有完善的测试体系。能测多细就测多细，每一次优化有没有改进，是不是性能出现了回归，需要有尽可能完善的统计数据来支撑，而不能凭感觉靠猜想。
当建立了这样完善的体系后，你就会对更细致的优化有了信心，有了深入下去的动力，会追查性能里面的微小优化点。这些细小的优化，即使不能对帧数产生任何影响，但你知道，它就在那里，发挥着作用，日积月累，当有更多的优化，就会共同对游戏性能产生良性的作用。
无法量化的另一个问题是知识无法显式传承，也无法高效沟通，依赖说不清道不明的定性结论，无法令人信服。比如你去面试，和HR谈工资，你能说，我要少许工资吗？还是报一个具体数字，或者给个百分比更合适吧？再举个专业方面的例子：
一个优化，带来了一定的副作用，你如何衡量它的影响呢？一个优化的渲染算法，会有性能提升，这个比较容易想到，也容易测量；但往往优化算法会带来画质损失，这一点就没有太多人关注了。简单表示没有什么影响，并不足以服众。严谨的做法，是定义画质，和原算法在同样的条件下做逐像素比较，不那么严谨--但也远远好于不做任何事的做法，是找相关美术同事，仔细看对比图，判断对画质影响。
有了这样的比较，就可以理直气壮和其他团队表示，画面效果没有可识别损失，和原画面差别低于5%，主美术表示肉眼无可识别差异。上可安抚制作人，下可嘲讽小伙伴，这样的论据，说服力会远远大于个人的主观判断。
不仅仅是技术，其实策划、美术领域也是可以度量的，不轻易相信直觉，不随便迁就喜好，我们该真正从用户角度出发，做调研，阅读报告，分析数据，找到合适的策划方向和美术方向。作为一个程序员，就不多在自己的客场多BB了，请策划美术同学自己补充。
在生活中，自我量化，数据说话也是一个好习惯。
我曾经从全拼切换到双拼输入法，双拼是有一些学习成本，所以我需要数据来证明，切换过去是值得的。毫无疑问，作为一个对自己负责任的Geek，我要定量统计。
我先查了很多网络数据，看见平均击键数字上面，全拼平均是3.x，但双拼只有2，所以理论上会更快。
然后找了段范文，测试了一下自己的全拼输入速度，记录下来。
努力切换到双拼，虽然开始很痛苦，但咬牙坚持。
切换的前几周，每周都测试同一段范文，统计自己的输入速度。这有两个目的，一方面给自己切换输入法的动力，告诉自己输入速度提高了，另一方面也想验证我是否能达到理论上的输入速度上限。
在1个多月后，输入速度和全拼基本一样了，然后缓慢超过了全拼，最后稳定在一个程度再也无法提高。
这是我的一些统计数字,可以看出，有了量化，我可以看自己的速度提升，可以看在手机上输入的效率，可以看mac上输入效率，可以看机械键盘对我的输入有没有帮助，可以写文章引用自己的数据，然后为自己微不足道的进步沾沾自喜。
2009/10/13, 全拼，4:30
2009/10/20, 8:00
2009/10/29, 6:30
2009/11/17, 5:07
2010/1/20, 4:15
2010/10/23, 3:50
2010/3/31, 3:45
2010/4/30 3:45
2010/8/15 3:45
2011/3/11 3:31
2012/12/6 3:35
2013/6/22 3:35
2013/6/22: Note2, 6:50
2015/5/14: iPhone6，5:16
2016/4/30: mac, with filco keyboard, 3:11
那如何在工作中做到数字说话呢？我们还是以游戏开发中的优化来举例子：
１、开发中要建立测试框架。
所有需要对比的事情，都需要有测试框架。包括内存、显存、CPU开销、GPU开销，也包括接入各种第三方测试工具，各种profiler工具，能接上全接上。
２、工作中不停收集数据，尽量保留数据上下文，越完整越好。
比如测试工具输出的原始Log文件，临时的分析结果，截图和视频。如果能保留相应游戏版本则更好（不过考虑到现在游戏的规模，一般不可能），或者记下相应的changelist号码。上下文，是为了让你今后总结的时候可以快速的回顾，可以方便的补漏，可以从别的角度观察和总结当时的优化，可以很好的总结输出报告。如果没有保留上下文，无法恢复当时的环境，那么一旦事后发现缺乏一些数据，就很悲催了。
３、事后总结，输出邮件和分享。
相信一份详细的汇报，无论是对你将来的技术发展，还是对向leader汇报工作，都是很有好处的。
当然，要知道怎么做好数据统计，还是需要一定的眼界和深入的思考。多看看别人项目是怎么统计的，别的游戏引擎提供点什么数据，别的测试工具给出什么统计指标，然后结合自己的游戏，想想怎么让这些好东西为我所用。信息时代，没有孤岛，关起门来空想，不容易有突破。
如果实在找不到量化的方法，那就继续去努力找吧，成功没有捷径。