编码混乱是技术上的债务吗？
[原文链接]
“技术债务（technical debt）”这个词是由Ward Cunningham 发明的，用来描述为了在最后期限前实现某个项目任务而让开发团队做某种技术上的妥协。
这里有两篇博客文章，Uncle Bob 和 Martin Fowler 分别在里面描述了几乎所有项目都可能会遇到的各种技术债务。
在 A Mess is not a Technical Debt 这篇博客里， Uncle Bob 评论说，做出妥协是实现有最后期限目标的必要的手段。但是他区分妥协与否的方法只是纯粹从代码的粗心与否来考虑：
编码混乱并不是一种债务。编码混乱就是编码混乱。技术债务的产生是由现实的工程约束造成的。这是有风险的，但却是值得去做的。而程序员让编码混乱的行为永远是不理智的，它永远都是因为懒惰和不专业造成的，而且将来你也永远还不清这种债务。混乱永远都是一种错误 …
你承担的技术债务越多，你就应该越发自律。你应该做更多的测试，更多的结对编程，更多的重构。技术债务并不是你制造代码混乱的通行证。技术债务实际上是要求你更清晰的代码 … 当你决定去欠下技术债务的时候，你最好能确保你的代码保持清晰易懂。保持系统的清晰易懂是你将来偿还债务的唯一途径 …
在 Technical Debt Quadrant 这篇博客里， Martin Fowler 认为编码混乱就是一种技术债务，是程序员在不经意间犯下的错误。Martin Fowler 接着描述了四种类型的技术债务：故意的/大意的，故意的/谨慎的，非故意的/大意的，以及非故意的/谨慎的：
做这些区分的目的不在于判断它是否是债务，而是判断是思虑过的还是粗心的 …
不仅仅谨慎产生的债务和大意产生的债务有区别，考虑过的债务和非有意的债务更要有区别。谨慎思考过的债务的例子就是”故意的债务“，因为团队已经知道他们将会欠下债务，他们会考虑是提前发布一个不成熟的版本会得的利益多还是放弃这次发布产生的代价大。一个团队如果没有反复思考他们的设计，那他们就会欠下粗心大意产生的债务，他们甚至没有意识到自己已经陷入了无法自拔的债务泥潭里。
注意到，有一种特殊的债务既是既是大意的又是思考过的：
经常会有这种情况出现，一个项目你干了一年后才明白你实际应该采用何种的设计架构。也许我们应该这样计划项目：花一年的时间去开发它，然后扔掉重建，但没人会认同这种做法。除了此时你会明白什么的设计才是你应该采取的设计外，你还要明白，这就是一个非有意产生的债务。
你是否也认为混乱的编码、快速但质量低下的程序实现是某种形式上的技术债务呢？或者，你认为这些只是由于技术水平低下造成的，完全可以避免，即使是在有最后期限的情况下？
