【外评】我问过 100 位开发人员，为什么他们代码交付速度不快。以下是我了解到的情况

|

长期以来，我一直对开发速度这个话题非常感兴趣。在 Onboard AI，我们花了很多时间思考这个问题，这既是为了我们的内部运营，也是为了成千上万使用 Onboard 以更快速度交付代码的开发人员。

在我与工程领导者的交谈中，他们几乎一致认为，开发速度应与质量和合规性并列为首席技术官的三大优先事项。然而，首席技术官们：

  • 衡量开发速度的方法多种多样
  • 对于什么会拖慢开发人员的速度几乎没有共识。

当然，第 2 项因公司规模、文化、产品性质和团队组成而异。这是一个由年轻、精力充沛但经验不足的开发人员组成的团队吗？相对扁平的等级制度？团队是否各自为政？

我想，从基层或个人贡献者的层面来研究这个话题会很有趣。于是，我找到了来自这些公司的 100 名软件工程师→

  • Meta
  • Pinterest
  • Amazon
  • Paradigm
  • Heroku
  • Zeta
  • C3
  • Roblox
  • Humane
  • Stripe
  • Granular
  • Palantir
  • Segment
  • eBay
  • Splunk
  • DraftKings
  • Arista Networks
  • Zillow
  • Workday
  • Cisco
  • Stripe
  • Convoy
  • CrowdStrike
  • SpaceX
  • Google

……我只问了他们一个问题。

是什么阻碍了你们加快项目速度？

有两件事让我大吃一惊：

  • 几乎没有人需要考虑这个问题。大家都立即做出了回答，就好像我刚刚问到了他们心中一直存在、但从未被他人发现的痛点。
  • 令人惊讶的是，有很多人的原因与构建、编译和部署时间有关。开发人员非常讨厌等待。

答案多种多样，但我已尽我所能将它们大致分为几类和几小类。

代码库

依赖性错误

软件是一张由开源库组成的精美卡片。在很多软件中，源代码大部分都是由依赖关系组成的，而最令人头疼的错误往往都不是你的错。

前微软公司和前桥水公司的杰克列出了他在加快交付速度方面的第一大障碍–依赖性错误。

使用需要阅读大量旧的 stack overflow 链接和 Github issues 来解决随机的神秘错误

复杂的代码库

这是我最关心的问题。在过去的十年中，随着开发速度逐渐成为必要的竞争优势，几乎每个软件团队都饱受代码蔓延之苦。逻辑是正确的：

  • → 成长中的初创公司
  • → 必须加快交付速度
  • → 没有时间编写文档
  • → 随着公司的发展，早期的工程师会流失
  • → 新工程师需要在混乱中摸索。

亚马逊的 SDE 玛丽亚这样评价她团队的代码库：

>我们的服务中有很多文档没有记录，包括新功能记录不全、依赖关系信息不存在或已经过时，甚至连测试的最佳实践等基本信息也没有，因此我们在同步中浪费了大量时间来寻找正确的信息。

有趣的是，随着时间的推移，这个问题只会越来越严重

>没有人有时间更新文档，这就形成了一个恶性循环：功能越多，文档就越过时、越无用，这就意味着没有人更新或使用文档，如此循环往复。我们的很多文档已经好几年没有更新了

>微服务架构带来了额外的挑战，即在系统层面难以理解。

Palantir公司的高级工程师珍妮弗（Jennifer）描述了她在微服务架构中遇到的困难：

……对于一个同时触及许多部分的项目来说，了解所有不同的微服务如何相互影响始终是一个挑战。

当然，这个问题也会延伸到巨大的单体上。以下是 Stripe 高级工程师 Pranav 对此的看法：

>我们的 Ruby 代码多达数百万行。我们有一个名为 livegrep 的服务，它可以让我们快速搜索整个代码库，但有时还是很难找到东西，有时则会发现太多匹配项（例如，如果你要搜索一个键入结构，看看人们是如何使用它的）。

在大公司，问题往往在于对系统而非模块的理解。尤其是当堆栈比较分散时，这就更加困难。下面是 Meta 高级工程师达摩（Dharma）对这一问题的解释：

>我必须接触跨语言版本库。一部分代码使用 PHP，另一部分使用 Python 或 C++，在每种语言之间切换并查看它们如何交互，会增加完成功能的难度。

谷歌的工程师尼亚姆（Niam）说过，编辑代码库而不是代码才是最难的部分。

>我想说的是，深入理解构成系统的不同组件。

比如，由于代码库非常庞大，而你又必须设计一个功能实现，因此你必须确保你非常了解你的功能是如何与整个系统相匹配的，同时还要找到你需要修改的各个子系统的代码指针，以便让它发挥作用*。

