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

作者：Max Kanat-Alexander
发布日期：2017年4月4日

在工程生产力领域工作的人们常常会遇到两种困境：要么与他们试图帮助的开发人员发生冲突，要么花费很长时间开发某个项目，最终却发现这个项目毫无意义，因为没有人真正关心它。

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

错误的解决方式

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

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

个人挫败感

这种情况不仅会让公司产生抵制，对工程生产力工作者个人来说也极具挫败感。一般来说，人们喜欢完成事情，希望自己的工作能产生某种结果和影响。如果你做了一堆重构但没有人维护代码的简洁性，或者你编写了某些没人使用的工具/框架，那么最终你实际上什么都没做，这令人沮丧。

正确的解决方案

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

是的，你会实现这些目标（保住工作并让一些人高兴）……但可能只是暂时的。这种方法实际上非常短视。如果你合作的开发人员确切知道如何解决他们所处的困境，他们可能一开始就不会陷入这种困境。这并不总是正确的——有时你合作的是一群接手了旧代码库的新团队，但在这种情况下，通常这个新团队就是我所说的“生产力工作者”，或者你可能就是这些新开发人员之一。但即使如此，如果你只提供别人建议的解决方案，你最终会遇到我在《用户有问题，开发人员有解决方案》中描述的同样问题。

具体实施步骤

1. 了解开发人员的真实问题

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

在这个阶段，我使用一个技巧：一般来说，如果你直接询问开发人员代码复杂性在哪里，他们不太擅长回答。但如果你询问他们对所处理代码的情感反应，他们几乎总是有话要说。我会问这样的问题：“你的工作中有什么部分让你觉得很烦人吗？”“有没有某段代码一直让你感到沮丧？”“有没有代码库的某个部分你不敢碰，因为你觉得会破坏它？”对经理则问：“有没有代码库的某个部分开发人员一直在抱怨？”

2. 建立可信度

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

3. 渐进式改进

一旦通过处理这个初始问题建立了基本可信度，你就可以开始审视开发人员有什么问题，以及你认为最佳的解决方案是什么。通常，这不是你可以一次性实现的。这是另一个重要点——你不能一次性改变团队文化或开发过程的所有方面。你必须逐步进行，处理改变的“后果”（人们因为你的改变而生气，或者因为一切都不同了，或者因为你的第一次迭代效果不好），等待情况平息后再进行下一步。

4. 处理阻碍

有时你会遇到一些非常固执的人，你似乎无法取得进展。有时会有一些非常资深的人，他们要么非常固执己见，要么有点疯狂。在这种情况下，你能取得多少进展部分取决于你的沟通技巧，部分取决于你坚持的意愿，但也部分取决于你如何解决这种情况。

一般来说，你要做的是找到你的盟友，为你所做的努力创建一个核心支持小组。几乎总是，大多数开发人员希望理智占上风，即使他们没有说出来。

文化转变

当你通过渐进步骤提高生产力取得进展，并且对可能阻止你的情况有一定控制时，你该往哪里去？确保你的渐进步骤朝着根本问题前进。在某个时刻，你需要开始改变人们编写软件的方式来解决这个问题。

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

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

核心原则

记住，这整个过程不是关于“建立共识”。你不是要争取团队中每个人都完全同意你应该如何工作。而是要找出人们知道有什么问题，并给他们提供解决方案——这些解决方案他们可以接受，能够提高你在团队中的可信度，同时也能逐步解决代码库的真正根本问题，而不仅仅是迎合当下最响亮的开发人员需求。

如果你只能记住一件事，那就是：解决人们知道他们有的问题，而不是你认为他们有的问题。

最后思考

我谈了很多，好像你个人对整个公司或整个团队的工程生产力负责。情况并非总是如此——事实上，对于大多数在工程生产力领域工作的人来说可能并非如此。有些人负责工具的较小部分、框架、子团队等。关于解决真实问题的这一点仍然适用。实际上，我上面写的大部分内容都可以适应这种特定情况，但最重要的是你不要去解决你认为开发人员有的问题，而是解决一个（a）你可以证明存在且（b）开发人员知道存在的问题。

不要浪费你的时间。要高效。并改变世界。

-Max