编码混乱是技术上的债务吗？

“技术债务（technical debt）”这个词是由Ward Cunningham 发明的，用来描述为了在最后期限前实现某个项目任务而让开发团队做某种技术上的妥协。

这里有两篇博客文章，Uncle Bob 和 Martin Fowler 分别在里面描述了几乎所有项目都可能会遇到的各种技术债务。

在 A Mess is not a Technical Debt 这篇博客里， Uncle Bob 评论说，做出妥协是实现有最后期限目标的必要的手段。但是他区分妥协与否的方法只是纯粹从代码的粗心与否来考虑：

编码混乱并不是一种债务。编码混乱就是编码混乱。技术债务的产生是由现实的工程约束造成的。这是有风险的，但却是值得去做的。而程序员让编码混乱的行为永远是不理智的，它永远都是因为懒惰和不专业造成的，而且将来你也永远还不清这种债务。混乱永远都是一种错误 …

你承担的技术债务越多，你就应该越发自律。你应该做更多的测试，更多的结对编程，更多的重构。技术债务并不是你制造代码混乱的通行证。技术债务实际 上是要求你更清晰的代码 … 当你决定去欠下技术债务的时候，你最好能确保你的代码保持清晰易懂。保持系统的清晰易懂是你将来偿还债务的唯一途径 …

在 Technical Debt Quadrant 这篇博客里， Martin Fowler 认为编码混乱就是一种技术债务，是程序员在不经意间犯下的错误。Martin Fowler 接着描述了四种类型的技术债务：故意的/大意的，故意的/谨慎的，非故意的/大意的，以及非故意的/谨慎的：

做这些区分的目的不在于判断它是否是债务，而是判断是思虑过的还是粗心的 …

不仅仅谨慎产生的债务和大意产生的债务有区别，考虑过的债务和非有意的债务更要有区别。谨慎思考过的债务的例子就是”故意的债务“，因为团队已经知 道他们将会欠下债务，他们会考虑是提前发布一个不成熟的版本会得的利益多还是放弃这次发布产生的代价大。一个团队如果没有反复思考他们的设计，那他们就会 欠下粗心大意产生的债务，他们甚至没有意识到自己已经陷入了无法自拔的债务泥潭里。

注意到，有一种特殊的债务既是既是大意的又是思考过的：

经常会有这种情况出现，一个项目你干了一年后才明白你实际应该采用何种的设计架构。也许我们应该这样计划项目：花一年的时间去开发它，然后扔掉重建，但没人会认同这种做法。除了此时你会明白什么的设计才是你应该采取的设计外，你还要明白，这就是一个非有意产生的债务。

你是否也认为混乱的编码、快速但质量低下的程序实现是某种形式上的技术债务呢？或者，你 认为这些只是由于技术水平低下造成的，完全可以避免，即使是在有最后期限的情况下？(外刊IT评论 )

评论

3 楼 对酒当歌，人生几何 2009-11-04  

欠债总比被人骂好吧。我遇到的都是赶任务第一，代码质量是排最后的。不管用什么方法，越快实现越好。这样才会被别人赏识。至少我遇到的长官是如此的。

2 楼 tianmo2008 2009-10-30  

时间决定一切,
真心喜欢编程的人,肯定都希望自己写出来的代码能让人称赞,但在没完没了的加班状态下,
代码的质量,只能根据写代码人的经验来定,想从美学的角度来欣赏一下,空谈..

1 楼 黑暗浪子 2009-10-28  

做任何事情都有一个渐进明细的过程，因此有时候早期的一些错误认知是需要花代价来修正的。我认为没有“债务”的软件产品和项目是不可能存在于这个世界上的。