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