工程师文化落地的几点思考

什么是工程师文化？

1、自我驱动，学习型团队；

2、讲团队合作，彼此信任；

3、注重效率，自动化；

4、热衷开源技术，着眼未来；

常见的工程师文化落地

1、CodeReview

如果还在犹豫是否应该 CR，不确定 CR 是否应该推广，先看是否要做 Code Review？阅读 >>> 与BAT资深架构师争论之后的思考

以往的经历中，CodeReview 是每周一次，以小组为单位，每个成员轮流汇报一下上周进度、遇到的问题、写的代码、和思考。也有别的团队把 Code Review 放在每天，因为当天的代码量不多，每天的 CodeReview 其实也不会耗费太多。

刚开始大家对这个制度没太大感知，可以每周或者每两周一次，或者有代表能主动 CodeReview 一下，让大家熟悉这个流程，特别是日常对《代码整洁之道》和《重构》的学习实践，能够 从命名风格、职责划分、文件目录、设计模式等不同层面进行 CodeReview。但是目前最重要的还是命名规范、编码风格。比如换行、空格、注释，删除无用代码等，用 IDE 工具强制统一，每次提交代码前必须格式化。实行一段时间后，CodeReview 时间就相对比较少，甚至在提交代码的时候就可以利用 gitlab 等工具进行 CodeReview。

更多详细的 CodeReview 方法，可以参考你真的会Code Review吗？里边列举了最佳实践，要点如下：

1. 每次 Review 的代码量不要太多，控制在 400 行以内

2. 最好的建议是将一次 Review 的时间控制在 60 分钟以内

3. 确定 Code Style，亦可借助静态检查工具

4. 提交 Review 之前，工程师需要做严格的自我检查，根据 Checklist

5. 完善 CI/CD，（持续发布、持续部署，实践起来相对难度比较大）

6. 激励制度 通过统计对团队中 Review 次数，Comments 次数多的员工进行一定的物质激励，比如杯子，充电宝，书籍等简单的小物品。提升团队内 Code Review 气氛。

2、站会制度（汇报工作进度）

以往经历主要做 app 版本迭代，有比较固定的发布周期，提倡敏捷开发，在两周一个版本的节奏下，每个人分配的任务进行小时为单位的估时，最后统计总时间，对开发任务进行取舍，因为一周时间有限，比如有效开发时间一周按 40 个小时算，开发量多肯定会加班（加班肯定是沟通不足、或者估时过少造成），开发量比较的情况不存在。一般 站会制度是想让一个小团队，负责某个项目开发的每个成员（包括产品、测试、设计）都能 站成一个圈，轮流讲一下“昨天做了什么、遇到了什么问题、打算怎么解决、今天做什么、需要谁的帮助” 简短的发言，目标是最及时的反馈，信息同步，让大家对每个环节能心里有数，提高团队效率和彼此信任。

这个制度的目的还是信息同步，及时跟进，推动项目进行。

更详细的实施可以参考 每日站会怎么开才好？——你的站会姿势正确吗？

3、周会制度

这个是以周为周期，以职能上的分组为单位进行的一次内部交流。可以视情况而定。

4、总结回顾

复盘，这是一个团队习惯，一般比较重大的项目开发结束后肯定会暴露一些问题 或者 沟通 或者 代码设计 或者别的，最重要的是 能够阶段性的回顾一下：我们这个项目的目标是什么？我们做的效果怎么样，举例指标或者运营效果？有那些自我感觉做的比较好点？有那些做的不好需要自我批评？做的好的可以形成经验进行推广或提倡。做的不好的要反思形成改进意见做一个 TODOLIST

CaseStudy，是针对日常出现的比较重大的责任事故，需要追责，不一定惩罚，但一定要明确责任，为什么会发生？怎么解决的？有什么总结反思？要吸取什么教训？

复盘和 CaseStudy 都要做成 书面文档维护在团队文档里。 Confluence 团队文档是不同于 禅道的项目管理、不同于接口文档的 技术文档，是自我沉淀和反思的一个空间。

5、技术架构演进

没有完美的架构，但至少可以追求更好的设计，更好的抽象化，有利于后期维护和解耦，也提高系统稳定性和健壮性。架构设计肯定是渐进式的，慢慢优化摸索出来的。

我们要重构腐化的架构及不符合软件工程规范和质量要求的历史代码。

面对腐化了的架构，要毫不犹豫地去重构它。 任正非

6、技术分享会

1. 内部分享 结合工作讨论一下最近感兴趣的技术是什么，怎么能够利用到工作中，等等。以一个话题一个人或者多个人进行分享，分享完可以讨论。

2. 邀请业内大咖 过来分享。

7、一对一导师制和结对编程

让新人来了能快速适应团队，有一个人指导，规范下入职流程，开什么账号、需要什么权限、一步步了解什么代码，哪个同事对哪个功能比较熟悉，需要特别注意了解什么技术点，能够完整的走下来。

提倡结对编程，互相学习取长补短，传帮带，帮助员工一起成长。

8、阅读（小型图书馆，推荐书籍）

9、技术委员会

专门负责工程师文化建设，团队技术氛围等等。

10、团队博客

writing is thinking, 多总结，有产出，提高团队知名度和吸引力

11、自动化测试、 持续集成

规范代码上线流程，降低手动上代码的风险，让每个人专注于业务开发，能够自动化的尽量让代码或者机器来做，这个可能会更远一点，因为整个架构都要做调整。

尽早提交代码去集成。

12、开源文化

不要把时间浪费在已解决的问题上。

13、布道师

应该有人能充当技术领袖或者一个团队灵魂人物，在技术方向把控，有威信力、说服力。

14、一切的重点，都是提高效率，尽早交付更高质量的软件

能满足这个目标的工具、方法、流程，都可以说是最佳实践，都属于敏捷开发。

如果不注意这些会怎么样？

1. 要招更多人来维护烂代码，带来更大的经济成本。

2. 技术债迟早要还的。

1、需求文档:做什么？为什么？怎么做？边界怎么处理？在文档写清楚功能验收标准，降低边界问题对开发时间的消耗；

2、写代码前先做好 UML 图，评审后再写代码；

重构-改善既有代码（或 代码整洁之道）

领域驱动设计-软件核心复杂性应对之道

架构整洁之道

节选任正非的公开信

我们要改变只重视功能结果、不重视代码质量的行为习惯，要严格遵守软件工程规范；改变被动的修修补补；改变碎片化知识获取，主动去学习提升并贡献经验、代码，形成共享知识库。

我们将全面强化以 Committer 角色为核心的代码审核和提交机制，代码经过更加严格和系统的审核才能合入版本。为此我们将建立一支更高水平的 Committer 角色群体，负责软件架构的看护、代码的审核和提交，整体保障合入代码的高质量。我们要变革考核机制，要让架构设计好、代码写得好的人脱颖而出，对编程能力不满足要求的人给予帮助和培训。但任何人如果编写的代码长时间不能合入版本，将会被团队抛弃。

本文文字及图片出自 InfoQ