05 代码入库前：Facebook如何让开发人员聚焦于开发？

你好，我是葛俊。今天，我将与你分享优化流程中，代码入库前的开发流程。

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

图1 本地开发流水线

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

一个团队如果能够做到持续开发，那么它的有效产出自然会很好。而对于个人开发者而言，持续开发能够帮助我们把精力集中在技术本身，对技术和个人能力的提升都大有裨益，所以是一种很好的开发体验。

在我看来，持续开发的基本原则主要包括两条：

规范化、自动化核心步骤；
快速反馈，增量开发。

接下来，我们就一起看看这两条核心原则吧。

规范化、自动化核心步骤

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

首先，我们需要明确具体的开发步骤有哪些。我将其归纳为以下三大步：

获取开发环境，包括获取开发机器、配置环境、获取代码等。
在本地开发机器上进行开发，包括本地的编码、调测、单元测试等。
代码入库前，把改动提交到检查中心（比如Gerrit），再进行一轮系统检查，主要包括代码检查、单元测试、代码审查等，通过之后再入库。

图2 代码入库前的3大开发步骤

针对这三大步骤，我们可以有以下3个工程实践：

提高开发环境的获取效率；
规范化、自动化本地检查；
建设并自动化代码入库前的检查流程。

接下来，我们分别看看这3个工程实践如何落地。

提高开发环境的获取效率

开发环境的设置，包括开发机器的获取、网络配置、基本工具以及代码的获取和配置。这些操作的频率不是特别高，但如果步骤复杂、耗时长，就会对新成员加入、成员切换团队或者项目，产生比较大的影响。所以，开发环境的获取效率，通常是值得优化的。

有一个可以采用的优化方式是，把整个开发环境的获取，进行服务化、自助化。也就是说，开发者可以自助地申请获取环境，不需要IT部门的人员介入，从而既节省了开发者的时间，又降低了IT部门的人力成本。

比如，我之前在Facebook工作的时候，采用虚拟机作为个人开发机。内部工具团队开发了一个基于共享机器池的开发环境服务系统，让开发者可以在网页上申请和释放机器。机器返还之后，开发环境服务系统会自动对它进行清理，配置之后再重新放回机器池中。这就使得开发者可以在5分钟之内拿到一套干净的环境。

而至于开发机器上的代码，这个服务系统可以克隆获取团队常用的代码仓，并定时拉取最新的代码。这就使得开发者拿到一台机器之后，只需要再额外拉取很少的代码就可以进行开发。

上面这种方法定制性很强，Facebook并没有开源。如果你准备进行这方面尝试的话，在机器的生成和配置方面，我推荐两种方式。

第一种方式，借助基础设施即代码（Infrastructure as Code，IaC）系统。比如，HashiCorp公司的Terraform工具。它支持声明式的方式快速产生自定义配置的机器，并在上面运行脚本进行配置。TerraForm使用插件机制支持许多底层平台，比如AWS、阿里云或者本地系统。

这种方式的优点是使用方便、功能强大，但前期投入大。

第二种方式是，提供机器镜像和配置脚本。通过镜像让每一台新机器拥有最基本的设置，比如CPU、操作系统、基本软件，然后通过脚本实现基本配置，比如网络设置、软件更新等。这种方式的优点就是，前期投入小。我在Stand时，就使用了这种方法，效果不错。不过它的缺点就是不够灵活。

规范化、自动化化本地检查

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

在这个方面，Facebook的方法是，把很多工具都放到一个网盘上，挂载到每台开发机器的Linux文件系统上，让开发者们不用安装就可以直接使用。

挂载共享网盘的方法非常方便，因为用户不用操心工具的升级。但如果你们的系统没有这样的网盘的话，也可以通过脚本让开发人员一键安装工具和完成配置，效果也不错。缺点就是软件更新比较麻烦，因为要通知用户手动更新或者设计自动更新机制。

至于检查中使用的工具，我们需要根据具体的语言和框架去选择。

建设并自动化代码入库前的检查流程

建设并自动化代码入库前的检查流程，是持续集成前的必要工作，也可以看作是持续集成的一部分。它对入库代码质量起到一个门禁作用，对提高质量用处很大。我认为，除了人数非常少的初创公司以外，其他开发团队都应该进行这个配置。

