如何在团队建设工程师文化？阿里资深技术专家这么做

越来越多的企业重视工程师文化，但很难有人说得清什么才是好的工程师文化。建设工程师文化的具体步骤又是什么？

今天，盒马资深技术专家辉子分享了自己的实践经验，希望能给大家带来一些启发。

前言

人人都在说工程师文化，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 红着。

• 持续发布是你的终极目标

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

分支策略

我们采用的分支策略一定跟大部分同学们的分支策略背道而驰。

1. 大库：大家都在一个库上工作，理由不在这阐述了

2. 分支：分支尽量的少，分支越多持续集成越没意义，merge 成本越高，团队分支最多也不能超过下图

结对编程

两个人在一起写代码在阿里这么繁忙的企业应该是件让人匪夷所思的事情，但我坚持让团队践行这个实践：

• 一个主机，两个键盘，一个显示器

• 新老员工 pair 是新员工 get 实践的最快手段

• pair 让员工有机会互相学习对方良好的编程方式，形成团队独有的代码风格，而不是个人代码风格

• 时不时的 pair 不会降低开发效率，会提高学习热情

code review

很难说还有哪个实践比这个实践对代码质量更有意义，不过，大家 codereview 的方式不尽相同，我们的方式是：

• 团队 code review，总共最好 1 个小时左右

• 每天 code review

• 每个人的代码都要 review，每个人都要讲解

• 发现的问题当天就改掉

• 看官们不要质疑，因为这件事情真的每天在发生

standup 站会

站会是团队沟通的重要手段，阿里其实大部分团队都有站会习惯。

• 不要超过 15 分钟

• 一次只有一个人说话

• 只说三件事情：昨天干了什么，今天要干什么，需要什么帮助

technical session

不是每个 session 都跟业务相关，纯技术的 session 是同学们提高技术的良好手段。

retrosepctive 回顾会议

总结一下过去一个迭代做的好的和不好的，做出自己下一个迭代的改进计划。如果你觉得没有用， 仔细看看图片里记录的点点滴滴 ：

IPM 迭代计划

IPM 计划会议很有必要，团队可以借这个机会了解接下来两周要做什么，大概谁负责什么，大概什么时候可以做完？

拜神

再好的方法也需要关公守护，废话不说，把三兄弟都放上。

IDE

永远不能忽略 IDE 对编程效率带来的影响。IDE 是工程师每天面对的工作环境，任何跟工程效率相关的思想都应该以 IDE PLUGIN 的方式让工程师们每天可用，每天受益。Intellij 作为 JAVA 神器存在有其必要的原因是因为它把能帮到工程师的每一个操作都简化和方便到极致。团队使用 IDE 的技能是否出神入化一定程度反映了这个团队的编程效率是否高。 这是结对编程的另一个重要好处：一个团队使用同一套快捷键写代码，而这套快捷键是整个团队每个成员快捷键使用心得的合集。