工厂的重组：是时候给软件工程师提供更多的工具

本文最初发表于作者个人网站，经原作者 Erik Bernhardsson 授权，InfoQ 中文站翻译并分享。

在开发人员中流行的态度是，抱怨我们的工具和东西有多烂。或许我是个乐观主义者，因为我的观点完全相反！1999 年，我得到了第一个软件工程师的工作，在过去的二十年里，我见证了软件工程的变化，使我们的工作效率提高了好几个数量级。仅举一些我曾经做过或者接近做过的事情的例子：

• Spotify 使用 C++ 构建了一套完整的 P2P 架构，用于向听众分发流媒体音乐，而这在今天已经是一个微不足道的问题（将数据放在 CDN 上）。

• 过去，我常常编写自定义的 mapreduce 作业，以获取基本的统计数据，然后等上几个小时才能完成。现在，这些是数据仓库中的 SQL 查询，只需几秒钟就能运行。

• 以前我开过一家网店，用了一个星期才实现信用卡支付。而现在用 Stripe，15 分钟就可以搞定。

更不用说开发过程中的变化了：

• 在这个行业中，单元测试是非常罕见的：我第一次遇到它是在 2006 年谷歌工作时。

• 在 git 刚刚出现时，git-flow 是盛行的工作流，很多和我一起工作的开发人员都会花很多时间（比如 20~30%）来重新构建基础。

• CI 系统很脆弱，CD 基本上不存在，部署是可怕的手工事务。

这些只是例子——我可以说上一整天。正如关于软件生产力的经典论文《没有银弹》（No Silver Bullet），这些东西本身并没有什么显著的进步。但生产率的增长是累加的，并且是以对数尺度累加起来的，也就是说，当你的时间尺度是几十年的时候，我们看到的将是数量级的增长，这不是没有道理的。

（注意：在本文中，我将使用“工具”一词来指代所有种类的东西：框架、库、开发流程、基础设施。）

对软件永无止境的需求

对于世界有一种极为粗略的分类：

• 有些东西有很好的软件。

• 有些东西有平庸的软件。

• 有些东西没有软件。

到目前为止，这一点已经很明显了，因此我继续说下去：如果有一种能力，能够在零成本的条件下，瞬间生产出无限量的软件，那么最后两种分类将不再存在。平庸的软件之所以存在，是因为有些人没有能力雇佣更好的工程师，或者他们没有时间，或者其他什么原因。没有软件的东西……算是万能的吗？我是说，为什么你的鞋子里没有内置计步器？为什么会计里的标记还能生成 PDF 发票，并通过电子邮件发送给客户？怎么不……我还能说更多。

很明显，我们一直在向这个方向努力，而我的观点是，仍然有很多东西可以使用软件。那为什么还没有发生呢？由于一些人做出经济决策，他们认为构建这些软件的成本太高。雇佣工程师、培训工程师以及把事情做好，都需要金钱和时间。那么，我们如何看待这种成本呢？

软件工程师的供求关系

现在回到我的观点，即软件工程师的生产率会随着时间而提高。用经济学术语来说，这意味着单位时间内的产出价值将增加。就需求而言，这意味着构建软件的成本降低了。过去需要 1000 个小时才能完成的事情，现在需要 100 个小时就能完成。

如果需求是固定的，那就意味着大规模失业和工程师工资的降低，但需求并不是固定的！正如我前面所暗示的那样，构建软件的成本降低意味着新的机会的出现。以前，构建你的小工具不值得花费 1000 个小时的工程努力，但花费 100 个小时还是值得的。这里面存在着巨大的潜在需求。你甚至可以支付工程师更多的时薪。

这些情况可以同时发生：

• 开发更多的软件。

• 为软件工程师加薪。

• 软件工程师的数量越来越多。

这可能有悖于直觉，因此值得拿它和固定需求进行比较。假设发明了某种工艺，使纸尿裤工厂的产量提高了 10%（保持所有成本不变），并且这项发明可以立即提供给所有纸尿裤制造商。结果会是什么呢？纸尿裤市场将出现暂时性的供过于求，市场将趋于一个新的平衡点，即供应量萎缩以满足需求。在这个过程中，一些工厂将会关闭，纸尿裤的价格也将会下降。

软件工程师的不同之处在于，当成本下降时，需求就会增长。以前，你阿姨的牙科诊所没有网站，但现在值得拥有一套在线预约系统。你孩子所在的学校突然出现了一个应用程序，可以向家长发送更新的信息。我不知道——我的观点是，随着价格的下降，会有更多的需求出现。

