技术债务：我们需要更好的沟通，而不是更好的隐喻

技术债务这个比喻，对我们这个行业来说并没有多大用处。它原本是为了帮助我们与业务人员沟通，并就软件项目做出更好的决策。但它基本上失败了。部分原因在于，业务人员并不惧怕未来的利息支出。

在商学院，我学到了杠杆的力量：它是什么，如何获得它，如何衡量它，以及如何管理它。债务是一种工具。我的商学院同学们对杠杆和债务习以为常。所以，当程序员向业务人员抱怨技术债务时，业务人员却漠不关心。他们怎么会关心呢？这个比喻具有误导性；技术债务与金融债务只是表面上的相似。

利害攸关

我注意到，商人往往更善于说服程序员为了短期利益而损害其代码库的长期健康，而程序员则更善于说服商人拥有健康、混乱和低技术债务水平的软件的重要性。

这确实很不幸，原因有三：

1. 一旦你的项目变得一团糟，就很难清理它（在很多情况下甚至是不可能的）
2. 为了短期利益而走捷径或制造混乱的决定，从长远来看往往并非最佳选择。如果企业人士真正理解这些捷径的风险和成本，他们可能会做出更好的选择。
3. 维护和扩展一个充斥着糟糕代码的软件项目是一件令人沮丧、身心俱疲的工作。许多程序员为了摆脱低质量代码而辞职——这太严重了。

无论你的项目有多少技术债务，你总有可能让情况变得更糟。你总是会面临来自内部和外部的压力，比如在这里走捷径，在那里避免重构，或者在没有自动化测试的情况下发布新功能。

因此，我们需要更好地与业务人员一起捍卫代码。他们的职责是维护业务目标，而我们作为程序员的职责是维护代码。不相信？请阅读：软件工程道德规范和专业实践

如何倡导该准则

你需要让公司里的利益相关者了解软件开发流程。除非你确保他们理解走捷径的利弊和风险，否则你的工作就不算完成。我将在本文的剩余部分分享我的策略。

找到一个吸引商业人士关注你公司如何创建和维护软件的契机

你需要让业务人员参与到你的流程中。他们越能理解你的困难和挑战，就越好。

呼吁效率

你很难找到一个不想讨论软件开发人员提供以下服务机会的商人：

• 更多功能，更快速
• 更少的缺陷
• 更快响应变更请求
• 更可预测的发布时间表
• 降低开发成本
• 降低程序员流失率

您的主要观点可能是，您的公司正在错失一些高价值的机会。您希望得到一些业务人员的建议，了解如何利用这些机会，让公司运营得更顺畅/高效/有效。

呼吁规避风险

根据你的受众，你可能会发现另一种更有说服力的方法。商界人士受过风险管理的训练，你可以利用这一点，将当前情况描述为管理日益增加的风险。

以下是代码混乱的一些风险：

• 竞争对手发布了更优秀的软件
• 缺陷数量激增
• 成本飙升
• 无法满足监管要求
• 无法添加新功能
• 进展停滞
• 数据丢失/损坏/泄露
• 诉讼/罚款
• 失去客户
• 负面宣传
• 完全无法使用软件
• 优秀的程序员离开项目
• 最重要的是：风险以不可预测、非线性的方式相互作用

这两种策略中的一种可能会引起您的商务人士的注意。

让他们参与你的会议

我的团队做过的最好的事情就是采用 SCRUM。我们的产品负责人参加了几次这样的会议后，真的“领悟”了。他每周都会在这些会议上花上大约一个小时的时间，成为我的忠实听众。我充分利用机会，尽可能地加深他的理解。

这些会议让“进度慢”或“代码质量差”等抽象概念变得更加具体。例如，我们会在回顾会议上回顾所有大幅偏离预期的情况，并讨论其原因。但听一位程序员花20分钟解释为什么一个简单的系统变更耗时40小时（是预期的10倍）又是另一回事。当这种情况在一个又一个冲刺中发生时，业务人员会不由自主地接受它。我发现，如果让他们参与到根本原因分析中，并帮助你制定问题的解决方案，会特别有帮助。

