为什么你的经理喜欢技术债务（以及如何处理它）

工程师们知道，一个成功的软件项目不仅仅是表面看起来那么简单。当涉及到管理随着时间推移不可避免地演变的程序的复杂性时，重构和测试与功能同等重要。但是，当截止日期临近时，管理层往往会专注于功能。但是，如果这种技术债务开始堆积起来怎么办？

我有机会采访了 Caskey L. Dickson，关于他即将到来的 LISA15 演讲，主题是为什么你的经理喜欢技术债务以及如何处理它。Caskey 是一位拥有 MBA 学位的软件工程师，在在线服务开发方面拥有超过 20 年的经验。他看到了问题的两个方面，并将讨论工程师和经理如何共同努力，打造更好的软件产品。

导致技术债务产生的最常见原因是什么？

我想说最常见的原因是发布的压力，但这只说对了一半。我们承受着压力，需要以客户可见的方式展示进展和成果。即使是我们最善意的、最有效的快速生产软件的方法——我说的就是敏捷——也更强调交付用户可见的功能，而不是使软件可持续发展所必需的东西。我并不是说敏捷方法不能包含解决软件质量问题的积压工作项，只是说，如果没有额外的约束，很容易忽略这些项。事实上，这是故事的另一半。你的积压工作项应该包括与软件质量相关的、可量化的东西。“模块 X 在没有模块 Y 的实例的情况下无法进行单元测试，而模块 Y 的创建（或模拟）成本很高。” 修复类似问题属于你的积压工作项，但只有当开发人员将其放入其中时才会出现。如果产品管理拥有积压工作项，那么开发和运营方面的担忧永远不会神奇地出现。

当然，这引出了一个问题，这种压力来自哪里？很容易直接给出“产品管理”这个现成的答案，但情况比这复杂得多。没有哪个工程师想要交付不合格的产品。但作为一个物种，软件工程师是不耐烦且向前看的；我们想继续做下一件很酷的事情，不想“吃蔬菜”。我们需要作为一个开发者社区意识到，管理层直接走过来，用明确的措辞说“不要做测试覆盖率，我们现在就发布”的情况非常罕见。相反，我们每天都让质量下降一点，因为我们给自己施加了压力。我们每天都在对我们将要采取的纪律程度做出妥协。我坦率地承认，我曾看过一些东西，说过我应该重构它，然后决定我只是没有情感能量去承担它，因为所需的更改并没有那么大，所以我选择了简单的路线，只是为了确保功能不会滑到下一个 sprint。这些决定在一个开发团队中迅速累积。

在项目中管理技术债务的最佳方法是什么？是否有可能完全避免它？

我不敢说我知道最好的方法，但对我来说，归根结底是找到我们所说的技术债务的替代指标，然后使用这些指标将具体操作驱动到积压工作项中。技术债务对你意味着什么？作为开发人员，我们心中都有一个隐含的、模糊的想法，但它涵盖了我们称之为“-ility”的一系列事物：可维护性、可管理性、可扩展性等等。

我喜欢那句老话，你应该像下一个使用你代码的人是一个有杀人倾向的反社会者并且知道你住在哪里一样来编写你的代码。一旦你提出了一套你在代码中重视的东西，找到一种方法来衡量它并观察随时间的变化，这就是管理债务所需要的。我们有一个衡量功能的简单方法：每个 sprint 上的新闪亮功能的项目符号列表、产品发布公告、以盛大的宣传方式交付给用户的新功能和兼容性。这些都是衡量我们产品进度的指标。我们还需要衡量软件开发过程中缺失的要素——那些造成产品风险的缺失要素。

至于完全避免债务：绝对不可能。风险是一个连续体。一切都具有一定的风险，绝对值永远不会为零。此外，降低风险的成本呈指数级增长，尝试这样做是愚蠢的。作为工程师，我们有责任在可接受的风险量和为付出的努力交付的价值之间取得平衡。我们是这个过程的积极参与者，需要对所做的决定负责。而且，别自欺欺人——有些工程师比其他人更愿意接受更大的风险。有时我们的挫折不是来自管理层，而是来自我们对可接受风险有不同想法的同事开发人员。这就是为什么能够提出明确的风险衡量标准和一套商定的阈值如此重要。我认为需要发生的对话不仅是我们与管理层之间的对话，而且也是我们彼此之间的对话。

你认为为什么经理们不理解代码库中累积的技术债务的风险？

