作者 | Beyang Liu

译者 | 弯月

为什么在关于开发人员生产力的探讨中很少听到开发人员的声音？有很多自以为是的开发人员生产力专家，但似乎他们更感兴趣的是兜售某个概念，而不是准确地描绘开发人员的实际工作方式。正因为如此，我们只能看到一些高调的缩写字母、神奇的指标和方法论，却未能系统地思考这个问题。

开发人员擅长系统性的思考。我们的工作是系统建模和系统构建，我们经常绘制图表和示意图来说明这些系统的工作方式。但说到开发人员自己的工作情况时，画图的却是别人，而且他们的水平实在不怎么样。我怀疑我是唯一一个对生产力“专家”所说的话怀有警惕心理的开发人员。

难道我们不应该根据自己最直接的经验，建立有关自己的工作方式的思维模式吗？难道我们不应该画出能够实际反映最真实世界的图片和图表吗？下面，我们就来试试看。

内循环和外循环

SDLC（System Development Life Cycle，系统发展生命周期）是最常见的描绘软件开发过程的示意图。作为 DevOps 营销活动的支柱，SDLC 很好地展示了将代码投入到生产所涉及的各个阶段。然而，SDLC 未能定义软件开发中最关键的步骤：代码本身是如何被理解和编写的。

作为一名开发人员，回想自己的工作，我认为整个软件开发过程不应该只是SDLC展示的一个大循环，而是应该通过两个嵌套的循环来表示：

• 外循环与SDLC大致相似，每个冲刺、项目或产品发布都会经历一次。

• 内循环包括阅读代码、编写代码以及运行代码，每天我们都要重复这个过程，直至代码得到完善。

在开发的过程中，每次接触源代码，你就进入了内循环。内循环会在外循环的多个点触发，例如：

• 学习并理解需要更改的代码；

• 创建新功能或修复错误；

• 修复CI中出错的测试；

• 查看补丁或回复评论；

• 调试部署中出现的问题；

• 修复生产中的问题。

内循环很重要，它是创建软件的核心，但很多组织都会忽略内循环。

心流状态

内循环内部就是最佳状态：心流。心流状态指的是开发人员受到启发、浑身充满动力时，进入高度专注和超高生产力的状态。在这种状态下，开发人员心无旁骛，忘我地工作，而且能够享受大极大的乐趣。在这种状态下，开发人员能够随着思绪流动，行云流水般敲出一串串代码。为了进入理想的心流状态，我们需要重视内循环。

一旦达到心流状态，内循环就会加速。但是，开发人员需要很长一段不被打扰的工作，才能进入心流状态。一旦被打断，就会前功尽弃。作为开发人员，在努力完成工作的过程中，我最大的困扰便是经常被人打断。遗憾的是，许多开发人员的日常工作状态就像下面这张图一样：

破坏心流状态的因素可能来自内部，也有可能来自外部。

• 来自外部的因素包括开会或其他团队成员提问等。

• 内部因素主要是因为有其他方面的需求，例如需要了解如何使用某个库、需要设置工具或需要解决阻碍问题。

我认为，每一位程序员在生命中的某个时刻都曾经历过第一张图，那种高效投入的感觉让他们彻底爱上了编程。然而，许多开发人员在从事专业的编程工作时，往往会陷入第二张图所示的困境，这也是开发人员痛苦和生产力下降的根源。

开发人员生产力的单位

上面的图表揭示了一个重要的问题：“生产力”（上面图表中的 y 轴）到底是什么？许多开发人员可以描述出大致的感觉，但我们能给出更准确的定义吗？代码行数？提交次数？版本控制历史的综合指标？似乎所有这些指标都无法很好地衡量开发人员的生产力。

软件开发的核心是创新。与制造物理产品不同，软件开发的目标不是生产以前已经生产过的东西，而是生产新的、有用的知识。创新的原子单位是迭代，一个迭代就是内循环的一次循环。

开发人员生产力的原子单位应该是内循环的一次迭代。正确的单位不是代码行数，而是迭代频率。我们可以将这个数量单位称为“开发人员赫兹”。

进度是代码空间中的向量和

在物理世界中，速度有两个组成部分：方向和速度。与之类似，开发人员的速度也可以分解为方向和数量。

速度分量代表内循环的迭代速度。开发人员进入心流状态的次数越多，迭代的速度就越快，那么发布新功能或补丁的速度也就越快。

