人人都在说工程师文化，90%的同学们向往工程师文化，然而95%的同学们觉得自己的部门没有工程师文化。但关于工程师文化，事实告诉我们两件事：

事实1是：我们定义工程师文化的标准不一样。这就跟美女一样，每个人心中的美女都不一样, 但我们都爱美女。
事实2是：工程师文化还是可以客观感觉出来的。如果你真是个美女，大家还是都会认为你漂亮的。标准再不一样，敢说奥黛丽赫本丑的人还是需要莫大并且不要脸的勇气。

基于这个不恰当的比喻以及事实1得出：90%同学们都爱美女；基于这个不恰当的比喻以及事实2得出：95%同学们部门真的都没有美女！

基于以上事实我们做一个假设：如果同学们部门里都是美女，大家一定都很开心！

基于这个假设得到事实3：都是美女的部门业绩肯定完蛋了（这个推导过程只可意会不可言传）。

根据以上一个假设和三个事实，我们得到结论：一个部门要有美女，但不能多！极端的工程师文化产生少数几个极端成功的公司以及大多数死得很惨的公司。

工程师文化 vs KPI文化

工程师文化是由内而外的引导和自然发生， KPI文化是由外而内的信仰和强行注入。
工程师文化着眼未来， KPI文化活在当下。

工程师文化痛恨KPI，我不爱的我不做，我爱的我疯狂。 KPI文化唯KPI说话，爱不爱都要像战士一样完成。

浅谈工程师文化

工程师文化的前提条件

信任：leader和产品对工程师绝对的信任是工程师文化的最基本条件。如果他说要用一个更优雅的方法解决一个问题，但要花更多的时间，请你选择相信他。好的工程师非常懒惰，他这么做一定是为未来的工作提高效率。

卓越的技术领袖存在：领导如果对技术没有信仰，只把技术当成工具，就很难说这个团队会有工程师文化。说白了不是每个不懂技术的领导都懂得欣赏优雅代码产生的美和对未来产生的深远影响。

技术列为KPI：在我参加晋升面试的时候，50%以上的技术人员讲的都是产品（what），而不是技术（how），并且他们都晋升了.....这源于业务BU总是把业务当成KPI的唯一衡量手段：技术好不好有什么关系？今年不出事，明年我已晋升。如果没有技术KPI，技术就会总被放在次优先级。

工程师文化的特征

小团队：7-12人的团队是比较适合的团队大小。有人用pizza团队来形容一个团队的大小，就是一两张pizza可以喂饱这支团队。facebook和google经常有2-3个人的团队，小团队有如下特征（中文为个人即兴翻译，可以选择忽略）：

Move Fast and Break Things（不破不立）；
Huge Impact with Small Teams（以少为多，精准打击）；
Be Bold and Innovative（勇敢追求卓越）；

技术创新：团队必须坚信技术可以为业务带来不同于现在的可能性，现在没看见不代表它不存在。技术挑战产品是因为也许你不知道还有更好的技术和架构可以更简单更有效地完成一个业务任务。团队激励不单纯以业绩为主的技术的创新，比如：Google每个工程师都有20%的时间可以用于研究自己喜欢的技术，而不是跟Google相关的业务。

技术决策权大：尊重技术决策的前提就是信任技术决策，而不是简单粗暴地说：“为什么完不成？随便叫一个程序员就可以完成。”工程师未必在所有产品特性的定义上有决策的能力，但在优先级和排期上是可以从技术角度给出决策。所有的业务deadline倒排都在一定程度上逼迫技术做出妥协，并且这些妥协慢慢变成合法理由：我的代码不好的原因是业务压力太大。Note：工程师们不要为自己邋遢的代码找理由，代码对于一个软件工程师就是尊严。

技术数据可视化：可视化技术相关数据包含圈复杂度、测试覆盖率、重复率等等，对数据好的工程师给予掌声。但是，好数据给予的是掌声而不是奖金，所有数据都可以被造出来，这是个充分但不必要条件——好的代码数据肯定好，数据好的代码不一定是好代码。

