原文链接：https://uselessdevblog.wordpress.com/2018/06/24/why-we-all-choose-to-not-pay-back-tech-debt/
“我很想改进这个设计，但我还没有时间”
“我真的想整理一下这个，但它不在这个任务的范围内”
“我们没有时间现在重新思考这个模块的架构“
每个开发人员都听过这些短语一百次。地狱，每个开发人员都说过这些短语一百次。
并且，尽管我们不愿承认 - 很多时候这是正确的做法。
我很乐意为付出优雅，漂亮的代码付出代价，但实际情况是，我的雇主付钱给我提供对他们和他们的客户有用的功能; AKA 价值。
专注于提供给客户的价值是现代科技企业最大的重点，随着Eric Reis的“精益创业公司”的普及，以及它激发的整个“科技产品开发”思想流派，它变得更加突出。
然而，我们所有人（包括Reis和朋友）也认识到完全专注于面向客户的功能是一个错误; 这是你进入那些熟悉的“科技债务”区域，然后是“技术破产”的地方，导致可怕的，浪费的，承认失败 - “完全重写”。
因此，我们可以普遍认同，作为软件开发商，男aintenance，即保持代码库处于健康状态，是我们工作的一个重要组成部分。
但是，如果我们都认识到保持健康的代码库是我们工作的重要组成部分，那么我们如何经常发现我们的“价值”拨号是100％，但我们的“维护”拨打（几乎）0％？
我们知道维护是必须的。我们的技术主管知道它。我们的首席技术官谈到它，有时甚至首席执行官都熟悉“科技债务”的概念以及技术人员对它的害怕程度。
然而，在实地，优先事项保持不变。“我没时间修理它马上 曾经”。
有合理的理由吗？
最流行的解释是“大坏产品经理”理论：我不做技术维护，因为邪恶的商人不断推动我的功能。
我发现这个解释不充分，原因有两个：
首先，与我们喜欢描绘它们的方式相反，产品经理是合理的人。他们也知道并担心科技债务，他们想要避免它。
即使他们不这样做，保持业务技术方面的健康也是您的技术领导团队的目标。
其次，正如我们上面所述 - 维护是你工作的一部分。
从什么时候开始要求你的工作许可？
医生不会放弃彻底的检查和检查，因为“我们向客户承诺，到本季度末我们会健康”。
在她确认地面可以维持她正在建造的结构之前，专业承包商不会开始铺设基础。
那么为什么软件会有所不同呢？
很多原因在于我们行业的极端不成熟。
我们没有足够的专业标准来使代码健康成为流程中不可协商的部分，例如建筑安全检查或卫生服务中的卫生处理。
（这又是因为没有证明来证明这样的标准够专业能力，即-我们把在最后一个项目为“偿还债务的高科技”的时间，但它坎变成了废话那么，如何才能可信的需求。在下一个项目中做同样的事情？）
（当然，对于那些听过鲍勃·马丁叔叔和“其他”许多人多年来一直在说的话的人来说，这个观察结果不会是新闻）
但我相信这不是整个故事 - 这不仅仅是因为我们不够好（即专业）足以做好维护。部分问题是我们甚至都没有尝试过。
（记住 - 它是“我没有做到”，它不是“我试过，但未能做到”）
为什么我们甚至不尝试维修？
让我们考虑一下您的典型开发人员。在任何一天，他们都可以选择提供价值或维护。我们知道他们（几乎）总是选择前者而不是后者。尽管他们的技术主管，CTO，同事们都在谈论每天技术债务的恐怖。
这是为什么？
您（或同事）多少次因提供对您的客户非常有益的功能而受到称赞？
现在，将您与（或同事）多少次因为重构，维护或向项目添加技术文档而受到称赞？
或者，从不同的角度来看 - 如果您未能向客户提供100个计划中的功能，您认为对您个人的影响是什么？
相比之下，如果您未能在100个机会中的100个中改进/维护代码库，那么您认为后果将对您个人产生影响。
如果您的工作场所与我见过的任何工作场所都非常相似，那么您知道提供出色的维护可能会让您感谢您的同事，但提供功能将获得晋升。
你会选哪个？
这个结论并不令人惊讶或新颖; 如果我对市场经济有一点了解（并且我实际上只有一件事我知道），那么人们会根据提供给他们的激励来优化他们的行为。
按行代码支付开发人员费用？您可以获得x10更详细的相同功能。
修复每个错误的奖金？您会在应用程序中植入错误，以便以后修复它们。
没有任何实际的维护奖励？你得到科技债务。
走路，不说话
我们如何才能将开发商的比例从100％的价值 - 0％维护？
简单 - 经理需要把钱放在嘴边;
停止谈论想要解决科技债务问题。相反，表明你愿意付钱给别人来解决它。
（平衡在这里很重要;虽然我们不希望值和维护之间的分割为100/0，但50/50分割也是不合理的）
如何将维护相关的订单项作为年度审核流程的一部分？作为开发人员角色规范的一部分？
为什么不这样，每10次你会问“这样的功能是如何出现的？”，请问“你最近如何改进代码？”一次？
一旦人们明白激励他们保持代码库健康，他们在组织内的推广，提升和地位受到影响，他们就会找到时间，范围和精力来完成它。
（*巨大的警告：为了有效地判断某人是否达到了某个目标，你需要能够衡量它。测量代码质量或代码质量的提高量，无论如何都不是一个解决的问题。它是一个主题值得一篇博客文章（或书籍或学术研究）。）
行什么，你觉得呢？此描述是否符合您自己的体验？有没有合理的理由说明为什么我们无法偿还我错过的技术债务？或者这可能根本不是问题？请在下面告诉我。