这个流程一般可以使用代码仓管理系统作为中心，直接使用或者通过钩子集成其他工具和系统来实现。比如，使用GitLab提供的GitLab CI/CD框架。基本方法是，在项目的根目录里创建一个.gitlab-ci.yml文件，来描述你的检查环境设置和步骤。你可以点击这个链接查看具体的方法。

在Facebook，这一步使用的是开源版Phabricator的一个内部Fork。Phabricator在工作流中使用单元测试和Linter的方法，你可以参考帮助文档。

以上内容就是持续开发的第一个原则，也就是规范化、自动化核心步骤。这个原则，可以帮助开发者尽量减少非开发工作的耗时，从而把更多的时间、精力投入到本职的开发工作中。接下来，我们再来看看持续开发的第二个原则，即提供快速反馈，促进增量开发，这样能及早暴露问题，从而保证将来的工作不会因为实现错误，或者方向调整而进行昂贵的修改。

提供快速反馈，促进增量开发

提供快速反馈，进行增量开发指的是，能够快速验证已经完成的开发工作，说白了就是边开发边验证。具体的工程实践主要包括以下3个：

灵活使用各种Linter和测试；
建设并优化沙盒环境；
使用实时检查工具。

接下来，我们分别看看这3个工程实践如何落地。

灵活使用各种Linter和测试

最常用的快速验证方法就是，提高运行静态检查和测试的方便性、灵活性。各种语言、框架都有自己的测试框架和Linter，这里我就不再一一列举了。接下来，我会与你分享两种通用的有效使用Linter和测试的方法。

首先，用命令行的工具来封装各种检查。命令行工具特别适用于自动化，方便开发人员使用。比如，我们可以通过命令行脚本，来实现简单的工作流。

举一个具体的例子，我希望团队在开发中，在运行公司提供的统一检查之外，还可以运行一些适应团队自身特点的检查，每个开发人员也可以添加自己希望使用的检查。这样就可以通过一个Shell脚本，依次调用公司的、团队的、个人的检查来实现，很方便。

其次，以服务化的方式，把这些检查的能力提供出来。比如，Facebook的基础平台团队提供了在云上运行单元测试的能力，并把这个能力通过服务的方式提供给开发者，以方便他们在自己的开发机器上调用。也就是说，开发者可以调用云上资源运行大量的测试而不占用本地资源，从而在运行测试的同时可以高效地进行开发工作。

建设并优化沙盒环境

沙盒也是一个高频使用的、提高质量的工具。开发者如果能够方便地在本地搭建沙盒进行验证，那么进行开发自测的频率和质量就会大大提高，进而提高产品质量。所以，我推荐你在沙盒环境的搭建上进行投入。

在沙盒环境搭建中，有两个常见的优化点：

本地构建。因为我们必须把改动构建成产品才能进行本地验证，而这个步骤通常耗时较长。我推荐的优化方法是，不要使用全量构建，尽量只进行最小范围的增量构建。
测试数据的产生。产生贴近生产环境的数据往往比较费劲，Facebook的做法是，开发环境直接使用生产环境的数据，不过这个方法比较激进，使用的公司比较少。另一个常见方法是，进行生产数据的导出并脱敏，然后使用到沙盒环境中。

使用实时检验工具

快速提供检查反馈，做到极致就是开发者无需手动触发检查，工具就会自动探测到改动、自动运行检查。最常见的是，IDE中的实时语法检查。我们可以花一些时间来配置IDE。另外，有些工具可以自动监视文件系统的变化，文件有变化时自动重启服务。这对于开发者来说，非常便利。

举个例子。使用Node.js进行开发时，nodemon就是不可或缺的工具，你只要在原来的命令前，加上nodemon就可以使用。比如，启动服务的语句是./bin/www，使用nodemon的形式就是nodemon ./bin/www。这样运行服务之后，如果你的文件有修改，nodemon就会自动重新运行。

你可以在下面这个动图中看到，在第一次保存时，有语法错误，nondemon重新启动失败；第二次保存时修复了语法错误，nodemon成功重启服务。通过nodemon，我减少了两次手动重启服务的繁琐操作。

图3 nodemon使用示例

类似的工具，SpringBoot有Spring-Boot-Devtools，你可以点击这个链接查看详细描述。针对Python，可以直接使用nodemon，这里也有一个链接供你参考。

如果你使用的框架、语言没有直接可以使用的工具，帮助你进行实时重启服务的话，可以使用类似watchdog/watchmedo的工具来实现自动化。比如