分享多会议少：宁愿少开会掰扯这个应该谁做，这个P1应该谁来背，也要多听技术高手讲一个技术细节，大家都应该沉下心来沉淀一下自己的专业知识。

敏捷

敏捷——一个饱受非议，饱受争议的名词。今天我提它不是想为它正名，其实是想说大个子女孩的故事：我有个大个子女孩同学，身材非常好，178cm，人到中年坚持锻炼，身材高挑，穿啥都是给啥做广告。她告诉我，她外婆小时候走路只敢走在路坎的下面，邻居朋友走在路坎上面，这样可以显得她外婆矮点。那时，高个的女孩是被嘲笑的：150cm的姑娘指着她外婆的背影说：“看这傻大个！”可今天我想对我同学说：“你女儿最好也像你这么高，我儿子去看看能不能追上，优化一下我家族的身高基因。”

很多人一听到敏捷就说：“还说敏捷，早过时了！” 虽然今年流行网红脸，不流行高个姑娘，可她就是比你高。那些听到敏捷就嗤之以鼻的人，你们在坚持什么？至少坚持敏捷实践的人心中有信仰，这是他们作为工程师的信仰，他们还在坚持为减少一个if else修炼每一行代码，坚持为一个完整的自动化测试不停思考，坚持为了两个模块的解耦绞尽脑汁。

即便如此，今天不谈敏捷，就像今天不谈”身高“，我们谈”身材修长“。基于这个前提，敏捷还是不敏捷就不重要了：是不是敏捷，是不是所谓的工程师文化都不重要，重要的是找到适合团队的开发方式，让团队开发效率更好，系统更健壮，特性更易扩展。

盒马基础技术团队实践

Note：本文，我仅对自己的个别两个小分队进行描述。

设计

一个软件技术团队的最终产出物是可交付的软件本身，所以不管什么花里胡哨的管理方式都没有一份安全和稳定运行的代码来的给力。好的代码应该要有设计的痕迹：简单粗暴地还原业务或多或少给未来埋坑。在我们团队，大部分微观代码设计源自我们自己定制的一套领域模型设计套路。套路里要有每个工程师对每个特性的精心设计，同学们的设计原则是：可以设计得不完美，但不能不思考设计；即使已经上线了的系统，只要有问题，代码永远可以修改，但前提是有完善的自动化测试保护。

自动化测试

不要低估了自动化测试可以给软件质量带来的深远影响：不管是当下质量，还是未来加特性，或是单纯的重构代码。

不要低估了编写自动化测试的难度：检验代码好坏的一条标准就是——是否很容易对这块代码添加有效的自动化测试。

测试的一些原则：

代码提交前通过所有测试：测试就是验收标准，是需求验收的代码转换。原则上一条验收标准可以对应至少一个断言（assert），没有断言的测试被视为无效测试；
用given／when／then语态写单元测试；
要让测试代码更容易写必须分离代码逻辑与数据库读写；
合理使用mock／stub技术，测你要测的，让你的测试更有效；
异步测试不要用sleep；
最好的debug手段就是测试；
单元测试耗时最短，多用单元测试覆盖代码逻辑；
越是集成测试数量应该越少，因为代价很大，性价比不高；
静态代码质量分析应该伴随每次持续集成。

持续集成/持续发布

持续集成其实什么都不是，它只是随时把大家的代码编译、打包、部署、测试，不停地跑起来，持续地告诉你代码质量是否满足你的测试要求：

测试应按测试运行时间长短分级编排在不同级别的持续集成中，时间短的测试应该跑得更频繁，比如：代码的每一次push，时间长一点的跑的频度低点，像是每隔3个小时，每天晚上11点开始......
一次编译多次部署，在持续发布的环节中，只有第一次编译打包，后面的环境都是只部署不编译打包。
check in and pray vs check in and play： 每次提交代码要有足够的测试，并交给持续集成反馈结果，代码提交越频繁，你越容易play，代码提交时间间隔越长，你越容易pray。
持续集成的反馈要立刻修复，别让持续集成dashboard红着。
持续发布是你的终极目标

开发分支要少，不然你的持续集成容易没了方向，失去意义。