工程生产力提升之道：代码简洁性与团队协作策略

代码简洁性：有效的工程生产力

作者：Max Kanat-Alexander

发布日期：2017年4月4日

从事工程生产力工作的人员常常会与他们试图帮助的开发人员发生冲突，或者花费大量时间开发最终无关紧要的项目，因为实际上没有人关心这些项目。这是因为开发团队存在的问题并不一定是他们意识到的问题。

例如，你可能会进入一个团队，发现他们的代码极其复杂，无法编写良好的测试或轻松维护系统。然而，开发人员并没有真正意识到他们的代码复杂，或者这种复杂性导致了他们遇到的问题。他们意识到的是诸如“我们每月只能发布一次，整个团队必须工作到晚上10点才能按时发布”之类的事情。

当工程生产力工作者遇到这种情况时，有些人会试图忽略开发人员的抱怨，直接开始重构代码。这并不奏效，原因有几个。首先是管理层和其他一些开发人员会抵制你，使工作变得比必要的更困难。但如果仅仅是简单的抵制，你还可以克服。真正的问题在于，即使你做得再好，你也会变得不切实际，与公司脱节。你的管理层会试图劝阻你，甚至试图解雇你。当你已经在处理技术复杂性时，你不需要再与整个公司对抗。

随着时间的推移，许多工程生产力工作者对与他们合作的开发人员产生敌对态度。他们觉得如果工程师“只是使用我编写的工具”，那么一切都会好起来。但开发人员并没有使用你编写的工具，所以你的工具又有什么意义呢？问题在于，当你开始忽略开发人员的抱怨（甚至不去了解开发人员认为他们存在的问题）时，这本身就具有敌对性。也就是说，并不是一开始一切都很好，然后不知何故变成了大冲突。实际上，从一开始就存在冲突，因为你认为有一个问题，而开发人员认为有另一个问题。

而且，不仅仅是公司会抵制——这种情况对工程生产力工作者个人也非常令人沮丧。总的来说，人们喜欢完成任务。他们希望自己的工作有结果，有影响。如果你做了一堆重构，但没有人维护代码的简洁性，或者你编写了一些没有人使用的工具/框架，那么你最终并没有真正做任何事情，这是令人沮丧的。

那么你应该怎么做？我们已经确定，如果你简单地不同意（或不知道）开发人员认为他们存在的问题，那么你最终很可能会感到沮丧、士气低落，甚至可能失业。那么解决方案是什么？你应该只做开发人员告诉你做的事情吗？毕竟，这可能会让他们高兴，让你保住工作等等。

是的，你会实现这一点（保住工作并让一些人高兴）……也许只是一小段时间。你看，这种方法实际上非常短视。如果你合作的开发人员确切知道如何解决他们所处的状况，他们可能一开始就不会陷入这种状况。这并不总是正确的——有时你与一群接手旧代码库的新人合作，但在那种情况下，通常这群新人是我所说的“生产力工作者”，或者也许你是这些新开发人员之一。或者其他一些情况。但即使如此，如果你只提供别人建议的解决方案，你最终会遇到我在《用户有问题，开发人员有解决方案》中描述的相同问题。也就是说，当你从事开发人员生产力工作时，开发人员是你的用户。你不能仅仅接受他们对你如何实施解决方案的任何建议。这可能会让一些人高兴一小段时间，但你最终会得到一个不仅难以维护，而且只代表最吵闹用户需求的系统——这些用户可能不是你的大多数用户。因此，你有一个设计糟糕的系统，甚至没有实际用户想要的功能，这再次导致你无法晋升、感到沮丧等等。

此外，在开发人员生产力领域还有一个特殊问题。如果你只提供开发人员指定的解决方案，你通常永远无法解决实际的底层问题。例如，如果开发人员认为他们1000万行代码的单体二进制文件发布太慢，而你只花所有时间让发布工具更快，你永远无法达到良好状态。你可能会达到更好的状态（发布速度稍快），但你永远不会解决真正的问题，即二进制文件太大了。

那么该怎么办？不按他们说的做意味着失败，按他们说的做意味着只有平庸的成功。中间立场在哪里？

正确的解决方案与《用户有问题，开发人员有解决方案》非常相似，但有一些额外的部分。使用这种方法，我不仅解决了庞大代码库中的重大底层问题，还实际改变了重要工程组织的开发文化。所以当正确实施时，它效果很好。

首先要做的是找出开发人员认为他们存在的问题。不要做任何判断。四处与人交谈。不要只问经理或高管。他们通常说的与实际软件工程师说的完全不同。四处与直接从事代码库工作的许多人交谈。如果你不能接触到每个人，就从每个团队找技术负责人。然后，也要与管理层交谈，因为他们也有你想解决的问题，你应该了解这些问题是什么。但如果你想解决开发人员的问题，你必须从开发人员那里找出这些问题是什么。