我认为说他们不理解有点牵强；更恰当的说法是，他们没有获得做出明智判断所需的信息。管理层的工作之一是就风险与结果做出明智的决策。我认为他们没有获得客观评估我们凭直觉感受到的东西的工具——即由于我们代码中的质量缺陷而承担的实际风险。

我不反对管理层承担知情风险。坦率地说，那是他们的工作。我担心的是，目前绝大多数组织都在对他们产品的实际质量承担不知情的风险。我希望我的电子邮件提供商或我的健康保险公司在产品质量方面承担的风险与我希望我最喜欢的在线游戏承担的风险完全不同。当然，每个人对这些产品的重视程度可能不同。开发人员需要找到以可量化和可操作的方式表达风险的方法。然后，我们可以采取积极措施来达到并保持我们都同意的质量水平。

在永无止境的紧急任务积压的情况下，程序员可以做些什么来让管理层理解重构的重要性？

程序员可以花时间量化他们的挫败感，并将其放入积压工作项中。质量也是一项功能。正如我的演讲将试图指出的那样，抱怨像技术债务这样的抽象概念太模糊了。不模糊的是可操作的想法，例如“我们的构建过程不够可重复”、“我们的单元测试覆盖率太低”、“冒烟测试运行时间太长”等等。有时，我们自己开明的解决方案会妨碍干净的可测试代码。如果你无法对模块进行冒烟测试，因为没有简单的方法来注入模拟依赖项，那么也许是时候重构组件及其依赖项，使其更具可测试性。这些都是可操作的项目，可以根据商定的质量标准将其放入积压工作项中。

开发人员需要做的另一件事是采取有原则的立场。你拥有比你想象的更大的力量，只要你能就代码质量问题的性质和程度提供合理的论据，你的经理就会成为你的盟友。你的经理不希望你的产品失败，就像你不希望它失败一样，但他们往往没有获得关于你的产品质量的量化信息。此外，当你的经理查看你的评估并表示不同意时，不要感到惊讶。我永远不会忘记我曾经做过的咨询工作，我审查了一个代码库，演示了他们生产服务上的一些基本 SQL 注入，但管理层认为修复它的成本不值得（它带来的风险）。作为一名年轻的开发人员，我感到震惊；十多年后，我才意识到他们的决定不仅仅是针对所讨论的软件。

管理层的工作是承担风险。因此，让我们为他们提供做出明智决策所需的信息。

你认为开源项目是否不太容易积累技术债务？还是他们也遭受同样的问题？

这是一个棘手的问题。任何项目都有可能背负技术债务。不同之处在于，开源项目一旦进入野外，就很少会积累大量债务。只有当你拥有一群被俘虏的开发人员，他们被任务是向代码库添加功能，并且他们没有选择参与时，你才能达到那里真正糟糕的代码质量水平。当一个项目是开源的时，当它变得难以处理时，开发人员就会简单地离开，项目就会死亡。

我认为成功的开源项目通过积极的重构、坚持代码审查等提高质量的行为、单元测试覆盖率标准以及一个不良代码库缺乏愿意贡献的开发人员的生态系统来管理他们的技术债务。愿意为开源做贡献的人口是有限的，并且在选择一个好的、干净的代码库和一个充满复杂性和晦涩难懂的意大利面条式代码库之间，大多数人会选择质量更高的项目。对于好的开源项目来说，这是一个良性循环，它隐含地惩罚了质量差的项目。一个好的 OSS 项目的黄金标准之一是贡献指南。你的内部组织的项目是否有贡献者指南？如果你的公司中的另一位工程师想为你修复一个错误，他们需要多长时间才能拥有一个可工作的开发环境？

话虽如此，我在非开源项目中经常看到的最糟糕的代码是在孤立的开发环境中。正如在政治中一样，阳光是最好的消毒剂。我知道我有一些副业和玩具项目，我不好意思让任何人看到。这就是为什么我完全爱上了“内部开源”的运动。在组织内使用开源方法使代码可见且可广泛编辑，只能改进事物。好的内部项目不仅可以作为应该做什么的典范，而且不好的项目也会获得可见性，并且更多的声音被用来解决内部存在的担忧。

当然，将内部开源与开发人员在项目之间自由移动的能力结合起来，你就找到了圣杯。再说一次，那些被迫负责关键业务的意大利面条式项目的产品经理就惨了。

如果你本月要参加在华盛顿特区举行的 LISA15，你可以在 2015 年 11 月 13 日星期五上午 11:45 观看 Caskey 的演讲。