“技术债务”一词最初是由 Ward Cunningham 提出的（大家可以看看 Ward Cunningham 自己是如何描述这一术语的）：
最初交付的代码就好像是欠债一样，但只要能通过重写快速地还债，那么少量的债务是会提升开发速度的。但是，如果债务得不到偿还，危险就会随之产生。花在并不太正确的代码上的每一分钟都将成为债务的利息。整个组织都会在债务的重压之下被折磨得精疲力竭。
最近，本文作者与一些同僚就技术债务及其解决方案展开了一次对话。此次讨论的中心议题是：本文作者认为技术债务是个技术问题，可以通过规范的手段加以解决，比如重构和测试等；而另一方则认为光是重构与测试并不能减少技术债务。
可以将本文作者一方的观点总结如下：为了减少技术债务，人们必须要不断增加测试数量和重构次数以首先满足系统的设计与架构要求，接下来逐步解决系统所面临的各种问题。这一方对技术债务的理解是：技术债务就是个技术问题，应该通过管理的手段加以解决。我们可以接受技术债务，但不要忘记偿还就行。 Martin Fowler 、 Ward Cunningham 以及 Bob 大叔等人已经就这个主题、其重要性以及对开发团队的影响进行过多次讨论。
另一方的观点与本文作者并不矛盾，但他们认为技术债务只是真实问题的一小部分而已，我们可以解决表面症状，但如果没有足够的细心是无法解决其根源问题的。事实上，我们甚至在 TDD 和术语“重构”出来之前就已经在不断重构了。作为软件开发人员，我们会重新设计，重新构建系统，这不过是更大的重构周期（月、年而非分钟）的一部分。因此，TDD 和重构只是在解决表面症状而已。他们援引 Deming 的话说：
这并非是把人分成三六九等。每个人都要清楚自己的工作效率在很大程度上会受到所从事工作的影响…
上面这句话表明技术债务实际上是更大问题的一种症状表现，然而人们很难看清债务本身，对于开发者和组织来说，千万不要放任技术债务横行。因此，解决方案就是公开问题与解决问题的代价，而非向开发者提供一套新的工具集。
本文作者认为还需要一些时间来消化上面这些内容，同时感觉很有必要与社区分享这些内容。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论