这些会议还能让业务人员了解团队的情况。程序员们如何管理自己？他们能力强吗？他们爱抱怨吗？团队士气如何？他们懒惰吗？他们关心业务吗？这些问题的答案远不如让业务人员得出一个不可避免的结论重要：“编程这件事”比表面上看起来要难得多。

区分技术债务和糟糕的代码

技术债务的定义已经从最初的扩展至几乎所有质量不佳的代码。在我的工作场所，我们正在抵制这种趋势。我们会区分技术债务和糟糕的代码。

技术债务：

是为了实现短期目标而故意做出的走捷径的决定，但要付出不可知的长期成本。

糟糕的代码：

是任何其他类型的非技术债务的捷径。

我们的政策是，只有在业务人员和程序员经过深思熟虑后，才允许将技术债务纳入代码库。我们的软件已经非常成熟，因此我们只允许在紧急情况下将技术债务纳入代码库。例如，如果我们在生产环境中发现一个关键缺陷，我们可能会“入侵”某个解决方案，立即解决问题，并将其称为技术债务。之后，我们会编写一个故事，以便稍后妥善修复。

虽然我们允许代码库中存在一定数量的技术债务，但我们对糟糕的代码采取零容忍政策。这项政策是经过一系列长期讨论和根本原因分析后制定的。我们认为，推进项目的唯一合理途径就是杜绝糟糕的代码进入代码库。为此，所有代码都会经过审查，并且在达到我们的质量目标（请参阅我们的代码审查清单）之前不会与主分支合并。即使这意味着修改所需的时间会比我们最初预估的时间长十倍，我们也接受。

当然，事情并非如此黑白分明。程序员每天都会做出各种判断。但我们的言行举止都是为了不写出任何糟糕的代码。这已经成为我们文化的一部分。

向他们展示关于糟糕代码成本的研究

商务人士通常不知道糟糕的代码对软件的健康有多大危害。所以，我的工作就是教育他们。

我把我的《软件项目生存指南》（史蒂夫·麦康奈尔著）借给了公司里的两位高层。这本书虽然有点过时了，但前五章绝对物超所值。

我会向所有愿意关注我的人展示罗伯特·C·马丁所著的《代码整洁之道》第4页。在这一页里，鲍勃大叔描述了拥有一团糟代码的总成本。我尤其喜欢指着页面底部的图表（如下所示），问他们觉得我们现在在哪个位置。

我还向人们展示我的《软件工程的事实与谬误》（罗伯特·格拉斯著），并用它来激发软件工程讨论。

我积极维护我们的代码、我们的团队以及我们的理智。我真正想表达的是以下三点：

1. 开发软件很困难，成本高昂，而且容易彻底失败，所以我们应该认真对待
2. 作为一项职业，我们了解哪些实践会影响软件开发的风险、进度、质量和成本
3. 我们应该采取与我们想要的结果相关的做法

向他们展示你项目中糟糕的代码示例

从理论上来说，说服人们糟糕的代码是糟糕的很容易。但让他们相信他们自己写的就是糟糕的代码，则是另一回事。

我甚至直接把我的IDE截图发邮件给我们的高层。我发现我去年写的一封邮件里有截图，内容如下：

• 我们某个项目的所有静态分析错误。它显示了一千多个严重警告和错误，以及数千个弱警告和通知。
• 包含 5 种语言和 500 多个警告的单个 3,189 行文件的静态分析错误
• 单个文件的所有错误和警告都标记在编辑器窗口的右侧。警告指示器覆盖了 95% 的区域

我写这封电子邮件给：

• 使我们的代码质量问题可见
• 说明为什么我们的代码修改成本如此之高
• 并提倡不要让情况变得更糟

质量和速度并不对立

我喜欢这个。Steve McConnell 发表了一篇题为《软件质量即最高速度》的文章。他认为：

