開源社區的技術債：寫代碼的“碼農”VS 刪代碼的“清道夫”，誰更該被嘉獎？
大數據文摘出品
編譯：楚陽、橡樹、錢天培
對于開源項目來講，寫新代碼的貢獻者不一定是好程序員，但不會刪代碼的程序員一定不是合格的程序員——因為“刪代碼”才是使開源軟件項目的代碼簡潔高效的關鍵所在。
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/
【本文是51CTO專欄機構大數據文摘的原創譯文，微信公眾號“大數據文摘（ id: BigDataDigest）”】
