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

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

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

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

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

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

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

参考文章:

研发效率破局之道

文章目录

研发效率破局之道阅读总结(3)工程优化
- - - 1. 软件研发环境
    - 2. 如何做好代码审查
    - 3. 如何处理技术债
    - 4. 测试如何应对新的开发模式
    - 5. 各种部署的定义

1. 软件研发环境

按照开发流程，软件研发需要以下几种环境：

开发机器；
IDE；
开发过程中使用的各种工具、数据和配置；
本地环境、联调环境；
测试环境、类生产环境

Facebook 从不吝啬在开发机器上的投资。每个开发人员除了有一台笔记本外，还在远程数据中心有一台开发机器。数据中心的机器用于后端以及网站的开发，为方便描述，我称之为后端开发机。而笔记本有两个用处：一是用来做移动端 App 的开发；二是作为终端，连接到后端开发机做后端和网站开发。

两台机器的配置都非常强劲。后端开发机一开始是实体机器，后来为了便于管理和提高资源利用率，逐步转为了虚拟机，但不变的是配置依然强大。在 2015 年的时候，绝大部分机器配置都能达到 16 核 CPU 、144G 内存。笔记本有两种选择，一种是苹果 MacBook Pro，另一种是联想 ThinkPad，都是当时市场上顶配或者顶配下一级的配置。

配置高效的研发环境主要包括以下几条原则：

舍得投入资源，用资源换取开发人员时间。
对环境的获取进行服务化、自助化。
注重环境的一体化、一致性，也就是要把团队的最佳实践固化下来。

2. 如何做好代码审查

做好代码审查的一个前提条件就是，要找到适合自己团队的方法。

按照定义，人工检查才是代码审查。机器进行的检查一般叫作代码检查或者代码自动检查。

代码审查的作用很多，主要表现在 5 个方面。

尽早发现 Bug 和设计中存在的问题。我们都知道，问题发现得越晚，修复的代价越大。代码审查把问题的发现尽量提前，自然会提高效能。
提高个人工程能力。不言而喻，别人对你的代码提建议，自然能提高你的工程能力。事实上，仅仅因为知道自己的代码会被同事审查，你就会注意提高代码质量。
团队知识共享。一段代码入库之后，就从个人的代码变成了团队的代码。代码审查可以帮助其他开发者了解这些代码的设计思想、实现方式等。
针对某个特定方面提高质量。一些比较专业的领域，比如安全、性能、UI 等，可以邀请专家进行专项审查。另外，一些核心代码或者高风险代码，也可以通过团队集体审查的方式来保证质量。
统一编码风格。

按照审查方式，代码审查可以分为工具辅助的线下异步审查和面对面审查两类。

工具辅助的线下异步审查，就是代码作者通过工具将代码发送给审查者，审查者再通过工具把反馈传递给作者。可以控制审查时间，减少对自己工作的干扰，会留下文档，方便以后参考。
面对面审查，就是审查者和代码作者在一块儿阅读代码，进行实时讨论。这种方式的好处是快，可以高效地审查不方便用文字讨论的代码。比如，架构问题的讨论就很适合用这种方式。

事实上，有调查显示，代码审查更容易发现架构问题而不是 Bug。所以我的建议是，尽量使用代码设计时审查。具体的方法是，可以使用与门禁代码检查相同的工具，只不过这个时候发出去的 PR 目的是为了讨论，而不是为了入库。讨论结束后删除这个 PR 即可。

在这里插入图片描述

代码审查需要时间，这听起来好像是废话，但很多团队在引入代码审查时，都没有为它预留时间。结果是大家没有时间做审查，效果自然也就不好。而效果不好又导致代码审查得不到管理者重视，开发人员更不可能将代码审查放到自己的工作计划中。于是，形成恶性循环，代码审查要么被逐渐废弃，要么流于形式。

管理者要明确代码审查是开发工作的重要组成部分，并记入工作量和绩效考评。这是成功引入代码审查的前提，再怎么强调都不为过。

成功推进代码审查的关键操作:

代码提交的原子性，是指一个提交包含一个不可分割的特性、修复或者优化，同时这个提交要尽可能小。
提高提交说明的质量，，好的格式应该包含：标题，详细描述，测试情况，与其他工具和系统相关的信息。

代码审查是两个开发者之间的技术交流，双方都要谨记互相尊重的原则。

