技术债务是一种缺乏理解的行为

不久前，我在一个项目中工作，感觉技术债务的定时炸弹正在我们面前爆炸。我们不能因为Whossitz而重构狂欢，当我们问到Whatsitz时，没有人知道Whatsitz以及它到底是如何与狂欢一起工作的，当然也没有对它的测试。当我们通知管理层时，他们回答说：“我们现在的情况是边飞边造飞机，如果不做大的改写，我们现在怎么能把这件事做出来呢？”很明显，技术债务是如何积累起来的。

这让我开始了探索技术债务概念的狂欢。我知道技术债务是什么，或者更确切地说，它是什么感觉，但我没有一个很好的方法来解释它，这不是纯粹主观的。“代码的味道”很能说明问题，但是如果“我不喜欢的代码”是技术债务的标准，那么每次你雇佣一个有远见的新员工时，你就是在重构整个项目。

经过一番搜索，我很高兴地找到了沃德·坎宁安(Ward Cunningham)的这段视频，他是一位软件程序员，最初创造了“技术债务”这个词，他在视频中对这个概念做了进一步的解释(…。

“如果你在很长一段时间里开发一个程序，只增加功能，但从来不重新组织，以反映你对这些功能的理解，那么最终这个程序根本就不包含任何理解，所有的努力都会花费越来越长的时间。”

我喜欢这样的定义，即问题在于“从未重新组织(代码)以反映您的理解。”在一个走走停停的产品周期中，这种理解的丧失开始产生一些问题，这些问题具有字面上和比喻意义上的成本。一种普遍的迷惑感层出不穷。开发人员的经济效益很容易量化；要么你放慢速度，在每次主要迭代后雇人重构和记录代码，要么付钱给每个在项目上工作到最后的开发人员，让他们盯着代码看几个小时，然后想知道到底发生了什么。随着时间的推移，这让人目瞪口呆地盯着代码库化合物。在组织上，你的报酬是速度和流动率；有才华的人在几轮废话后就会离开。

知识管理在组织中非常重要，但它们很少经历重组以反映当前理解的关键步骤。需要证据吗？看看离你最近的公司维基百科吧。我几乎可以保证它是一团糟，因为大多数公司永远不应该有维基。成功的维基百科，比如维基百科，是由一支编辑大军提供支持的，大多数组织永远不会优先考虑那么多时间或内容策略。管理不善的知识给组织留下了金鱼般的记忆。我不能告诉你我参加过多少次新产品计划会议，没有人记得两个季度前关于同一件事的会议。这就像土拨鼠节，但你却一遍又一遍地开着同样的会议。

我喜欢坎宁安基于理解的技术债务观点的一点是，它为必要时的大规模重构留出了理由。如果一个产品中有足够多的组织人员变动或足够多的特性，那么重写可能是最好的选择，这样您的团队才能对代码有一个集体的理解。你不能指望人们在匆忙的代码、难以理解的需求和不再在那里工作的人创造的捷径达到顶峰的情况下高效工作。在这一点上，你的技术债务气球已经破裂，你拥有了一项有毒资产，是时候买单了。或许，通过一些公认的原则，你可以找到欺骗熵或建立技术信用的方法，而不是累积债务或无休止地追逐新的闪亮之物。