在这个阶段，我使用了一个技巧。总的来说，如果你直接问开发人员代码复杂性在哪里，他们不太擅长表达。比如，如果你只是问“什么太复杂？”或“你觉得什么困难？”，他们会想一会儿，可能想出点什么，也可能想不出。但如果你问大多数开发人员对他们工作或使用的代码的情感反应，他们几乎总是有话说。我问诸如“你工作中有什么部分让你觉得很烦人吗？”“有没有一段代码一直让你感到沮丧？”“有没有代码库的某部分你不敢碰，因为你觉得会弄坏它？”对经理，我会问“有没有代码库的某部分开发人员总是抱怨？”你可以根据你的情况调整这些问题，记住你要与开发人员进行真正的对话——不仅仅是机械地读问题列表。他们会说一些你想了解更多细节的东西。你可能想记笔记等等。

这样做一段时间后，你会开始发现抱怨之间存在一个共同主题（或几个共同主题）。如果你读过我的书，或者你在工程生产力领域工作了一段时间，你通常会意识到问题的真正根本原因是某种代码复杂性。但这并不是我们纯粹寻找的主题——我们甚至不用和任何人交谈就能想明白。我们在寻找更高层次的东西，比如“构建二进制文件很慢”。可能会出现几个主题。

现在，你会有大量数据，你可以用它们做几件事。通常工程管理层会对你收集的一些信息感兴趣，向他们展示这些信息会让你在经理眼中变得真实，并有望促成一些共识，认为需要解决问题。这并不是这个解决方案的必要部分，但有时根据你对情况的判断，你会想这么做。

你应该用数据做的第一件事是找到一个开发人员知道存在的问题，你知道可以在短时间内（如一两个月）做点什么，并交付解决方案。这不必是改变生活的，也不必完全改变每个人的工作方式。事实上，它真的不应该那样。因为这个变化的重点是让你的工作可信。当你从事工程生产力工作时，你的生死取决于你的个人可信度。

你看，在某个时候，你需要能够解决真正的问题。而你能做到这一点的唯一方法是，开发人员觉得你足够可信，当你想要做出一些改变时，他们相信你并信任你。所以你需要先做一些事情来赢得团队的可信度。这不是一些巨大的、全面的改变。这是你知道你可以做的事情，即使有点困难。如果其他人尝试过但失败了，这会有所帮助，因为这样你也证明了事实上可以对这些混乱做点什么，而其他人可能无法处理（然后每个人对整个事情感到绝望，决定只能永远忍受混乱，无法修复等等）。

通过处理这个初始问题建立了基本可信度后，你就可以开始审视开发人员存在的问题以及你认为的最佳解决方案。通常，这不是你可以一次性实现的。这是另一个重点——你不能一次性改变团队文化或开发过程的一切。你必须逐步进行，处理变化的“后果”（人们因为你改变了什么而生气，或者因为现在一切都不同了，或者因为你的第一次迭代效果不好），等待情况平息后再进行下一步。如果你试图一次性改变一切，你基本上会面临反抗——这种反抗会导致你的可信度终结，所有努力失败。你会重新陷入上面两种无效解决方案的同样困境——士气低落或无效。所以你必须分步进行。有些团队可以接受较大的步骤，有些只能接受较小的步骤。通常，团队越大，你必须越慢。

有时在这个时候，你会遇到一个非常固执的人，你似乎无法取得进展。有时有一个非常资深的人，要么非常固执，要么有点疯狂（通常后者可以通过疯狂的人经常侮辱或无礼来判断）。在这种情况下你能取得多少进展，部分取决于你的沟通技巧，部分取决于你坚持的意愿，但也部分取决于你如何解决这种情况。总的来说，你想做的是找到你的盟友，为你所做的努力创建一个核心支持小组。几乎总是，大多数开发人员希望理智占上风，即使他们什么也没说。

当有人说他们想改进什么时，公开鼓励会有很大帮助。不要要求每个人都做出完美的改变——你在聚集你的“团队”，并验证代码清理、生产力改进等是有价值的。你有一种志愿者文化或开源项目——你必须非常鼓励和友善以促进其成长。这并不意味着你应该接受糟糕的改变，但如果有人想改进事情，你至少应该承认他们，说这很棒。

有时10个人中有9个都想做正确的事，但他们被一个吵闹的人否决了，他们觉得必须屈服或出于某种原因非理性地尊重这个人。所以你基本上与支持你的人群做你能做的，以这种方式取得你能取得的进展。通常，实际上甚至可以忽略那个吵闹的人，继续改进事情。