从审查者的角度来看，在提出建议的时候，一定要考虑代码作者的感受。最重要的一点是，不要用一些主观标准来评判别人的代码。

在打回提交的时候，一定要礼貌地描述原因。审查要尽量及时，如果不能及时审查要告知作者。

代码审查常常出现问题的一个地方是，在审查过程中因为意见不同而产生争执甚至争吵，所以一定记住代码审查的目的是讨论，而不是评判。讨论的心态，有助于放下不必要的自尊心，从而顺利地进行技术交流，提高审查效率。另外，讨论的心态也能促进大家提早发出审查，从而尽早发现结构设计方面的问题。

审查者切记不要说教，说教容易让人反感，不是讨论的好方法。审查者提意见即可，不一定要提供解决方法。我曾经见过一个团队要求提出问题必须给出对应的答案，结果是大家都不愿提问题了。

想办法增加讨论的有趣性。

3. 如何处理技术债

第一方面，要利用技术债的好处，必要时要大胆“举债前行”。也就是说，在机会出现时，使用最快的方式完成业务服务用户，抢占市场先机，“不要在意那些细节”。

第二个方面，要控制技术债，在适当的时候偿还适当部分的技术债。

控制技术债主要有以下 4 步：

让公司管理层意识到偿还技术债的重要性，从而愿意投入资源；
采用低成本的方式去预防；
识别技术债并找到可能的解决方案；
持续重构，解决高优先级技术债。

4. 测试如何应对新的开发模式

测试可以保证产品质量，重要性不言而喻。但，要做好测试也比较困难，需要克服很多挑战。尤其是，持续交付、敏捷开发等开发模式为传统软件测试方式带来了更大的时间压力。

我们先来看看下面这种熟悉的测试方式都有什么问题：

测试人员接到项目后参与需求评审，然后根据需求文档写用例、准备脚本，等开发提测之后正式开始测试、提 Bug、回归，测试通过后就结束了，项目交给运维上线，之后投入下一个项目继续重复这样的流程。

这样的流程看似没什么错，但有两大问题：

测试人员非常被动。当需求质量、开发质量较差的时候，测试人员只能被动接受。
但同时，测试又被认为是质量的责任人。如果因为需求质量、开发提测质量差而导致上线延期，大家通常会首先怪罪测试团队。

这些问题，在新的开发模式下愈发严重。因为这些新的开发模式有一个共同点，就是要缩短产品的交付周期，对自动化的要求越来越高，能够专门留给传统竖井流程中测试环节的时间越来越短，自然更难保证质量。

测试左移和右移，就是把测试的范围从传统测试的节点中释放出来，向左和右扩展。

向左扩展，就是让测试介入代码提测之前的部分。比如，扩展到开发阶段，在架构设计时就考虑产品的可测试性，并尽量进行开发自测等。另外，测试可以更进一步扩展到需求评审阶段，让测试人员不只是了解需求，更要评估需求的质量，比如分析需求的合理性以及完整性等。
测试右移，是让测试介入代码提测之后的部分。比如，测试人员在产品上线过程中，利用线上的真实环境测试。另外产品上线之后，测试人员仍然介入，通过线上监控和预警，及时发现问题并跟进解决，将影响范围降到最低。这样一来，测试人员不但有更多的时间进行测试，还能发现在非生产环境中难以发现的问题。

要做好测试左移，有 3 个基本原则：

调整团队对测试的态度。一个有效的办法是，按照功能的维度管理团队，让整个功能团队对产品负责。也就是说，如果产品质量出现问题，不只是测试团队“背锅”，而是会影响整个功能团队的绩效。
把测试添加到开发和产品需求步骤中。常用的办法是，让测试人员参与到开发阶段的方案设计中，了解开发的实现方式。因为很多开发人员可能只熟悉他负责的那一部分，而测试人员往往对全局更加了解，所以测试人员要评估改动范围以及是否有遗漏的模块和系统。
频繁测试，快速测试。在测试左移之前，我们需要等待提测，比较被动，不能频繁测试。但测试左移到开发阶段之后，我们就有了很大的自由度去频繁运行测试，从而更好地发挥测试的作用，尽早发现更多的问题。

测试左移，本质上是尽早发现问题、预防问题。基本原则包括：从人的角度出发，让产品、开发、运维人员统一认识，重视测试；从流程上，让测试融入产品设计和开发步骤中；快速测试、频繁测试。

其实，软件开发行业早就达成了共识，问题发现得越晚，修复代价越大。