软件工程之美学习笔记十三 12 | 流程和规范：红绿灯不是约束，而是用来提高效率

《软件工程之美》材料地址:https://time.geekbang.org/column/article/87129

1 为什么要有流程规范？

提升团队效率

从个体来看，因为流程规范的存在，确实可能存在效率降低的情况，但从团队的角度来看，好的流程规范反而是提升效率的。

将好的实践标准化流程化，让大家可以共享经验

各种开发模型，实际上也是开发流程规范

借助流程规范，让项目管理从人治到“法治”

而好的项目管理，不需要直接管人管事，而是管理好计划和流程规范；项目成员不需要按照项目经理的指令做事，而是遵循计划和流程规范。

举例：红绿灯交通规范

2 如何制定好流程规范？

第一步：明确要解决的问题
第二步：提出解决方案

1. 敏捷开发的流程

2. 代码规范：
   Airbnb JavaScript Style Guide
   Google Java Style Guide
   .NET Guide

3. 源代码管理流程
   《 Git 使用规范流程 》
   《Git 工作流程》
   《Git分支管理策略》
   《Understanding the GitHub flow》
   《Introduction to GitLab Flow》

4. 部署流程

第三步：达成共识，推广执行
第四步： 持续优化，不断改进

3 将流程规范工具化

任正非的《全面提升软件工程能力与实践，打造可信的高质量产品》被人总结为

“软件工程”和“质量工程”需要依靠架构技术，而不是依靠CMM和QA管理流程。一切工程问题，首先要思考能否通过技术解决，当前技术无法解决的问题，暂时由管理手段代劳，同时不停止寻找技术手段。

4 我的留言

我来谈谈对老师讲的几个点的个人看法和实践。
1，方法和流程规范的区别。
老师讲的很对，流程规范是在很多经验总结后形成的。从ITIL流程来说，这里的方法实际上可以理解为事件管理的范畴，就是发现了一个incident ,想办法去解决，甚至用work around 的方法去解决。当相同的incident发现次数多了，在review的时候，事件就上升成为问题。问题管理就是用来彻底避免相同事件重复发生的。而规范流程是问题管理的一种手段。问题管理会带来变更管理，规范流程的制定和修改，是可以纳入到变更管理中的，只要纳入到变更管理，就自然会考虑到沟通机制、回退计划等事情。我们也碰到过类似老师提到的该数据库的问题。刚开始数据库该出问题了，我们就处理数据库问题，后来，总结下来，需要严格改数据库的流程，比如增加业务运维和基础运维的经理审批才允许修改数据库。改数据库的流程我们也花了很多时间进行优化才真正固定下来。
2，流程规范工具化。
我觉得，除了工具化，还要尽量自动化。举个例子，我们这边最早采用checkstyle和findbug嵌入到IDE的方式进行代码检查，然后规定每个项目必须用这两个工具。但后来发现，这个规定执行的很不好，许多项目组没有自觉执行，增加了QA团队的检查工作量。后来我们采用sonarqube,并把它集成到ci里，就不怕项目组不执行了。
3，推广执行的问题
除了前面两个方法，纳入变更管理和纳入自动化流水线之外，还有一个特别重要，那就是考核问题。但这个有很大的难度。有些规范的执行力度很难量化考核，就举个简单的例子，测试用例和需求文档的匹配问题，还有比如压力测试的性能指标问题，如果没有工具和环境，这简直会把QA愁死。所以，流程执行的好坏，还是与人和工具技术有关，三者互相关联，缺一不可。

关于第三点，我也想问问老师，需求文档和测试用例怎么验收？对于性能测试是否合格问题，你们是怎么解决测试环境和生产环境可比性问题的？

老师回复: ?谢谢高质量的补充！

需求文档验收可以通过需求评审会议，评审时开发和测试都要有代表参加，一个是提出反馈，另一个是及早了解需求。评审会议通常要开几次才能最终定下来。

测试用例通常是产品经理协助验收或者辅助确认。

原来我们在飞信时，会有一个模拟生产环境的压力测试环节，从生产环境同步真实数据过去，规模按生产环境比例缩放。

还有的压力测试是直接在生产环境做的，在半夜人流量少的时候。