这种情况不仅发生在整个经济领域，也可能发生在微观尺度上。如果你有一个数据科学家团队，而你引入了一个工具，使当时的生产力提高了 2 倍？很好。你只是增加了一倍的投资回报率，你应该去雇佣更多的人。我从来没有见过一个公司的数据科学家会没有工作了：总是有更多的东西需要分析。

这种情况会一直持续下去吗？我想在某种终极状态下，我们会遇到类似奇点的东西，软件本身制造软件的速度如此之快，以至于需求不能随着供应而增长。在这个时候，我会为软件工程师的失业担忧。但是我想，在未来的几十年中，我们会看到越来越多的软件工程师出现在我们的视野中。

如何成为软件工程师

很明显，软件作为一个领域的发展和薪资的增长，本身就吸引了更多的人进入，但是我认为还有一件事在发生。

几十年前，软件工程非常困难，因为你必须从头开始构建一切，并解决所有这些基础问题。你需要存储空间来为 100 万并发用户提供服务？阅读关于一致哈希算法，CAP 定理，CRDTs 之类的论文，卷起袖子，准备好迎接 10 万行硬核 C++。

如今，这些问题大部分都已经解决了，你可以使用现成的工具来解决这些问题。但那并不容易！正如我之前提到的，这里没有银弹，只有数以百万计的工具，你需要知道如何根据最佳实践来组合这些工具。但是我们知道这是另一种困难。

数十年前的软件工程倾向于那些能够把复杂软件从原子中拼接出来的深奥抽象思维者。在我看来，今天的软件工程更像是一门手艺：更多的是了解应该使用哪些工具来完成哪些工作。我是说，它仍然非常偏爱那些更深层次的抽象思维者，但是相对来说，这种技巧的差异比过去更小。

我认为这改变了供给侧的方程式。现在，阻碍软件工程师成长的因素已经变得不同，这为他们打开了更大的人才库。这样就有了新的供应，这意味着更多的软件将会诞生。

知识工厂中的软件工程师角色

对于公司来说，构建软件过去是，现在仍然是一项非常昂贵的工作。在一般的公司里，你的积压工作仍然无休止地存在。工厂的软​​件方面通常仍然是公司的瓶颈。

当你有一个部件制造商是制造工厂的瓶颈时，你该怎么办？你要确保瓶颈在任何时候都能得到充分利用。这意味着你可以集中小部件制造商的资源管理：你可以控制输入，并且尽力确保按照什么顺序生产哪些部件。

大多数公司的运作方式仍然大致如此。但是，那些（在我看来）拥有高效率工程团队的公司，他们的组织方式略有不同。他们倾向于分散优先级，并直接与产品和业务利益相关者一起进行紧密的迭代。如果某个资源不再是瓶颈，你就可以通过在许多不同的团队中分配资源，从而显著提高迭代的速度。我的意思并不是说管理要分散开来，要说清楚。我是说要把积压的工作分散到小团队中，直接根据业务需求来做。

你没有一个营销团队在这个模型中把一些东西放进了工程团队的积压中。你有一个跨职能的团队，他们拥有自己的收购权，其中一些人是传统的营销人员，一些人是工程师。你可以想象得出一家典型公司的几乎所有功能：客户支持、财务或任何其他。

在历史上，有个很有意思的类比，那就是为什么电力用了那么久才改变了制造业。在蒸汽机时代，工厂是围绕着万能的蒸汽机的动力分配而建造的。能源是宝贵的资源，因此很自然地认为制造工厂就是围绕着能源分配而建立的。电力改变了这一点，也改变了分散的能源生产方式，但是制造工厂要重新调整和利用这种方式，真的需要很长的时间。

（注 1：这个类比并不十分恰当，因为蒸汽动力不仅是一种宝贵的资源，而且难以制造出小型蒸汽机。）

（注 2：我所链接的文章的主要观点是，创新往往需要时间才能释放生产力，因为那些最初尝试使用新技术的人常常试图将创新转变为传统结构。比如：互联网首先创造了通过邮件发送的 DVD，但是真正的互联网原生创新是流媒体视频。）

知识工厂的瓶颈

对于提高工程师工作效率的工具，我已经谈了很多，但是还不够全面。显然，还有很多非技术人员使用这些工具来做他们自己的事情，这是好事！但是，我也看到很多工具是为了让人们不必和工程师合作。为什么这样说？原因是多方面的。

1. 迭代速度：向工程师解释所需成本，使得它不值得去做。

