代码简洁性

有效的工程生产力

2017年4月4日 by Max Kanat-Alexander

通常，从事工程生产力工作的人要么与他们试图帮助的开发人员发生冲突，要么花很长时间从事某个最终无关紧要的项目，因为没有人真正关心它。

这种情况的发生是因为你看到的开发团队存在的问题不一定是他们知道存在的问题。例如，你可能会进入团队，看到他们的代码极其复杂，因此无法编写良好的测试或轻松维护系统。然而，开发人员并没有真正意识到他们的代码很复杂，或者这种复杂性导致了他们遇到的问题。他们意识到的是类似“我们每个月只能发布一次，整个团队必须工作到晚上10点才能在我们发布的那天完成发布”这样的事情。

当工程生产力工作者遇到这种情况时，有些人试图忽略开发人员的抱怨，直接开始重构代码。这并不真正有效，原因有几个。首先是管理层和其他一些开发人员会抵制你，使完成工作比需要的更困难。但如果只是简单的抵制问题，你可以克服它。真正的问题是你将变得不真实，与公司无关，即使你正在做任何人见过的最好的工作。你的管理层会试图劝阻你完成工作，甚至试图摆脱你。当你已经在处理技术复杂性时，你不需要同时应对整个公司的反对。

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

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

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

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

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

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

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

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

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

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

现在，你会有一堆数据，你可以用它做几件事。通常工程管理层会对你收集的一些信息感兴趣，向他们展示这些信息会让你对经理来说变得真实，并希望促成一些共识，即需要针对问题采取一些措施。这并不是这个解决方案的必要部分，但有时你会想这样做，基于你对情况的判断。

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

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

一旦你通过处理这个初始问题建立了基本的可信度，你就可以开始查看开发人员有什么问题，以及你认为最好的解决方案是什么。现在，通常，这不是你可以一次性实施的东西。这是另一个重要点——你不能一次性改变团队文化或开发过程的一切。你必须逐步进行，处理变化的“后果”（人们因为你改变了某些东西而生气，或者因为现在一切都不同了，或者因为你的第一次迭代变化效果不好），等待它平静下来，然后再进行下一步。如果你试图一次性改变一切，你基本上会面临一场叛乱——一场会导致你失去可信度和所有努力失败的叛乱。你会重新陷入上面两个无效解决方案的相同困境——士气低落或无效。所以你必须分步进行。有些团队可以接受更大的步骤，有些只能接受较小的步骤。通常，团队越大，你必须走得越慢。

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

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

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

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

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

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

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

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

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

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

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

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

-Max

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

9条评论 留下回复

有效的工程生产力 | ExtendTree 说： 2017年4月9日下午12:00 […] 阅读全文 […]

回复

Ofer 说： 2017年4月9日下午6:14 你的帖子价值千金。通常个人/政治因素没有被考虑进去，尤其是在工程和软件开发中。这应该是每个人都应该掌握的软技能集的一部分。

回复 Max Kanat-Alexander 说： 2017年4月13日上午7:51 是的，软件工程实际上从根本上是一门人类学科。这最适用于编写和理解代码的是人这一事实，但