对于开源项目来讲，写新程序代码的贡献者不一定是好工程师，但不会删程序代码的工程师一定不是合格的工程师——因为“删程序代码”才是让开源软件程序代码简洁高效的关键所在。
MongoDB的工程师Dj Walker-Morgan就在推特中这样说道：“依我看，删程序代码才是偿还技术债的绝杀技能。”
对于软件工程师来讲，只有其本人对整个项目了然于心，才能知道哪行程序代码是冗余的，删除这些程序代码才能确保程序在保证功能完整性的情况下高效运行，真正达到去粗取精的目的。
另一位资深工程师CharityMajors曾发推文表示：“在曾与我共事过的资深工程师中，最优秀的那批人一直在想尽办法，避免在项目中添写新程序代码。”
那么，对于这些删除程序代码，或以最小的程序代码量完成更多功能的软件工程师，我们是否有合适的奖励方法呢？
降低技术债成本，工程师需要花时间删除冗余程序代码
前文提到，删除程序代码是偿还“技术债”的必杀技，那么到底什么是“技术债”呢？
在软件开发过程中，如果工程师为赶在最后期限之前交差而采用了一种较为简单但未达到最佳标准的解决方案，那么项目就会背上技术债，潜在的风险会像利息一样，使债越积越大。
Dormain Drewitz曾发布过一个非常有趣的观点：“所有写下的程序代码都是技术债。”此话怎讲呢？
由于“马后炮效应”的存在，人们的后见之明使得分辨一段程序代码是正确的决策还是垃圾的产出变得十分容易，但在实际的开发过程中，工程师可能没办法找到一个更好的解决方案，甚至可以说，目前的程序代码在当时来看可能就是最佳选择。
但我们要知道，这些当下的“最佳选择”并不意味着要长久保留。不管你喜欢与否，“技术债”都会越积越重。
来自ThoughtWorks的MatrinFowler便对处理技术债提出了以下建议：
“通常解决金融债务的最佳途径就是一点点地偿还本金，“技术债”也是如此。在搭建第一个功能时，我就会开始花额外的时间删掉一些冗余程序代码。这就好比减少了技术债未来可能产生的利息，虽然会花费一些额外的时间，但这让最终的技术债变得可承担。像这样逐步改进程序代码，那些经常被我们经常修改的程序代码块便会随着时间的推移变得越来越精炼，而这些程序代码块也恰好是程序代码库中最需要定期清理的部分。”
工程师SarahMei将技术债称为“混乱体”，一个杂乱的房间。正因如此，尝试用微服务架构（MSA）来解决技术债的想法是不切实际的。
她认为，这样做会使得项目最终只剩一个饱和微小的空间和一堆杂乱无序的存储单元。同样的，你无法在这样一个狭小、拥挤又混乱的房间中找到你想要的东西。
因此，降低技术债的理想方案是从那些拥有最多所谓贡献量的程序代码入手。于是，眼下要解决的问题变为——如何通过合适的方法标定那些被删除的程序代码？
负责整理、删除程序代码的工程师应该得到奖励
如果你去看Kubernetes或其他项目的贡献排行榜，你很容易找到那些提交开源程序代码的工程师，但排名指标的下拉菜单中并没有出现与“删除程序代码行数”相关的数字。依照前文Majors对优秀的资深软件工程师的定义，尽管记录那些提交新程序代码的人是有意义的，但这些新程序代码能为开源项目带来多大价值就不太好说了。
相较于统计程序代码量，对程序代码效率的计量是一件并不那么客观的事情，尽管这一举标十分重要，但实际上很难对其下一个准确统一的操作性定义。而正因为如此，我们反倒可以重新体会到“删程序代码”的艺术魅力。
曾任职MongoDB的HenrikIngo告诉作者：“在MongoDB工作的3年里，我删掉的程序代码比我写的要多。”他还自嘲道：“但遗憾的是，这注定是以场失败的战役——这只会激发更多的同事编写更多新的程序代码进去。”
在这样的评判标准下，优秀的工程师可能不会在排行榜中名列前茅，因为他们的贡献在于巧妙地删除冗余程序代码，就像Henrik，他们删除的程序代码可能比写的新程序代码还要多。
几年前，Yelp的团队开发了Undebt——一个旨在自动化实现大量程序代码重构的项目，但至今没有见它有过后续的维护和更新，也没见它被成功使用。
那么，你所在的团队是如何发现和鼓励会删程序代码的工程师呢？为开源项目删程序代码的工程师是否也可以通过同样的方式得到鼓励和回应呢？
至少目前来看，人们所关心的排行榜或许是基于不完美甚至是没有价值的指标——那些致力于在茫茫程序代码的海洋中消除一个个技术债的“清道夫”工程师应该受到更大的重视和嘉奖。