研发效率破局之道阅读总结(2)流程优化

Author: Once Day Date: 2025年4月15日

一位热衷于Linux学习和开发的菜鸟，试图谱写一场冒险之旅，也许终点只是一场白日梦…

漫漫长路，有人对你微笑过嘛…

全系列文章可参考专栏: 程序的艺术_Once-Day的博客-CSDN博客

注: 本文内容摘抄于原文，文中"我"代表原作者【葛俊】大佬视角。

参考文章:

• 研发效率破局之道

---

1. 如何实践方法论

方法论实施效果不好，关键在于没用好。

在学习方法论的时候，我推荐使用类似美国著名作家、企业顾问西蒙斯 · 涅克（Simon Sinek）总结的 Why-How-What 黄金圈法则。

参见下图：最中间的一个圆是 Why，也就是这个方法论的目标，是要解决一个什么问题； 第二个圆是 How，也就是这个方法论的基本原则、指导思想；最外层的圆是 What，也就 是这个方法论的具体实践。

在使用一个方法论的时候，一定要从内往外看。中心的目标一般错不了。比如，敏捷的目标就是快速应对变化。原则的通用性就差一些，你需要在理解的基础上挑选适合自己的。比如，敏捷中有一条原则是“面对面交谈是最好的沟通方式”，就不一定适合你的团队。 具体的实践，就更要小心，切忌生搬硬套。

在引入实践的时候，我的建议是逐步优化已有的开发流程和框架，甚至只给出原则，让团队 成员逐步摸索并最终找到合适的方法。

• 衡量每一个时间段成果的标准，应该是价值假设方面的进展。也就是说，你的工作应该让你学习到如何更好地给用户提供价值，而不是开发了多少功能。
• 使用最小可行性产品（Minium Viable Product，MVP）来帮助学习。这里的关键点是，要以探索价值为出发点设计产品，最快地验证你的假设，功能要尽量少， 能够使用就可以。
• 让功能尽快地流动，说白了就是快速开发。问题发现得越晚，修复代价越高，这已经是常识。要做到快速开发，开发人员需要尽量把功能拆分，同时做好一个提交之后尽快提交。
• 让节点之间的联动更加顺畅，可以通过对关键流程的自动化、工具之间的网状互联， 以及节点之间的融合来实现。在具体实践上，个人代码上线后，在和他人的代码集成时容易 出现问题，这时就可以使用 CI/CD（持续集成 / 持续交付）流水线来自动化代码集成过程。
• 节点间的融合，也是为了保证节点间的联动顺畅。也就是模糊节点间的边界，让功能在节点之间的流动更顺畅。在这一方面，我见到比较有效的方式是：职能团队提供平台和工 具，让全栈工程师能够自己处理端到端的工作。比如，测试团队提供测试平台和工具，运维团队提供运维平台和工具，这些平台和工具可以通过服务化自助使用。
• 发现整个流程中的瓶颈，并解决它们。

Facebook 在流程方面的实践，给我最大的一个感受就是，以实用主义的态度，从原则出发，灵活优化流程。在 Facebook 的几年时间里，我并没有听到很多新方法论的时髦术语，但是公司的很多实践却和这些方法论的原则是一致的，甚至是超前这些方法论的。

2. 如何聚焦于开发

代码入库之前的开发活动，主要包括编码、调测调优、静态检查、自动化测试、代码审查 等。这是开发者编写代码的步骤，自然是提高研发效能的关键环节。

提高开发者编写代码的效能，关键在于让开发者不受阻塞、不受不必要的干扰，从而全身心地聚焦在产品开发上。我把这种不受阻塞的开发状态叫作持续开发。

要让开发者聚焦于开发，就必须把研发流程中可以自动化的步骤尽量自动化。因为一般不可能完成所有步骤的自动化，所以我推荐的方式是：分析关键路径上的活动，以及耗时较长的活动，然后投入精力优化这些步骤。

提高开发环境的获取效率：把整个开发环境的获取，进行服务化、自助化。也就是说， 开发者可以自助地申请获取环境，不需要 IT 部门的人员介入。可以提供机器镜像和配置脚本，通过镜像让每一台新机器拥有最基本的设置，比 如 CPU、操作系统、基本软件，然后通过脚本实现基本配置，比如网络设置、软件更新 等。