watchmedo shell-command \
 --patterns="*.py" \
 --command='python "${watch_src_path}"' \
 .

会监控所有的Python文件改动并自动重启。

提供快速反馈，边开发边验证，虽然只是一个简单的原则，但可以带来很多好处。最直接的收益就是，能够大大提高开发者对当前代码的信心，从而促进代码尽早入仓、尽早集成。

可能你也注意到了，代码集成越晚发现问题就越晚。这正是产品上线的最后关头合并混乱，产品质量差、返工率高的一个重要原因。所以，我建议在你的工作流程中，要尽量提高实时验证的能力。如果你这么做了，很快就会看到效果。

小结

在今天这篇文章中，我和你分享了两条持续开发的基本原则，来帮助开发者在代码入库前聚焦于开发工作：一是，规范化、自动化代码入库前的核心步骤；二是，提供快速反馈，帮助开发者边开发边验证，以促进增量开发。

我将今天的内容，总结为了一幅图，帮助你复习。

图4 代码入库前流程优化

这些原则和实践，是我根据自己的经验总结出来的。如果能直接适用于你的团队当然最好了，但我更加希望的是，你能从这些原则和实践的讨论中，理解它们背后的思路，从而找到合适的方法和实践，去优化代码入库前的流程中最需要优化的地方，让开发者能够真正聚焦于开发。

另外，我给你一个落地持续开发的小贴士：持续开发很适合用自上而下和自下而上相结合的方式来推动。因为开发者最了解自己工作的痛点，所以也能比较准确地找到需要优化的地方。在Facebook，很多工具和流程都是由开发者自发开发或者引入，后来逐步推广至团队和公司使用的。

所以我推荐，作为开发者，你可以自己抽一点时间优化自己的工作流程，自动化繁琐的工作；而作为管理者，你可以有意识地奖励这样的优化行为，并对适用于团队的部分进行推广。

思考题

最后，我来给你留下两个思考题吧。

在开发环境方面，你有没有尝试过在Docker里面进行开发？你觉得这种方式的好处是什么，弊端又是什么呢？
有些开发者喜欢写好一个比较大的功能单元，然后再一口气调测。你觉得这样做的好处和坏处，各是什么呢？

感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！

精选留言（15）

Y024 👍（14） 💬（1）
搭车推荐 IntelliJ 下的效率神器插件 JRebel，可以免手工重启，快速生效文件改动最新效果。 http://plugins.jetbrains.com/plugin/4441-jrebel-for-intellij
2019-09-04

技术修行者 👍（9） 💬（2）
1. 在开发环境方面，你有没有尝试过在 Docker 里面进行开发？你觉得这种方式的好处是什么，弊端又是什么呢？在之前的项目中有用过Docker来搭建开发环境，主要是一些中间件，例如后端数据库，solr，elk等。带来的好处是每个开发人员可以很快在本地搭建一套开发环境，彼此不会有冲突，不好的地方是Docker文件和镜像的维护，需要额外的精力。 2. 有些开发者喜欢写好一个比较大的功能单元，然后再一口气调测。你觉得这样做的好处和坏处，各是什么呢？这种做法的好处是写代码的时候可以更加专注，不好的地方是如果开发人员经验不够，这种方式就会变为调试驱动开发，反而会降低效率。不同的人会有不同的开发方法，我认为并没有普适所有人的方法，对于经验非常丰富的开发人员来说，怎样做都会得心应手。想一想纸带编程时期，哪有什么单元测试。
2019-09-13

追忆似水年华 👍（9） 💬（2）
我的开发方式可能比较另类，也比较不合规。公司买的是阿里云的 Windows 服务器，我现在常常都是直接通过远程桌面连接到服务器上，用 VSCode 开发前后端项目。前端用 Vue 全家桶，后端用 Node.js + nodemon，有改动之后立刻生效，最大的好处就是快，见效快 😂 之所以这样做，是因为我们公司就俩开发，一人负责一大摊子事，所以常常用各种野路子，怎么方便怎么来，哈哈。
2019-09-03

