我是程序員：你只加了兩行代碼，爲何用了兩天時間

------------恢復內容開始------------

 

幫助我寫一個電商網站，像淘寶同樣，3000預算還不夠嗎？但能夠再加一點。」幫助我寫一個像百度同樣的搜索引擎，一個輸入框應該不會花多少時間吧？"我這方面的需求有點複雜，幫我寫一本隨手機主題顏色變化的智能後蓋，錢不成問題。"

不管你是一家正規的網絡公司，仍是一名兼職的開發人員，你都會或多或少地遇到各類各樣的產品需求，客戶需求，老闆需求，他們都贊成：這個需求很簡單。

這是否是真的呢？

"只要兩行代碼，爲何要花兩天時間？"

這個問題看起來是有道理的，可是在其背後有幾個荒謬的想法：

 

 

代碼行數=工做量代碼行數=價值代碼行之間沒有什麼差異，相互等價很明顯，以上三個都是廢話。

開發人員面對這樣的指責，翻白眼之餘卻也難免怨天尤人，軟件開發是將現實世界映射到虛擬世界的魔術，回顧咱們所作的改變，有太多的理由能夠解釋爲何兩行代碼要花上兩天。

因爲問題報告對再現方法的描述不夠清晰。

有時咱們要花費數小時才能可靠地重現某些問題。趕上這樣的狀況，一些開發人員會馬上聯繫問題報案者，要求對方提供更多的細節。可是有些開發人員不喜歡修復 Bug，所以缺少信息就成了甩鍋的好方法。

因爲所報告的問題是關於功能的，因此我並不熟悉這些功能。

 

 

這可能涉及一些功能，一些開發人員不多使用，所以並不十分熟悉相關細節。在這種狀況下，開發人員須要花費更多時間來了解如何使用功能，尤爲是這種功能 bug與軟件交互的具體過程。

這是由於我花了時間研究問題產生的真正緣由，而不只僅是流於形式的症狀。

若是一些代碼產生錯誤，直接將其封裝到 try… catch語句中，這樣能夠有效地抑制錯誤。沒有錯，沒有問題，對不對？確定不行對於負責的開發人員來講，掩蓋問題和解決問題是兩回事。隱藏錯誤很容易引發其它意想不到的反作用。在將來的一個緊要關頭，我不想再爲一樣的錯誤而煩惱。

這是由於，除了報告的複製步驟外，我還研究了其餘可能引發相同問題的狀況。

儘管能夠很容易地使錯誤重現，但一組重複步驟每每不足以揭示引起錯誤的深層緣由。在找出這種根源因素的同時，研究一切可行的解決辦法，纔是真正有價值的分析洞見。它可能涉及到代碼的實際工做方式，多是在其餘位置有其餘須要解決的問題，也多是某些代碼不一致的情況(致使某個代碼路徑發生錯誤，而其餘路徑沒有發生錯誤)等等。

因爲我花了一些時間來驗證其餘代碼是否受到相似問題的影響。

假如這個錯誤是由一個 bug引發的，那麼一樣的錯誤應該出如今代碼庫的其餘地方。如今有了用戶報告，最好是完全檢查一下。

因爲找到了錯誤的根源，我想用最簡單的方法來解決問題，保證反作用被控制到最低的風險。

因爲我徹底測試了這個變化，並確保它在不一樣的代碼路徑下解決了相同的問題。

我不想讓別人對修復測試感到麻煩事。在此以前，我不但願再有相似的錯誤發生，所以我不遺餘力確保問題獲得完全解決。環境轉換既複雜又乏味，我但願本身的工做可以使全職測試人員再也不須要作本質上「徹底相同」的更改。

有什麼比修復 bug更麻煩的事情嗎？這意味着重複修復相同的 Bug。您看到的只是我添加的兩行代碼，而沒有看到我在背後分析爲何要添加這兩行代碼，以及爲何這兩行代碼會這樣實現。

天天只寫幾行代碼，這是怎麼回事？

 

 

不少團隊的績效考覈指標都曾經爆出過「代碼行數」的問題，部分測試人員以查「Bug」數爲依據，各大因特網大廠也曾將團隊中動輒上億行代碼做爲品宣賣點。

它讓外界產生一種錯覺，認爲代碼行的數量就是衡量程序員的技術能力、工做成果的萬金標準。能寫的多了，就表明寫的好了？莫非是那種濃密的 if… else衝擊波，還能像寫文章時那樣用排比句式來形容？

林克斯看着想打人。

實際上，程序員的工做產出與代碼行的數量並無很大的關係，並且程序員的工做時間並不侷限於寫代碼。

去年，外國研究機構 ActiveStates進行了一項調查，結果顯示，80多個國家的開發者中，有數千人來自美國和中國。

開發人員平均天天編寫程序的時間不到4小時。

 

 

有38.8%的人在1250個調查樣本中天天只花費2-4個小時來編程。這個結果和2018的調查類似，37%的人天天花2-4個小時來編程。與此相比，27.92%的人天天花5-7小時來編程，而在2018年的調查中有31%的人天天花5-7小時來編程。

更使人吃驚的是，在2019年，61.52%的受訪者花費4小時或更少的時間進行編程，而在2018年，只有51%的人花費4小時或更少的時間進行編程。另有10.56%的人花費8小時或更多的時間進行編程，比2018年的19%降低了近一半。

開發人員編寫代碼所花費的時間愈來愈少了，那麼時間都到哪裏去了？

 

 

百分之四十四的人說他們必須把時間用在各類活動上，包括會議，測試，維護，甚至是社會交往。一個最耗時的活動是軟件設計/體系結構，佔11.36%，而後是參加 standups/會議，佔8.24%。

這些開發人員可能還要花不少時間寫日誌，寫週報，在中國：

這些代碼體現了個人社會情懷，包含了個人哪些精髓技術和商業思惟，最大程度地實現了客戶價值，知足了用戶需求，爲團隊留下了寶貴的技術財富，爲實現數字化經濟增添了一份力量，拉通了團隊，對齊了目標，解決了痛點，賦予了行業，賦予了生命。這是一個很是棒的程序員！

花上兩天的時間，你會不會以爲我很高效？

 

點擊瞭解更多資料，更有免費開源項目和課程等你觀看哦！

------------恢復內容結束------------