“我很想改进这种设计，但是我没有时间。”
“我真的很想整理这些，但是这不属于这个任务的范围。”
“我们现在没有时间重新思考这个模块的架构。”
这些话把每个开发人员的耳朵，都磨出茧自来了。更不像话的是，每个开发人员也整日把这些话挂在嘴边。
更让人心有不甘的得失，很多时候这些都是应该做的事情。
曾经我也很希望提供优雅美观的代码，但是现实情况是，我的老板付钱给我，让我提供对他们和他们的客户有用的功能，即价值。
专心为客户提供价值，是现代科技业务最大的重点，而且随着Eric Reis的“精益创业”的流行，以及其对整个“科技产品开发”思想的启发，这个重点变得更为突出。
但是，我们所有人（包括Reis和他的朋友）也都认识到，全心全意提供面向客户的功能是一个错误；这是导致我们陷入熟悉的“技术债务”的罪魁祸首，接下来就是“技术破产”，最终我们在恐惧中承认失败，所有工作都白费，所有代码必须“完全重写”。
因此，作为软件开发人员我们普遍认为：维护（即保持代码库处于健康状态），是我们工作重要的组成部分。
但是，如果我们都认识到保持健康的代码库，是工作的重要部分，那么为何我们常常发现“价值”，占据了我们100%的工作时间，而投入到“维护”的时间几乎为0呢？
我们知道维护是必须的。我们的技术负责人知道。我们的首席技术官常常说起，有时甚至连CEO都熟悉“技术负债”的概念、以及技术人员对此的恐惧。
然而，在现实中，我们工作的重点依然没有变。“我现在没有时间该这个问题。”
维护的正当理由
这个问题有什么正当理由吗？
最常见的解释理由是“产品经理是大坏蛋”的理论：我没法去做技术维护，因为这个邪恶的商人不断给我分配功能开发。
我发现这个解释不够充分，原因有两个：
首先，产品经理与我们形容的形象相反，他们也是讲道理的人。他们也知道而且很担心技术债务，他们也想避免这种情况。
而且即便他们不想这么做，我们还有技术人员，保持技术方面的健康是技术领导团队的工作。
其次，根据我们以上的观察，维护是你的工作的一部分。
从什么时候开始你的工作需要领导批准？医生不会因为说“我们承诺在本季末保持客户的健康”，才去做彻底的检查和测试。
一个专业的承包商不会在确认地面足够支撑建筑的结构前，就开始铺设地基。
那么这与软件有何不同？很多原因在于我们这个行业的极端不成熟。
我们没有足够专业的标准，让保持代码健康成为流程中不可或缺的一部分，就像建筑中的安全检查，或医疗服务中的卫生处理。
这反过来又说明，我们没有足够的专业能力，来证明这样的标准，也就是说我们在上一个项目中花了时间来“偿还技术债务”，但却没有成功。那么我们怎么可能要求，在下一个项目中还这么做呢？
当然，对于那些追随Bob Martin叔叔以及其他许多年来一直说同样的话的人来说，这个结果并不新奇。
但是我相信事情还没完，不全是因为我们不够优秀（不够专业）做正确的维护。部分是因为我们不愿尝试。请记住——我这里说的是“我没这么做”，而不是说“我努力了，但是做不到”。
为什么我们不愿尝试维护？
假设你是一个典型的开发人员。某一天，他们可以选择创造价值还是做维护。我知道他们（几乎所有人）都会选择前者。
尽管他们的技术负责人、首席技术官和同事每天都在讨论技术债务的忧患。这是为什么呢？你（或同事）因为交付对客户非常有利的功能，而受到称赞的情况有多少次？
现在，比较一下你（或同事）因为做了代码重构、维护或写技术文档，而受到表扬的情况有多少次？
或者，从另一个角度来看，对于你个人而言，如果你们计划了100个给客户的功能，但是有1个未能交付，那么你认为后果是什么？
比较一下，对于你个人而言，如果有100次机会，可以改进或维护代码库，但是这100次你统统没有做，那么你认为后果是什么？
如果你的工作环境，与我见过的所有工作环境都很相似的话，那么你知道交付优秀的维护工作，可能你的同事会感激你，但是交付功能可以让你赢得升职。
你会选哪个？这个结果一点都不惊讶或新颖；凭我对市场经济仅有的一点了解，我也知道每个人都会努力争取最大化利益。
如果你按照代码行数付钱，那么相同的功能，你拿到的代码量将是10倍之多。如果每改好一个bug，就可以收到一份奖金，那么你的应用程序里面会布满bug，以方便他们日后慢慢改。
如果维护代码没有切实的奖励，那么你就会陷入技术负债。
我们怎样才能将开发人员100%投入到价值的精力转移到0%的维护工作上呢？简单来说，经理不能只是动动嘴皮子；不要再喋喋不休地讨论，如何解决技术债务。相反，应该表明你愿意付钱找人解决这个问题。
平衡在维护中的重要性
平衡在这里很重要。虽然我们不希望开发人员在价值和维护上投入到精力比例为100比0，但也不想变成50比50。
如何将维护相关的工作，作为年度考核中的一部分呢？或者作为开发规范的一部分呢？
在问开发人员“这些功能做得怎么样了？”的时候，每问10次，可否有1次问“最近代码改进怎么样了？”
一旦人们明白，保持代码健康也会受到奖励，包括他们的升职、电影推荐加薪和公司内的位置等会受其影响，他们就会自己找时间、范围和精力来完成。
不过，为了有效判定某人是否达成了某个目标，你需要能够度量。度量代码的质量，或代码质量改善度，并不是一个可以轻易解决的问题。如何度量这个话题需要开一篇博文、写一本书或学术研究来解释。
本文的描述符合你的经历吗？还有什么合理的原因，导致我们不愿偿还技术债务吗？或者也许这压根不算什么问题？请在下面留言。
原文链接：https://uselessdevblog.wordpress.com/2018/06/24/why-we-all-choose-to-not-pay-back-tech-debt/
作者：Jhonny，资深软件开发人员，熟悉C#、javascriptnode和JS、ruby，以及一些工具AnuglarJS、nHibernate、rails、mongodb等。
译者：弯月，责编：胡巍巍
原文地址：https://www.cnblogs.com/wangfengxia/p/9626879.html