如果你最终被某个资深人士完全阻止，那么要么（a）你没有用正确的方式处理（意味着你没有遵循我上面的建议，存在沟通困难，你真正想做的事情对开发人员不利等等），要么（b）阻止你的人完全是疯狂的，无论他们看起来多么“正常”。

如果你因为做错了事而被阻止，那么找出什么对开发人员最有帮助，改做那个。有时这就像与阻止你的人更好地沟通一样简单。比如，停止敌对或争论，而是倾听他们说的话，看看是否能与他们合作。友善、感兴趣和乐于助人会大有帮助。但如果不是那样，你被一个疯狂的人阻止，即使有支持者也无法取得任何进展，那么你可能应该找另一个团队合作。与一个永远不会听道理、不惜一切代价阻止你的人对抗，不值得你牺牲理智和幸福。去一个你能有所作为的地方，而不是永远撞墙。

这并不是处理那种阻止你工作的人的全部知识，但它给了你基础。坚持、友善、组建你的支持者小组、不要做会导致你失去可信度的事情，并找到你能做的事情来帮助。通常阻力会随着时间的推移慢慢瓦解，或者不喜欢事情变好的人会离开。

假设你通过渐进步骤在提高生产力方面取得进展，并且你能控制任何可能阻止你的情况。接下来去哪里？确保你的渐进步骤朝着根本问题前进。在某个时候，你需要开始改变人们编写软件的方式以解决问题。关于这一点有很多要知道的，我以前写过或以后会写。但在某个时候，你需要开始简化代码。你什么时候能做到？通常，当你逐步达到某个点，有一个问题你可以可信地指出重构是解决方案的一部分时。不要承诺太多，也不要说你要开始绘制通过重构工作提高开发人员生产力的图表。管理层（和一些开发人员）会向你要各种东西，有时是不合理的要求，源于对你工作的不理解（或者有时是出于通过不合理要求阻止你的直接欲望）。不，你必须有一个问题，你可以说“嘿，重构这段代码会很好，这样我们可以更轻松地编写功能X”之类的话。

从那里开始，你继续在可能的地方提议重构。这并不意味着你停止处理工具、测试、流程等。但你对重构的坚持最能改变文化。你希望的是让人们认为“我们总是在处理事情时清理代码”，或者“代码质量很重要”，或者任何需要来获得你想要的文化。

一旦你有了一个事情在变好而不是变坏的文化，问题往往会随着时间的推移自行解决，即使你不再处理它。这并不意味着你应该在这一点停止，但在最坏的情况下，一旦每个人都关心代码质量、测试、生产力等，你会看到事情开始自行解决，而不需要你积极参与。

记住，这整个过程不是关于“建立共识”。你不是要团队中的每个人都完全同意你应该如何工作。而是要找出人们知道什么是坏的，并给他们解决方案，这些解决方案他们可以接受，提高你在团队中的可信度，但也要逐步解决代码库的真正底层问题，而不是仅仅迎合当时最吵闹的开发人员需求。如果你必须只记住一件事，那就是：解决人们知道他们存在的问题，而不是你认为他们存在的问题。

我最后要指出的一点是，我谈了很多，好像你个人对整个公司或整个团队的工程生产力负责。情况并非总是如此——事实上，对于大多数从事工程生产力工作的人来说可能不是这样。有些人处理工具、框架、子团队等的较小部分。关于解决真实问题的这一点仍然适用。实际上，我上面写的大部分内容可以适应这种特定情况，但最重要的是你不要去解决你认为开发人员存在的问题，而是解决一个（a）你能证明存在且（b）开发人员知道存在的问题。我合作过的许多工程生产力团队严重违反了这一点，他们花了多年时间编写开发人员不想要、从未使用、并且在设计者离开后开发人员实际努力删除的工具或框架。多么无谓的时间浪费！

所以不要浪费你的时间。要有效。改变世界。

• Max

分享 点击在Facebook上分享（在新窗口中打开） Facebook 点击在LinkedIn上分享（在新窗口中打开） LinkedIn 点击在Hacker News上分享（在新窗口中打开） Hacker News 点击在Reddit上分享（在新窗口中打开） Reddit 点击在Threads上分享（在新窗口中打开） Threads 点击在X上分享（在新窗口中打开） X

9条评论 留下回复

Effective Engineering Productivity | ExtendTree 说：

2017年4月9日下午12:00

… 阅读全文 …

回复

Ofer 说：

2017年4月9日下午6:14

你的帖子价值连城。通常个人/政治因素没有被考虑进去，尤其是在工程和软件开发中。这应该是每个人应该掌握的软技能集的一部分。

回复

Max Kanat-Alexander 说：

2017年4月13日上午7:51

是的，软件工程实际上根本上是一门人的学科。这最适用于编写和理解代码的是人这一事实，但