開源社群的技術債:寫程式碼的“碼農”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/
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31562039/viewspace-2656527/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 解碼技術債:AI程式碼助手與智慧體的革新之道AI智慧體
- 碼農程式碼之外的生存指南
- 碼農深耕 - 什麼樣的程式碼才是好程式碼?
- 編寫更優雅的 JavaScript 程式碼JavaScript
- 如何寫出更優質的程式碼
- 程式碼質量與規範,那些年你欠下的技術債
- 一刻社群程式碼開源啦
- 寫程式碼之前應該做的幾件事
- 低程式碼VS無程式碼
- 誰動了我的程式碼!?
- 10年老碼農:如何從該死的爛程式碼中爬出來?
- 保護C#程式碼的藝術:深入淺出程式碼混淆技術C#
- 四千行程式碼寫的桌面作業系統GrapeOS完整程式碼開源了行程作業系統
- 老碼農冒死揭開行業黑幕:如何編寫無法維護的程式碼(上篇)行業
- PHP理想國--程式碼怎麼寫看的更舒服PHP
- 修改VS的程式碼高亮顏色
- 程式碼整潔 vs 程式碼骯髒
- 尋找寫程式碼感覺(十五)之 刪除功能的開發
- 谷歌檢視CSS程式碼被誰覆蓋谷歌CSS
- 低程式碼的技術原理是什麼?
- 火爆的低程式碼開發具有哪些技術特點?
- 開源低程式碼平臺開發實踐一:低程式碼開發探討與技術選型
- 被解救的程式碼 - 程式碼即服務時代來了!
- 天天寫業務程式碼的程式設計師,怎麼成為技術大牛程式設計師
- 12 個給全等級碼農們的程式設計資源程式設計
- 碼農被3年資深程式設計師狂噴:根本不懂程式碼!程式設計師
- 如何提高Java程式碼質量-優雅的寫程式碼Java
- 《程式碼英雄》第五季(2):寫程式碼的地方
- 把IDE字型增大才能寫出更簡單的程式碼IDE
- 盤點那些程式設計師最汙的技術段子,老碼農秒懂!程式設計師
- 技術總監到底要不要寫程式碼?
- 需求變更,程式碼改的像辣雞 - 論程式碼質量
- 分享常用的CSS函式,助你寫出更簡潔的程式碼CSS函式
- 不用寫程式碼的爬蟲爬蟲
- 好的程式碼很容易刪除!
- Appsmith:真正的低程式碼開源開發工具APPMIT
- Uber開源Piranha:一種自動刪除陳舊程式碼的工具
- 碼農與程式設計師的區別程式設計師