规范化、自动化化本地检查：本地检查是指，开发者在开发机器上进行的验证，比如语法检查、规范检查、单元测试、沙盒搭建等。我推荐的方式是，根据团队实际情况，找到合适的工具和配置进行这些检查，并 让团队成员统一使用。

建设并自动化代码入库前的检查流程：建设并自动化代码入库前的检查流程，是持续集成前的必要工作，也可以看作是持续集成的 一部分。

提供快速反馈，促进增量开发：提供快速反馈，进行增量开发指的是，能够快速验证已经完成的开发工作，说白了就是边开 发边验证。包括灵活使用各种 Linter 和测试、建设并优化沙盒环境、使用实时检查工具。

代码集成越晚发现问题就越晚。这正是产品上线的最后关头合并混乱， 产品质量差、返工率高的一个重要原因。

3. 持续集成和持续开发

代码入库和入库后的 3 种持续工程方法：

• 持续集成（Continuous Integration, CI)，在团队协作中，一天内多次将所有开发人员的代码合并入同一 条主干。
• 持续交付（Continuous Delivery, CD），在短周期内完成软件产品，以保证软件保持在随时可以发布的状态。
• 持续部署（Continuous Deployment, CD)。每一个代码提交，都构建出产品直接部署给用户使用。

4. git分支管理

Facebook 的分支管理和发布策略：一种基于主干的开发方式，也叫作 Trunk-based。在这种方式中，用于开发的长期分支只有一个，而用于发布的分支可以有多个。所有的开发人员基于 master 分支进行开发，提交也直接 push 到这个分支上。基于主干开发模式中，在需要发布的时候会从 master 拉出一条发布分支，进行测试、稳定。在发布分支发现问题后，先在 master 上修复，然后 cherry-pick 到发布分支上。

Git-flow 工作流：有两个长期分支：一个是 master，包含可以部署到生产环境的代码；另一个是 develop，是一个用来集成代码的分支，开发新功能、新发布，都从 develop 里拉分支。此外，它还有 3 种短期分支，分别是新功能分支、发布分支、热修复分支，根据需要创建，当完成了自己的任务后就会被删除。

Fork-merge： Fork-merge 是在 GitHub、GitLab 流行之后产生的，具体做法是：每个开发人员在代码 仓服务器上有一个“个人”代码仓。这个“个人”代码仓实际上就是主代码仓的一个 clone。

开发者对主代码仓贡献代码的步骤如下：

1. 开发者产生一个主代码仓的 fork，成为自己的个人代码仓；
2. 开发者在本地 clone 个人代码仓；
3. 开发者在本地开发，并把代码推送到自己的个人代码仓；
4. 开发者通过 web 界面，向主代码仓作者提出 Pull request；
5. 主代码仓的管理者在自己的开发机器上，取得开发者的提交，验证通过之后再推送到主代码仓。

总结来说，尽量减少长期分支的数量，代码尽早合并回主仓，方便使用 CI/CD 等方法保证主仓代码提交的质量，是选择分支策略的基本出发点。

5. 全栈开发

DevOps，Development 和 Operations 的组合词，是一种重视“软件开发人员 （Dev）”和“IT 运维技术人员（Ops）”之间沟通合作的文化、活动或惯例。 通过自动化“软件交付”和“架构变更”的流程，使得软件的构建、测试、发布更加快捷、频繁和可靠。

SRE，全称是 Site Reliability Engineer ，网站可靠性工程师，是一个职位，是软件工程师和系统管理员的结合，主要目标是创建可扩展且高度可靠的软件系统。

目标、利益不一致，是导致开发团队和运维团队矛盾的首要问题，所以想办法让它们的目标、利益变得一致，是整个 DevOps 中最重要的一条。因为只有协调好了目标和利益，他们才有动力去解决问题。实现这个原则的一个最主要的方法，我称之为“全栈开发”。

全栈开发就是让工程师不再只是对某一个单一职能负责，而是对最终产品负责。

注: 本文内容摘抄于原文，文中"我"代表原作者【葛俊】大佬视角。