电线杆儿 👍（5） 💬（1）
@在开发环境方面，你有没有尝试过在 Docker 里面进行开发？你觉得这种方式的好处是什么，弊端又是什么呢？ #好处：A节约开发资源（多个开发人员共用一台docker开发机器，基于容器的资源隔离，抽象成多个开发机，提高单台机器的使用率）B快速搭建（新来的开发同事可以迅速创建一套或多套开发环境，基于镜像的一致性，保证环境创建过程中不踩坑，节约项目融入时间，同时，如果环境遭到破坏，或开发机不可用，可以迅速迁移到其他docker开发机）C轻松构建（很多时候出了搭建开发环境，还要搭建构建环境，通过docker提供的各种工具镜像，可以实现轻松构建自己的代码）缺点：A资源控制（对于性能要求高的服务，docker开发环境不如独立开发机性能高，虽然使用cgroup技术，但是docker还是会占用部分资源，对于独立性要求高的开发不利） B镜像构建（从传统方式到docker开发，需要构建基础镜像，代码、日志要持久化出来，通过sftp与IDE实现实时保存更新，基础镜像如果不够灵活，使用中会遇到问题）C需要了解docker命令（对没接触过docker的有一定的学习成本，并且查看日志，和启动服务等操作会变得跟传统方式不同）D网络限制（docker默认采用bridge方式提供小二层网络，比较抽象，对于需要独立IP资源的服务不友好，当然可以更改网络模式，但是需要整个公司的网络支持） @有些开发者喜欢写好一个比较大的功能单元，然后再一口气调测。你觉得这样做的好处和坏处，各是什么呢？ #好处A功能完整（这样一个功能可以根据项目需求周期来决定要不要该功能整体，如果较小的功能单元，后期可能会根据项目需求不断调整，经验不足就会对项目其他功能造成影响）坏处A需求见效慢（开发周期长，问题暴露滞后，不利于敏捷开发，可能会错过需求的最佳上线周期）B项目返工修复困难（单元大，设计的模块多，如果有BUG，修复起来很难）C不利于持续交付（如果要走持续交付路线，就要频繁上线，尽可能的优化上线流程，如果很久才开发一个功能并上线，即便有问题，也会觉得是个例）
2019-10-15

robincoin 👍（4） 💬（1）
怎么用线上的数据给开发人员进行开发测试呢
2019-09-15

我来也 👍（2） 💬（2）
监听文件变动并重启服务的事情我做过。当时是用lua开发的一个项目，lua本身还是支持热更新的，不需要重启进程. 我就在代码逻辑中定时扫描文件的变动情况，有过变动且最近5秒未再变时就热更新加载代码。（因为在网络传输文件的过程中，如果文件没传完，就开始了重载流程，就会出现语法错误。）这样我用vim在服务器上开发时，只要一保存，就触发了重载。另外我会单独开一个终端在tail日志，如果有问题，可以及时的发现。从这也能看出，我喜欢小步走。
2019-10-26

于小咸 👍（2） 💬（2）
如果工程比较大，编译需要很久的话，自动编译并重启服务是不是就不太合适了？
2019-09-02

Joe Black 👍（1） 💬（1）
发现解释性或者脚本型的语言做持续集成都比较方便，工具也多，但是像我们主要用C++的，好像没有这样的自动化工具链吧。老师对这个有经验或者建议吗？
2020-02-13

大河 👍（1） 💬（1）
Docker开发对于前后端没有分离的项目来说，前端会省去大量的搭建项目的时间，直接使用后端搭建好的环境，然后去提交代码进行联调。
2019-09-09

Marco 👍（1） 💬（3）
老师,有自动化的一套工具介绍吗?
2019-09-05

师傅又被抓走了 👍（1） 💬（1）
采用虚拟机作为个人开发机------这个比较高效，值得学习！
2019-09-04

许童童 👍（1） 💬（2）
老师，数据那一块怎么管理呢，比如初始数据
2019-09-02

Marvin 👍（1） 💬（1）
1、使用docker对前端或者硬件需求较苛刻的开发不是很友好，好处是开发环境搭建迅速零维护。2、较大功能单元，不利于单元测试，不利于后期维护，不利于工作拆解，不利于发现问题，好处是功能相对集中，持续开发时间较长。
2019-09-02

Geek_b43d27 👍（0） 💬（1）
据说facebook有很多的外包测试人员啊。所以是不是还是有很多测试的？
2020-11-09

oliver 👍（0） 💬（1）
采用docker作为个人开发机的话是否意思是在服务器上开一个docker？还是把docker模板文件拉下来到本机环境运行？如果用docker开发。是否只能用vim，无法用idea之类的IDE了？
2020-04-22