開源社群的技術債：寫程式碼的“碼農”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/