流程

质量保证循环

质量保证流程是质量与速度之间的权衡。开发人员经常指责质量保证过于 “细致”，给开发周期增加了无用的重复。

泰勒曾在一系列高增长的初创公司工作过，现在也在经营一家公司，他是这样描述质量保证流程的：

>我为 QA 制定测试规范。质量保证部发现问题（因为质量保证部总会发现问题）
>两天后得到问题清单
>修复合并冲突，因为上次推送后有更多代码已经发布。加上上下文切换
>回到 QA*

在 QA 审查代码所需的时间内，潜在的上下文可能会发生变化，从而使变更更加复杂。

等待规格文档

随着团队的壮大，任何决策所涉及的利益相关者数量都会呈超线性增长。这必然会在工程师开始执行前引入额外的步骤、重新绘制和修改规范。

前康宏工程师 Brianna 在被问及为何不加快出货速度时，只说了这样一句话：

只是在等待规格批准

等待利益相关者的批准

对于亚马逊繁琐的利益相关者参与，拉吉有这样的看法，他认为亚马逊的过度参与造成了损害。

> 在亚马逊？开会、审批、与 10 个不同的利益相关者交谈，因为改变一个按钮的颜色会影响到 15 项微型服务

当然，利益相关者的蠕变会大大减慢开发速度。经典的 “厨子太多”。以下是乔希，前美达高级软件工程师

> 了解产品需求需要很长时间
> 过多的签字流程和过多的审核人员。

编写测试

开发人员对测试的抱怨基本上可分为测试不够和测试不佳两种。

测试不够–没有 E2E 测试意味着每项新任务都需要编写大量新的临时测试，无论任务有多小。

以下是一家金融科技独角兽公司的 SWE 格兰特对此的看法

> ……最大的问题是我们没有好的测试或好的类型，所以每当我想发布东西时，我都必须做大量的工作来进行 E2E 测试。

糟糕的测试会堵塞 CI/CD 管道，给部署过程增加不必要的时间。以下是 Splunk 高级工程师 Sadir 关于哪些因素会拖慢他的工作进度。

我的理由是，运行管道需要大量时间，而且为了确保测试用例对代码的正确覆盖，有时我们需要这些管道花费适当的时间，这反过来又拖慢了我们的速度。

工具

部署/构建速度

这一点让我感到非常惊讶，因为我没想到有这么多人深受其害。我有一套关于闲置时间毒性的理论–闲置时间不是休息时间，但也不是生产时间。等待部署正是如此。

部署时间往往长达数小时。下面是 Arista Networks 的开发人员 Aryan 对拖慢他工作的原因的看法：

> 我的工作需要 3-4 个小时才能完成一个完整的构建，并在其上运行 PR 的所有测试，即使经过大量优化，这些测试也需要 1 到 3 个小时才能完成。
因此，即使是很小的改动，比如修改文件名，也会很繁琐

Stripe 高级工程师雷蒙德（Raymond）如是说：

CI/CD 管道缓慢

人

等待 PR 审核

大多数现代软件公司都有某种版本的代码审查流程，同行或有时是高级工程师会在合并前对代码进行审查。通常情况下，工程师将此视为次要责任（主要责任是编写新代码）。自然，这就意味着代码需要花费过多的时间进行审查。

Stripe 前高级产品工程师 Roman 在谈到 PR 审核时这样说道：

> 我想说的是，整个公关流程，即使进展顺利，你也要等到有人批准了公关才能继续。

在有些公司，问题则出在另一端–过度的公关审查耗费时间。

> 我认为在我的工作中，无法更快交付的首要原因就是繁琐的代码审查过程。其他工程师会对代码进行细致入微的审查，指出最微小的缺陷，有时会增加交付的难度。

其他工程师似乎只是为了审查而审查。有时我不能更快地发布代码的另一个原因是，我需要高级工程师的批准。我在一个产品团队中工作，因此我所做的每一个改动都非常关键，可能会造成灾难性的后果，这导致高级工程师（L6 级人员）有时会仔细检查代码。

这是一个反复出现的主题，而且有规律可循：

  • 大多数工程师都认为，等待公关审查的时间+修改的时间是必要之恶。
  • 大多数人还认为，吹毛求疵的公关审查往往是以下原因造成的：
    • 个人恩怨/偏见/偏袒。
    • 开发人员空闲时间太多。
    • 激励机制错位（彻底审查代码是件好事，但并不意味着每个小毛病都要挑剔）
  • 从工程师们对公关流程的普遍看法来看，我建议工程领导审核其团队的公关实践。在这方面可能会损失一些时间，而这些时间是很容易恢复的。