在软件中，更高的质量（以更低的缺陷率形式）和更短的开发时间是相辅相成的。

这篇文章论证充分，由专家撰写，并有研究支持，脚注中也明确引用了相关研究。不妨一读，收藏一下。你会发现，这篇文章将成为你反驳那些认为你的团队只要停止进行大量的质量保证或上游规划就能加快进度的论调的有力武器。

竭尽全力使企业成功

如果业务人员哪怕只是一瞬间认为你的业务利益并非你的首要任务，你所有的努力都将付诸东流。你不能说从现在开始无论如何都不会再承担任何技术债务。你也不能说从现在开始你都会“以正确的方式”做事，然后他们就只能接受它了。

你们都在同一个团队。你们的目标是为公司尽可能多地赚钱。所以，当业务人员说他们需要在5周内开发一个新功能，而你认为​​需要20周时，你们（集体）就面临着一个需要解决的问题。

而你，作为软件专家，有很多可以贡献的地方。他们为什么需要这个功能？他们需要一次性完成所有功能吗？能否将其分成几个阶段，然后在五周内交付第一阶段？能否修改规范，使该功能更容易实现？能否在五周内构建一个完全不同的功能，并带来相同的销售和利润影响？能否集成 API 并减少开发工作量？能否在五周内交付该功能的精简版本，并立即跟进增强版本？能否将部分工作外包？

除了把东西拼凑起来然后扔到门外，还有很多可能性。如果你已经通过其他步骤打下了良好的基础，或许可以避免事情发展到那种地步。

始终表现得像专业人士

如果你想得到专业人士的对待，你需要表现得像个专业人士。抱怨和发牢骚可不是专业人士的行为。但这还不是全部。你需要一个计划来有效地管理你的软件开发流程并交付成果。你需要做出诚实的估算。你需要对团队的成果负责。你需要诚实，避免夸大其词。

例如，我避免对我们的代码库做出笼统的陈述。有些代码很糟糕，有些代码还不错，有些代码实际上相当不错。所以我从不说我们不能做出改变。但我会说，这项改变需要对我上周跟你提到的那个非常丑陋且未经测试的模块进行大量修改。原作者早已离职，我们真的不知道它是如何运作的。我会说这项改变需要花费数月的时间；你想让我做一份详细的估算吗？

在这种情况下，我的估算会包含一个范围，用于表明这种规模的变更所涉及的不确定性。我估计，这种变更可能需要 3-8 个人月，置信度为 85%。这意味着，我认为我们有 85% 的可能性在 3-8 个人月内完成这项变更，而实际工作量有 15% 的可能性会超出这个范围。

不，我只能给出更好的预算了。这就是预算。如果我们修改变更范围，可以再做一次预算，但我总是第一次就给出最好的预算。我不会让自己被迫降低预算。

当您了解商务人士的目标并能提出建议和计划来帮助他们更快地实现目标或至少避开前进道路上的雷区时，您就获得了真正的胜利。

当一切都失败时，你可能不得不放弃

有时候，你就是无法说服你的同事，除了“黑客加黑客加黑客”之外，其他任何方法都是可行的。他们不关心软件工程研究，不关心最佳实践，不关心你是否需要处理糟糕的代码，不关心你的生活是否痛苦，也不关心你是如何开发软件的。他们只想要结果，而且越便宜越好。

如果你发现自己处于这种情况，你需要做出一些决定。我只想说两点。首先，有些公司确实关心软件质量和开发人员的士气。其次，高质量的软件开发人员需求量很大，所以如果你想换工作，找一份新工作应该不会太难。

总结

当程序员在一个预期寿命很长的项目中加入了糟糕的代码时，无论是研究还是来之不易的经验都表明，他们几乎肯定会承担比自己意识到的更多的成本和风险。你会面临各种内部和外部的压力，要求更快地交付功能。但请永远记住，你的职责是维护代码和业务的最佳利益。