代码简洁性

有效工程生产力
作者：Max Kanat-Alexander
2017年4月4日

从事工程生产力工作的人常常会与他们试图帮助的开发人员发生冲突，或者花费很长时间完成某个项目，最终却无关紧要，因为没有人真正关心它。这是因为你看到开发团队存在的问题并不一定是他们已知的问题。例如，你进入团队后可能发现他们的代码极其复杂，因此无法编写良好的测试或轻松维护系统。然而，开发人员并没有真正意识到他们的代码复杂，或者这种复杂性导致了他们遇到的问题。他们意识到的是类似“我们每月只能发布一次，整个团队必须工作到晚上10点才能在发布日完成发布”这样的事情。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-Max