我们的研发哲学
郑昀 创建于2015/2/27 最后更新于2015/3/25
关键词： 哲学、规则、套路、传承
本文档适用人员：广义的技术人员
提纲：
- Don't make me think
- If it hurts, do it more and often
- 这个世界从来没有什么救世主
- 没有苦劳，只有功劳
一，Don't make me think
大家都知道，技术人员从事的是创造性工作，加之是单核处理器，我们的上下文切换非常困难，被打断后从新进入“神游”状态往往需要十几分钟。尤其是研发经理，承担更多的责任，线上线下的问题都要照顾到，还要解答内外的各种咨询，工作时间碎片化严重。我们（包括系统）给出的信息，一定要足够简练，一目了然，让人很容易克服焦躁情绪，啪啪地就处理了，或者啪啪地二次分发出去。 不要用无用的信息折磨这些人。
其次，技术人员是“世界”的构建者，不得不做大量琐碎且枯燥的工作，其中，相当大比例的工作是重复性的，如修改配置文件适配不同环境，如打包。
重复的工作一方面容易出错，尤其是在通宵上线时，另一方面消磨人的耐心和斗志。 我在《职场培训第五期：职场的真相》中讲过解题思路：『要摒弃单纯依靠员工之间互相提醒、依靠个人认真细致来规避相同错误的固有思路，铁打营盘流水兵，靠人终归是靠不住的，最好靠遵循规则的机器』。
王淮在《以 Facebook 为案例剖析科技公司应有的工具文化》一文中谈及，基本理念就是凡是被很多人不断重复的好习惯，要将其自动化，绑定到工具之中，以"Don't make me think"的方式来推广最佳实践（best practice）。
基于以上原因，我们认为，凡是被不断重复的过程，将其工具化，绑定到自动化流程之中，减少不必要的心智负担。
这也就是过去几年里我们一季季地推进持续集成（Continuous Integration，CI）的原因，把我们的经验教训变成可重复的规则，融入工具中，融入自动化流程中，而不是一代一代口口相传。
好了，在举具体的例子之前，让我们大声读出这几条 Slogan：
- Don't make me think!
- 减少不必要的心智负担！
实例一：
Exception 日志分析邮件是我们非常重要的工具，是我们的宝贵财富。每天凌晨 Python 脚本定时分析各个工程的 Exception 日志，按异常类型归类，用邮件 Push 到研发经理桌面上，它充分体现了我们的哲学： 自动化是王道。
但如果看到邮件内容后，研发经理仍需要费一番功夫才能搞明白这是什么异常，而我们往往没有足够的时间，我们就会嫌麻烦，就会下意识地放过这个 Exception，甚至不再看日志分析邮件和报警邮件，那么“Exception 日清日结”就会沦为一句空话，等攒到每天数以千计 Exception 时已经失去了清理的欲望。
我们都知道，电商的购买流程每增加一个交互环节，就多了一道门槛，用户最终成单转化率=流量入口UV数×步骤1转化率×步骤2转化率×步骤三转化率×……，同样道理，我们要尽量把条理清晰、一目了然的报警邮件和 Exception 日志分析邮件推到大家面前， 操作越少越好，我是在帮你，不是给你找麻烦。
实例二：
Yahoo! 的 Combo Handler 的出现就符合本哲学，阿里还因此出了一款插件 nginx_concat_module。前端工程师可以发布便于阅读的原版 JavaScript 和 CSS 文件，只要模板文件里做一个特殊声明，多个文件就能通过服务器端的插件合并且压缩，配好之后从此不需要再考虑 Minimize HTTP Requests、压缩和混淆了。
实例三：
页面上所引用的 CSS 背景图片可能需要做到 CSS Sprite 图里，然后在 CSS 里写偏移量，每增加一个 CSS 背景图片，这些操作都要来一遍。
也许这是不必要的心智负担，因为机器可以自动做。假如我们引入 Gulp，就可以自顾自地在指定 folder 里放一张张 CSS 背景图片，CSS 里写好声明，然后让 Gulp 这个前端构建工具自己把 folder 下的背景图片合并为一张大的 CSS Sprite 图片，并且它自己修改 CSS 里的背景图片地址和偏移量声明，不需要为此每次费心费力。
二，If it hurts, do it more and often
我们不能死于听天由命和漫不经心。
工程师为什么会听天由命？
- 因为线上日志里的异常实在是太多了，处理不过来。
- 因为异常太多了，淹没了致命异常，以至于服务挂得死死的才发现问题已经存在N久了。
- 因为明天就要提测了，代码合并冲突还有几千个。
- 每到常规版本提测时就心里打鼓，合并个代码都得预留两天时间。
- 因为画时序图好烦，所以复杂系统的数据流转靠“心算”、靠文字描述。
- 人脑容易有思维死角，一个考虑不到，系统就防不住并发提交和重复提交。
- ……
因为已然集腋成裘，所以做事前我们各种纠结和抵触，于是找各种理由拖延。
怎么办？
我在《职业化的7个细节》里讲到， 如果一件事做起来很烦，那就把它拆成很多块儿，每天做一点，每次做一点。
实例一：
以代码合并为例，如果每天早上到公司后，从开发主线合到自己的私有分支上，每天都做，那么等你向测试分支提测时，合并冲突是不是就少很多？
实例二：
如果你觉得画时序图（或泳道图）麻烦，要么是你不会用 visio，要么是你想不清楚调用时序。你应该立即从手头的功能开始画时序图，多练习，以后画时序图、业务流程图只是分分钟的事儿。用 excel 也能做泳道图啊。
很多工程师觉得写设计文档好烦，不开设计评审会的话就不写。我是这么做的：
- 我动手做一个系统，肯定已经大致想清楚了对象的定义、大致的设计模式；
- 也就有了一大堆的类文件（空的）以及目录结构；
- 每个类文件我都先写类功能定义、处理流程、数据类型定义，blabla 一大堆注释。反正写代码之前也得想明白这些事儿，那就直接写成注释；
- 最后，把这些注释摘出来，配上各种图，一篇设计文档就搞定了。
所以我从来不会为写概要设计和详细设计烦心。
三，这个世界从来没有什么救世主
这个哲学我过去几年里一而再再而三地讲。在《职业培训第五期：职场的真相》中，我说：
过去几年里，我们深深地体会到，从来就没有什么救世主，要创造人类的幸福全靠我们自己，不要指望有什么人能救我们，只能绞尽脑汁闯阵。
为什么？
技术团队是互联网公司里最认真最专业最实操最靠谱的一群人，如果我们凡事都要指望别人给我们解决方案和思路，指望别人比我们更认真，那这个公司就危在旦夕了。
所以，我在2012年的飞行研讨会上抛出两个 Slogan：
- 抛掉幻想，勇敢面对！
- 直面白刃战！
实例一：
飞行研讨会上我说：
遇到问题，立刻跟进去Debug
——主管不能仅仅说一些似是而非的官话套话
——主管要投入白刃战
————我党向来是副职打仗下到主攻第一线
————纵队副司令到主攻师，副连长打仗带尖刀排
——围观不能救中国
主管都不出手，指望工程师救你啊？
实例二：
对历史因果关系、系统调用、业务逻辑和数据流转，甚至系统里的脏数据，最了解的人莫过于我们。怎么可能指望上游部门有一个人横空出世，洞悉所有细节，告诉我们该如何设计和实施呢？
是你的终归是你的，躲不过去的。
基于这个哲学，我们衍生出两个 Slogan：
- 不要等死！
- 向前迈半步对接！
四，没有苦劳，只有功劳
早年间，侯小强曾经说过： 如果你在职场，需要有三个好习惯，1，能马上做的事情马上做。2，每个事情要有始有终。3，要有这个习惯思维，没有苦劳，只有功劳。但如果没有极其努力，通常也不会有功劳。
延续着这个思维，我们过去几年里反复强调：没有结果就没有意义。不要期望公司因为你和小伙伴们有苦劳而宽容你们没有产出，这是一个商业公司。
实例一：
一些内部研发课题，由于不像主站那样直面消费者的压力，所以工程师会做得比较粗糙。就算功能 okay 了，但总缺少一股精细范儿， 让我们这些老手浑身难受，迟迟不能投入商业应用。这就属于典型的“没有结果”，没有在指定时间到达指定战场。
实例二：
以下几个征兆会被我判定为“只有苦劳，没有功劳”：
- 如果没有结合前面几个哲学，没有定期审视自己的工作，没有找出痛点并用工具解决痛点，而是低水平重复再重复。累是很累，加班也加了。
- 同样的错误一而再再而三地犯，技术团队因此忙于四处救火，料理脏数据。
以上就是窝窝这四年来总结的研发哲学。我认为，我们团队应该把这些理念结结实实地变成新老员工的“本能”，用哲学来指导我们的行事方式，保证不管我们换了多少人，始终能前后一致。对现代中国曾经有一个说法“每隔十年乱一次”，Why？大抵是十年后掌权的那帮人，不记得十年前发生过什么，传承都丢了，踌躇满志，满怀热情再错一遍。
-over-
职业培训系列：
第一次培训：2013年，职业化包含的六个行为模式
第二次培训：2013年，职业化的七个细节
第三次培训：2013年，大项目爆浆处理模式
第四次培训：2013年，职场(潜)规则
第五次培训：2014年，职场的真相
……
第十次培训：2015年，窝窝研发哲学
