@程序员，技术债你还清了吗？

“我很想改进这种设计，但是我没有时间。”

“我真的很想整理这些，但是这不属于这个任务的范围。”

“我们现在没有时间重新思考这个模块的架构。”

这些话把每个开发人员的耳朵，都磨出茧自来了。更不像话的是，每个开发人员也整日把这些话挂在嘴边。

更让人心有不甘的得失，很多时候这些都是应该做的事情。

曾经我也很希望提供优雅美观的代码，但是现实情况是，我的老板付钱给我，让我提供对他们和他们的客户有用的功能，即价值。

专心为客户提供价值，是现代科技业务最大的重点，而且随着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等。

译者：弯月，责编：胡巍巍

_“ 征稿啦_”

CSDN 公众号秉持着「与千万技术人共成长」理念，不仅以「极客头条」、「畅言」栏目在第一时间以技术人的独特视角描述技术人关心的行业焦点事件，更有「技术头条」专栏，深度解读行业内的热门技术与场景应用，让所有的开发者紧跟技术潮流，保持警醒的技术嗅觉，对行业趋势、技术有更为全面的认知。

如果你有优质的文章，或是行业热点事件、技术趋势的真知灼见，或是深度的应用实践、场景方案等的新见解，欢迎联系 CSDN 投稿，联系方式：微信（guorui_1118，请备注投稿+姓名+公司职位），邮箱（guorui@csdn.net）。

————— 推荐阅读 —————