技术债务墙：让技术债务无所遁形_架构_Mathias Verraes



 写点什么

“技术债务”是对低效、无效或完全错误的软件设计决策的一种隐喻，它们将会在未来给开发带来额外的成本。今天走的捷径以后会让你慢下来，直到你通过解决问题来“偿还”债务。它们不仅指的是代码：架构、文档、测试和领域模型都可能受到技术债务的影响。

技术债务会严重拖累开发进度，而通过重构来偿还技术债务通常也不是可行的方案。但是，与金融债务一样，技术债务并不总是坏事。债务让我们在赚到钱之前有投资的资本。在将产品推向市场时走走捷径，可以让我们以较低的成本测试业务模型，并在发现代码不好时直接丢弃代码。通常，之所以会存在债务，是因为随着业务的增长和演化，早期有效的设计决策变得不再有效。

问题不在于技术债务本身，而是我们无法管理这些技术债务。在任何一家公司，首席财务官都知道公司有多少财务债务。他们可以看电子表格、季度报告、付款计划，可以选择再融资或出售债务。但如果你问首席技术官，公司有多少技术债务，你会得到一个尴尬的回答：“有很多吧？”

你办公室里有一面墙（或板子），我们把它叫作技术债务墙，可以将写满问题的便利贴贴在这面墙上。这样做很容易，我们可以选择增加、减少、偿还或忽略技术债务。当然，这绝不是一个规模化管理技术债务的完整解决方案。它之所以有效，是因为它做起来很容易。

如何做

很简单：让债务技术可见，养成习惯，定期沟通协商，放弃控制权。

让技术债务可见

在团队工作的地方选一面墙，确保它是公开可见的，给它贴上“技术债务墙”的标签。画一个漂亮生动的 logo，确保周围有便利贴和记号笔。

养成习惯

在开发代码时你要想想：

是什么让你的速度变慢了？是什么让代码变得难以理解？是什么原因导致 bug 难以跟踪？什么东西应该被更好地记录下来或测试？在便利贴上记下你碰到的任何一个技术债务。保持简短，但要确保你以后仍然看得懂。
估计机会成本：如果不存在这个问题，你原本有多少时间可以用在其他事情上？把它写在便利贴上。确定好时间标记，例如用点号表示半天。视觉化比是否精确更重要。
估计解决这个技术债务需要多长时间，把它记下来。
或者记下如何解决技术债务。你可能会把它记在问题跟踪系统中，那么就把问题编号写在便利贴上。
把便利贴贴在技术债务墙上。
如果有人遇到同样的问题，添加更多的标记，用来表示他们付出的时间成本。

在引入新的技术债务时，都要添加便利贴。诚实一点，这并不可耻，因为代码不能代表你。记住，技术债务是一种投资，而不是犯罪——除非你隐瞒债务，如果那样的话你就是在做假账！

协商

随着技术债务墙上的东西越来越多，公司里的人可能会有点紧张。没关系，债务总是存在的，你只是把它们显现出来罢了。

不管是什么时候，只要有人在已有的便利贴上添加时间点，都要先与团队讨论。将技术债务可能浪费的时间成本与偿还技术债务需要花费的时间成本进行比较。偿还一个技术债务可能需要一天的时间，但如果每周都会因为这个债务浪费两个小时，那么很快就会回本。或者你认为偿还某个技术债务不值得？但这已经不是美学或观点的问题了，这是一个指标收集问题。此时，你们是作为一个团队在协商权衡。

当有人要为已发现的技术债务添加便利贴时，请先想一下团队现在是否可以解决这个问题，或者直接把它贴到墙上也可以。没有证据表明这个问题会让你继续付出代价？那么就让它继续收集更多的时间点数。

但是，如果我们是引入新的技术债务，情况就不一样了。请想一下团队是否可以选择不走捷径，在成本相对较低的时候把问题修复。现在的问题不是“我们现在有时间吗”，而是“以后再为它支付利息值得吗？需要支付多少？”。这个问题的答案可以是“没关系，只管去做吧”，也可以是“其他很多事情都依赖它，我们先把它做好再继续。”

关键在于不要企图解决所有的技术债务问题，而是要学会协商什么时候该把它们添加到墙上，什么时候该修复它们，什么时候该避免它们。在以前，这些情况几乎是在不知不觉中发生的。团队成员在不了解所有事实的情况下添加或偿还了技术债务。而现在要开始运用团队的集体脑力，使用真实数据作为参考。

放弃控制权

现在，我们来看看真正的魔法。由于技术债务墙上的东西是可见的，经理们应该开始注意到它们了。(如果他们仍然没有注意到，可以在墙上加一些标有“€”或“$”的大红色标记，因为钱是全世界通用的语言。）

当团队要求花时间解决技术债务，这样做并不会给用户或业务带来直接的实际利益。经理们并不知道偿还这些技术债务是否重要，可能开发人员只是想要尝试使用新技术，或者让代码更优雅？即使是具有深厚技术背景的经理，如果他们没有直接参与编码，也不可能做出很好的判断。

但有了技术债务墙之后，情况就不一样了。现在不是意见不意见的问题，也不是要成为一个能够写出优雅代码的工匠程序员的问题，更不是为了要解决具有挑战性的难题。现在事关事实、数字、债务和要支付的利息以及投资回报。好的代码就是资产，不好的代码就是负债。经理们最擅长的就是根据数字做决策。他们有很多方法：CBA、OODA、PCDA、SWOT……

放弃控制权。经理们更了解公司的战略、预算和风险。让他们来决定哪些技术债务要偿还，并规划时间表。那些数字可以作为参考。

技巧和陷阱

不要一开始就对所有的技术债务进行全面的审计。当然，你可以花几天时间来确认所有的技术债务。但之后你需要安排时间，要把它当成一件大事。“我们会在夏天来偿还这些技术债务”，或者“在完成那个大项目之后”，或者干脆委婉地说“永不”偿还。在墙上贴的每一张便利贴都能带来价值。你可以在以后回过头来做审计，但不要让它成为瓶颈。
对于没有时间点标记的便利贴，我们需要展开讨论。有些困扰你的事情实际上可能并不会影响未来的开发。在遇到问题时，只是简单地加入问题，技术债务墙就会体现出时间成本。你要养成协商技术债务的习惯，而不是做出一次性的努力，回到老路上去。
反过来也是一样。如果你看到了一些写得很奇怪的代码，但它们并没有浪费你的时间，那就忽略它们。我们并不关心你是否喜欢它们，我们关心的是它们是否会占用额外的时间。
不要忽略了实体的技术债务墙。不要把所有东西都放在数字工具里，比如 bug 跟踪器。日志和指标只有在人们查看它们时才有用，而数字工具很容易把这些信息隐藏起来。墙是可见的，会让那些信息无所遁形。

结论

在阅读了我写的博文后，一家初创公司引入了“技术债务墙”。他们是一家非常小的公司，办公室所有的墙壁都已经被商业计划和应用程序模型占满了，于是他们把便利贴贴在办公室的一扇窗户上。有趣的是，当房间开始变暗，他们就知道是时候进行重构了。更重要的是，他们总是在完美主义和快速打入市场这二者之间徘徊，而技术债务墙帮他们突破了这一困境，他们很快就开始行动了。据我们所知，各种公司的团队都成功地应用了技术债务墙，或许你也可以。