前言
是不是流程约束越多，效率越低？不然，如果因为缺了流程约束，而搞砸了质量，那么一切都将归零。
所以找到一套适合自身的研发过程质量管理方式，在质量与效率之间趋向平衡是每个研发团队所必须要考虑的事情，本文是基于中小规模的企业环境中，研发团队不过百人而总结出来的一套最小化研发过程质量管理，以供有意者参加。
一、总体概要图
二、需求设计阶段
技术方案评审
需求设计阶段最关键的就是技术方案评审，关于评审重点要放在以下几个内容上：
1. 评审参与人员
首先一定要有需求承接团队的架构师或者技术负责人在场，这并不是因为他们的技术怎么样，而是因为他们看问题的视角不一样，他们更关注技术方案是否有最佳实践可参考，领域边界划分是否合理，非功能性是否有考虑等等。
除此之外必要参与评审的人员还应包括，研发、测试、产品，如果涉及到上下游系统支持时，还需要上下游系统的相关人员一起参加，不同的角色看问题会有不同的角度，这也是这些人参会的必要原因之一。
2. 评审方式
评审时要以提问为主，建议在评审开始之前，先将设计文档发出来，让参与评审的人员先过一遍，参与评审的人员要带着问题来评审，提问人与回答问题的人都要清楚自己的目的是什么，提问的人不要挑刺，提出类似于过度设计的场景，回答问题的不要反感，要抱着学习的心态。
3. 评审内容
一图胜千言：设计文档中在有复杂处理逻辑时应有相关流程图，在有多系统交互时应有相关时序图，在有多状态变更时应有相关状态图。
认知统一：明确边界模糊地带设计，达成架构清晰，职责明确。
接口协议：接口设计时除了基本出参入参之外，还应考虑到接口权限，参数合法性校验，幂等，限流，熔断，降级，敏感数据等。
数据存储：数据表设计时关注了表结构（可以参考基本范式），字段类型，索引以及数据预期增长量。
中间件：其他的如有涉及到中间件，如Redis、MQ、ElasticSearch等等需说明具体使用场景以及如何使用。
分布式问题：分布式事务、分布式锁、分布式存储。
4. 非功能性设计
非功能性本身当然也是评审的内容，但因比较特殊，所以单独拉出来聊。
非功能性需求一般包括：性能、安全、隔离、兼容、灰度等方面。
性能：性能不必多说，但凡链路过长，QPS过高，数据量过大等情况就一定存在性能问题。
安全：安全一方面是业务问题上的安全，一方面是系统问题上的安全。
隔离：隔离也有很多层面，例如业务分核心与非核心，在线，离线，近实时；环境和数据分正式与非正式，多业务，多租户；资源分软件硬件，读写，连接池，线程池，队列，分区等。
兼容：兼容也是常常容易被忽略的地方，主要是涉及到协议时考虑向前、向后的兼容，向前兼容就是老服务兼容新协议，向后兼容就是新服务兼容老协议。
灰度：最后一点就是灰度，非严格意义上来看灰度也可以包括ABTest的范围，这通常是业务上的述求，而研发所要求的灰度更倾向于服务稳定性上的考虑，谁也无法保证上线不出问题，既然无法避免，那就只能尽量减少影响范围，而灰度策略就是一种简单又有效的方式。
三、开发阶段
开发计划
凡事预则立，不预则废，充分准备就是成功的关键，也是以结果为导向的关键。做项目就是要得到结果，有结果，过程怎么样都是有道理的，没有结果，有再多原因那也都是在找理由。不过，要想得到结果，过程还是非常重要的，而制定计划，按计划执行就是避免在过程中遗漏对关键目标跟踪的有效方式。
各阶段时间表，主要节点就是开发时间、测试时间、验收时间以及发布时间，这里面开发时间又包括需求设计时间，独立开发时间，开发联调时间（内、外部），尤其是涉及到多方人员参与时这个时间一定要事先确认好，并以相对正式的方式进行公示。如果是灰度上线方式，也需要提前做好灰度时间的计划。
项目状况跟踪
理想的状态是到了开发阶段，就能根据前一阶段的开发设计一鼓作气的完成开发，但实际情况肯定会遇到些问题是在之前设计时没有识别出来的，另一方面因人的因素（千万不要以为只要排了计划，所有人就会到点交结果。），事的因素所引起的问题也无法保证能够完全按照项目计划来进行。
所以无论处于什么阶段，只要没有结束就应当保持对项目状况的持续跟踪，包括每天的工作情况，是否有遇到什么困难，外部参与人员能否按计划完成约定的事项等等。
对于识别出来的新问题，无论是需要变更需求，还是需要变更设计，都必须及时的给与响应，并以相对正式的方式确保通知到所有干系人，并让其评估是否还会带来其他影响。
沟通形式
根据项目实际情况决定按照每日站会的方式进行追踪，不需要很长时间，主要以信息反馈为主，需要进一步沟通的可以等到会后，如果项目中还有外部人员参与的，至少也需要安排每周进行一次沟通反馈。
项目信息的反馈方式一定要显得正式一点，并以文字加口头表达的形式传递给项目相关人员。
研发质量
关于软件架构、设计原则这种“道”层面上面的内容就不在这里阐述了，本文的研发质量管理主要是针对“术”。
1. 编码规范
符合编码规范要求（代码编写规范、日志打印规范、RPC调用规范、服务依赖规范、sonar扫描等等），大众熟知的如阿里的Java开发手册，对于这些规范要求，我一直强调要先搞清楚为什么要这样规定，在搞清楚目的的前提下，再结合自己公司的实际情况结合使用才能达到较好的效果。
2. 关于接口
接口要满足防御性功能，记住下面三个原则：
- 凡是上下游依赖保持不信任。
- 凡是第三方依赖都有降级、熔断方案。
- 墨菲定律，凡是可能出错的地方就一定会出错，做好处理。
3. 代码自测
研发自测时如果能保证覆盖率和边界值这两个关键点，基本上就能避免大多数问题遗留到测试阶段了，覆盖率指的是有多少分支逻辑被验证到了，边界条件例如超范围，非法参数等特殊值验证。
4. 代码Review
代码Review总是容易被忽视的一步，长期放任不管不但会给研发过程但来困难，也会造成研发质量的降低。
-
关注点：代码评审一方面是看编码规范、一方面是看性能，处理逻辑的细节建议熟悉的开发之间互相把控。
-
一次性Review的量：不要一次性提交太多Review的代码。
-
互相学习：review是互相学习的过程，学习别人的处理方式的同时也可以向别人展示你的知识积累。
四、测试阶段
测试用例评审
应当是同技术方案评审差不多的要求。
冒烟测试要求
开发人员要对提测质量负责，除了自己完成之外，也要满足冒烟测试用例通过，这样才算是符合提测要求。
测试质量结果
测试阶段需要关注：冒烟通过率，自动化case通过率，缺陷日清率，缺陷引入率。
五、发布阶段
虽然在前面几个阶段已经做了很多为防止系统发布后出现问题的事情，但有意思的是，大多数的系统的问题仍旧是因为新的发布所导致的，就如墨菲定律所描述的一样，因此，我们得清楚认识到上线是最后可能造成系统故障的时候，我们无法追求系统永远不出问题，我们追求的是将故障所造成的影响时间、范围尽量缩短。
因此首先我们至少需要明确本次发布需要准备哪些事项（Checklist），这些事项至少要包括如下几点：
发布内容：包括发布时间，发布的服务（服务发布顺序），发布的脚本（是否存在大表操作，脚本执行时间），配置中心修改项等。
发布影响评估：业务影响，应用影响，系统影响等。
回滚方案：搞清楚什么时候需要回滚？通常我们如果我们发现服务核心功能不可用了，就应该立即回滚，如果非这种情况，则一般结合日志，监控等观察工具，如有明显异常数增长，则也应立即采取回滚避险方式。
回滚内容就是发布的内容，服务回滚，脚本回滚，配置项回滚等，最后观察回滚后是否如预期一样恢复正常。
发布后验证：系统运行是否正常？业务功能是否正常？新上线的内容是否满足预期？
三板斧：
阿里有个安全生产三板斧的概念：可观测、可灰度、可回滚。
可观测就是一系列系统与业务指标的问题，最后在避免漏报与无效告警之间平衡。
可灰度前面提到过除了业务本身的灰度要求之外，技术从系统稳定性上考虑也会有灰度的要求，比如按机器维度，按流量维度，按用户维度等等。
最后就是可回滚，通常是通过代码开关控制或直接服务部署回滚，在设计时考虑好兼容性即可，这点在设计阶段也已经提到过。