范围蠕变

C3.ai 的前工程师乔希在被问及是什么拖了他的后腿时，简明扼要地回答道

项目经理引起的范围蠕变。

人类总是喜欢在去机场的前几分钟，把最后一刻需要的东西塞进行李的缝隙里，这在软件公司表现为范围蠕变。它缓慢而肯定地推后你的发布日期，每一次增量都让人觉得是微不足道的任务，但总的来说却大大增加了团队的速度。

要求不明确

不明确的需求拖慢开发人员的进度并不奇怪。根据我的谈话，这大致有三个原因：

  • 生产力与信念密切相关。目标和成功状态定义不明确=信念不足=动力不足=工作效率低下。
  • 当你感觉脚下的土地坚实时，你就能跑得更快。
  • 如果管理层不清楚应该建设什么，开发人员就不会信任管理层。当开发人员觉得他们对应该建设什么没有影响力时，更是如此。

Justine 是一位前 Meta 软件工程师，她在谈到自己所在组织的需求不明确时这样说道。

了解产品需求需要很长时间
> 过多的签字流程和过多的审核人员。
> 管理不善。

会议过多

这是开发人员最关心的问题，这一点不足为奇。考虑这个问题的常见框架是 “制造者 “日程表和 “管理者 “日程表。管理者可以在一天中分散开会，因为他们的任务可以在会议间隙分块完成。制作是一项深层次的工作–它需要大量不间断的创造性时间。

问题通常表现为管理者管理制作者的时间，无意中将管理者的日程表强加给制作者。

亚马逊的 SDE 玛丽亚认为，过多的会议是浪费时间的首要原因。

……为了找到正确的信息，很多时间都浪费在了同步会议上。

激励

Diane 是 Meta 公司的一名前工程师，她在谈到拖累自己的首要原因时这样说道：

>最诚实的回答是我在做广告
>那是一个非常古老/复杂/庞大的堆栈（已编辑）
>我不明白
>我在年轻团队的朋友们似乎更快乐，而我却很痛苦

这一点不足为奇。优秀的工程师通常都是非常聪明的人，因此他们希望从事有趣、有启发性的工作。有些项目通常更有趣，而有些项目往往进展更快。

这其中的另一个原因是，付出更多的努力却得不到回报。亚马逊 SDE 罗汉（Rohan）这样说道：

也是动力。我懒得磨，因为反正我的晋升速度也是一样的，所以如果我超出了预期，多花几个小时又有什么意义呢？

在大公司，个人影响力几乎无法衡量。这意味着两件事：

  • 很容易侥幸逃脱惩罚。(Rest and vest）。
  • 超越自我很难得到认可和奖励。

结果是什么？很多人碌碌无为，很少有人超越期望。

结论

人们普遍认为，开发速度是一项至关重要的业务优势。优秀公司的生死取决于它们的发货速度。从我收集到的模式来看，规模较大的公司通常在快速发货方面处于劣势。有时理由充分，有时则不然。

它们本质上更倾向于规避风险，因为失误会带来严重的代价。这表现在大量的公关审查、质量保证和规划等方面。
他们更有可能召开过多的会议，并推动制造商按计划运行。

这也许就是生命的轮回–正是因为早期初创企业的灵活性更强，才使他们能够打乱缓慢的现有企业。如果他们成功了，他们自己也会成为行动迟缓的现任者，等待着被后起之秀颠覆。

现在来看一些图表。

你们的代码交付速度为什么不快（可视化）？

我不得不酌情为每条信息指定一个类别，以下是我的最佳尝试。等待利益相关者批准的复杂代码库是阻碍开发速度的最大因素。尽管如此，还有一个重要的长尾原因。原来，开发人员有很多抱怨。

将近三分之一的受访者提到了公司或团队的具体问题，因此我决定略去这些问题，以保持其普遍实用性。(例如：Workday 的工程师觉得他们的专有编程语言拖慢了他们的工作。这很吸引人，但几乎与其他公司无关）。

为了使图表更易读，我制作了一个更简洁的图表，将这些原因归纳为 7 个主要类别，但忽略了一些长尾原因。

  • 流程
  • 人员
  • 代码库
  • 开发运维/工具
  • 激励
  • 调试
  • 文档

人员和流程通常是相关的，这两者加在一起占所有受访者的近一半。

免责声明：为保护隐私，调查参与者的姓名均已更改。

本文文字及图片出自 I asked 100 devs why they aren’t shipping faster. Here’s what I learned

你也许感兴趣的：

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注