2. 工程资源不到位（或过于昂贵，或者其他）。

3. 需要的只是工程师的一小部分，但是市场并不存在。

4. 构建一些东西需要一些特殊的领域知识。

5. 工程师们很怪异，而且身上有怪味。

好吧，最后一个理由只不过是一个愚蠢的玩笑。但我认为其他的观点已经涵盖了大部分。

在这些理由中，我认为第一个原因（迭代速度）是 100% 合理的。举个例子，我鼓励所有的业务人员学习 SQL，这样他们就可以自己运行查询。

我觉得不幸的是第二个原因（工程资源不到位）。很多人都会遇到这样的情况：人们手动发送带有宏的 Excel 文件，每天早上将新数据复制粘贴到电子表格中，或者其他类似的事情。这有时被称为 “影子 IT”。在拥有专业工程资源的情况下，构建和拥有这些东西的总成本可以大大降低。

但事实是，没有工程师在制造技术，这证实了对工程师的需求。许多公司的工程师是无法满足需求的。因此，随着时间的推移，通过更好的工具能够满足更多需求。站在工程师生产力前沿的公司，很可能不太注意到这些问题：工程师会尽早介入并致力于解决商业问题。

第三个原因（部分资源）对小公司来说也许是对的。假如你是一名牙医，你不会雇一名工程师为你建立一个预约系统。幸好，他们得益于全行业产出的增加：一个全新的牙医软件生态系统可供购买（因为构建它要便宜得多）。

最后一个原因（特殊知识）有些道理。我们常常看到业务人员建立人工工作流程，然后由工程师来完成，并将其自动化，作为一种一线的技术攻关，以实现基本的原型。相应地，随着去中心化程度的加深，工程师们将会越来越多地积累专业知识。比如，许多公司为人力资源和财务团队提供了专门的数据科学和数据工程资源。

巨大的生产力不平等

其中一个有趣的推论就是，它形成了一个积极的反馈，一些公司甚至会更落后于人：

• 缺乏新工具的采用意味着落后于利用这些工具的公司。

• 软件工程师的高薪意味着这些公司将被挤出高端招聘市场。

• 如果不能对工厂进行重组，就意味着迭代速度的降低。

• 工程师的缺乏意味着一种诱惑，即采用工具而不使用工程师来构建技术，而相关的成本要大得多。

在合同中，处于这一前沿的公司将会看到他们的软件工程师的生产力激增，迭代速度提高。

我在抵押贷款行业呆了六年，我已经非常清楚地看到这些趋势正在我的眼前上演。最大的落伍者都在竭尽所能地机器人流程自动化和“管道胶带”，以及现成的 POS 和 CRM 软件。稍微好一点的公司都有自己的工程团队，但是似乎没能将流程工厂重新调整成一个技术驱动的公司。我的公司 Better 隐含着对我在这篇文章中提到的一切的赌注，或许还有其他一些趋势。

结束语

我认为这些词汇可以简洁地用于因果关系图：

很明显，这个理论并不完全适用于软件。其他趋势如因特网抹掉了物理护城河，软件创造了更大的规模经济效益。但是我认为，这能解释许多问题。

如果一种理论不能做出预测或政策建议，那么它就不会有任何作用，因此我敢打赌：

• 现在是软件工程师的好时机。

• 软件工程师的工具市场将继续增长。

• 许多“传统”企业的生产力提升将落后于其他企业。

• 新进入者将威胁到这些公司，并在很大程度上取得成功。

• 每家公司都应该思考如何重新调整构建技术的方式，关注去中心化和更高的迭代速度，将工程师嵌入到整个工厂中去。

• 从长远来看，公司采用工具的唯一目的是在没有工程师的情况下构建技术，这并不是一个好主意。

• 软件工程师应该全心全意地采用能够提高工作效率的工具：这让他们更有价值。

• 拥有高生产力的工程团队的公司将拥有更快的工程团队增长（因为雇佣更多工程师的投资回报率更高）。

这篇文章融合了我头脑中以前无关的观点。有一些也许对读者非常明显，有一些则不然。但愿你能在后者中找到一些有用的东西！

作者介绍：

Erik Bernhardsson，是 Better 的首席技术官，Better 是一家正在改变抵押贷款方式的初创公司。他写了很多代码，其中一些最终被开源，比如 Luigi 和 Annoy。他还参与组织了纽约机器学习会议。

原文链接：

https://erikbern.com/2020/12/16/giving-more-tools-to-software-engineers-the-reorganization-of-the-factory.html