方向分量反映了所采用的技术方向，例如，你使用的是库 X 还是 Y。选择一个好的方向是快速取胜的关键。而选择一个错误的方向则可能意味着某些步骤需要返工。

正确的方向决策意味着选择的技术有助于尽快实现端到端系统的启动和运行。快速启动端到端系统可以降低整个项目的风险。而在指定的截止日期之前达到可发布的状态则意味着，你可以利用剩余时间进一步改进。我们不应该将目标视为一个点，而是应将其视为可接受结果的区域。先进入可接受的区域，然后再逐步改进。

个体的速度变化剧烈，但团队的速度更稳定

上述这些示意图将软件开发看作了一项个体工作。然而，实际上大多数软件都是由团队制作的。团队合作对于保证稳步、前后统一的进度至为关键。古语有云：一人独行走得快，与人同行走得远。

个体的速度往往不是很稳定。我们常常需要花费大量时间来熟悉代码，或者被外部因素扰乱个人的编程时间计划。但是，将每个成员的速度加起来，团队整体的速度就会更加趋于平缓。

如果某个团队的生产力持续低下，那么就应该想一想是什么因素导致团队所有成员的生产力下降。有时，这是由自然因素导致的，比如建立新季度计划的过程占用了过多的时间；而有时则是由一些更严重的原因造成的，比如士气问题、技术负债或缺乏明确的目标以及优先等级等等。

并发不等于并行

人们普遍认为，软件团队的生产力会随着团队规模的增长呈次线性增长，而且最终会下降。这个结论是根据并行计算和阿姆达尔定律得出的。计算机CPU数量增加一倍，程序的运行速度也会加快，但无法快至两倍。

对于计算机，并行速度减慢的主要因素是 CPU 需要切换上下文，并将工作分解为可独立处理的块。对于软件团队，主要因素是沟通开销、工作的依赖结构、领域专业知识以及上下文的获取速度。

我们可以将项目分解成多个可交付的成果物，成品是一个金字塔，我们必须按照由底到顶的顺序放置各个小块：

上图中不同的颜色代表不同领域的专业知识。如果你是具有多个领域专业知识的开发人员，则可以独自构建整个项目。或者，你也可以将这些任务委托给其他两个拥有某一个领域专业知识的开发人员：

两位开发人员的优势在于，他们可以并行构建单独的块，但仍然有一部分串行的工作需要彼此依赖（某些块必须按照一定的顺序摆放），而且他们还需要花费一定的时间熟悉代码，还会产生一定的沟通开销。

大家都希望两位开发人员完成项目的速度是一位开发人员的两倍，可惜这不过是一厢情愿的想法。实际上，我们甚至无法保证两个人的速度一定会有所提升。但是，如果分工良好，团队关系融洽，那么一定程度的速度提升是可以实现的。

然而，每增加一个人，协调任务的复杂性就会相应地增加。对于大多数团队而言，每增加一个人，收益就会大大减少。这就是为什么许多组织会优先考虑雇用和留住优秀的开发人员，而不是一味地扩大团队规模。此外，他们还会投资能够提高个人生产力并有助于协调大规模软件开发的工具。

真实反映开发人员的现实状况

在文本的开头，我说过，如果开发人员不谈论生产力的这些要素，那么我们的组织就不会意识到它们的重要性。

然而，更糟糕的是，一些人在想法设法地说服我们的组织相信其他因素更为重要。很多时候，我们会被塞进一个个框架内，他们认为软件创建不是一个发现之旅，而是一个缺乏想象力的小加工厂。没有人重视内循环（即理解与创建代码的循环），他们只会要求开发人员考虑机械的外循环。如果就连“跳转到定义”都有困难，那么强调“变更失败率”又有什么意义？作为工程师，我们没有将钱花在刀刃上，想法改善我们的工具，却一味地扩大团队规模，陷入经典的人月神话谬误，最终导致“三多”的败局：团队成员越来越多，代码越来越多，问题也会越来越多。

建立能够真实反映我们工作的现实，并尊重基本创造力的思维模式，不仅有利于每一位开发人员，而且对我们的行业和整个社会都有利。

*本文由CSDN翻译，未经授权，禁止转载。

原文链接：https://about.sourcegraph.com/blog/developer-productivity-thoughts