让研发规范管得住 - 我们为什么在流水线之上又做了研发流程？

作者：子丑

为什么会有研发规范

很多程序员入职一家新的公司，领完电脑再安装完必备的开发工具，接下来最先接触的恐怕就是新公司的研发规范了。几乎所有的软件企业都有或繁或简的一套或多套研发规范，并且大部分软件团队都认为他们的研发规范是不太一样的，是适合他们当前的实际情况的。

研发规范是什么？它又是如何产生的呢？

我们回看历史，会发现研发规范是伴随着上世纪 60 年代开始的软件危机而产生的。在那个时候，软件由过去个人或者小团队的开发形式，逐渐向规模化、大团队的开发模式转变，软件自身的复杂度变高了，软件研发团队的协作复杂度也变高了，出现了诸如软件项目超预算、交付需求延期、交付质量低下、实现不符合需求等等问题。

软件危机的主要原因，把它很不客气地说：在没有机器的时候，编程根本不是问题；当我们有了电脑，编程开始变成问题；而现在我们有巨大的电脑，编程就成为了一个同样巨大的问题。

— 艾兹赫尔·戴克斯特拉， 谦逊的程序员， 《Communications of the ACM》

为了解决软件危机，软件工程出现了，而研发规范是软件工程实践的组成部分。

研发规范的目标，是为了解决或降低出现软件危机的风险。 其首先要解决的，是随着软件复杂度提高和团队规模变大，所带来的协作低效的问题，比如实现与需求不符、项目难以管理等。

所以，研发规范首先包含了研发过程中的协作规范，比如需求从提出到交付的流程规范、代码从开始开发到应用发布的分支规范等，这些规范本质上都是为了解决软件研发过程中不同团队、不同角色之间的协作问题。除了流程，协作规范还会定义需求的描述规范、代码的提交规范等，通过规范化的方式保证信息的完整性和传递的有效性。

另一方面，软件工程的发展，产生了很多优秀的工程实践，比如实例化需求、测试自动化、代码静态分析等，这些实践有着一定的学习门槛和执行成本，但如果使用得当，则可以帮助提升软件的研发效率和质量。因此，研发规范也会包含必要的工程实践，以规范的形式要求研发人员遵守并执行，一方面降低实践的执行成本，抬高软件研发的效率和质量底线，另一方面通过这种方式提升研发人员的工程 素养。

在某些企业，研发规范会制定得非常详细，包括：

• 需求管理规范：定义如何收集、记录、分析、验证和管理来自业务和产品的需求，包括需求的模板、需求分析实践、需求流转流程等。
• 代码管理规范：定义代码库的组织结构、分支策略、提交规范、合并流程、代码规范及如何处理冲突等，也包括代码评审的实践、代码质量的实践等。
• 制品管理规范：定义制品库的组织结构、制品的存储方式、制品的版本控制、制品的依赖管理以及如何发布和分发制品等。
• 测试管理规范：定义如何组织和执行软件测试活动，包括所用到的测试手段如单元测试、集成测试、验收测试等，也包括具体的测试实践，如契约测试实践。
• 自动化测试规范：是测试管理的一个子集，专注于测试自动化的实施，包括自动化测试工具的选型、用例的设计、开发、维护和执行流程等。
• 生产发布规范：定义如何将软件经过开发、测试，最终部署到生产环境的实践和流程，包括版本的管理、部署流程、发布审批、回滚策略、监控和告警设置等。
• 服务治理规范：定义服务级别、服务发现、负载均衡、熔断、限流、降级处理等方面的策略和流程，也包括如 AB 测试等工程实践。
• 安全研发规范：定义整个研发生命周期的安全措施和流程，涵盖需求分析、架构设计、技术实现、测试验收、生产发布等各个阶段，包括需求安全、安全架构、安全编码实践、漏洞管理、密钥和证书管理、合规性检查等方面。
• 等等