寫碼容易,讀碼難:工程師,千萬別重寫程式碼

評論
評論
2987926396_87eb3c3494_b
Photo Credit: Rennett Stowe

本文轉自虎嗅網 《程序員,為什麼千萬不要重寫代碼?》

作為 100offer 工程師拍賣的行銷,我們常常和用戶交流討論,有一個話題經久不衰:工程師入職新公司後接手已有的程式碼,怎麼處理?

大家都有一顆工程師的心,所以當他們到一片新的場地想做的第一件事就是,將舊的一切打掉重來。是的,他們決不會滿足於簡單的增加勞動量。

或許這種微妙的心理定位可以解釋:為什麼工程師進入新專案後寧願丟掉舊程式碼重新寫,也不願意修修補補,他們認為舊程式碼簡直一團糟。

但是,事實上真是這樣嗎?你之所以認為舊程式碼一團糟,其實是由一個基本定律決定的,那就是:寫碼容易,讀碼難。

為什麼你覺得舊程式碼異常混亂?因為讀代碼更難

這大概就是程式碼 Reuse 難以實現的原因,也可以解釋為什麼你組裡的每個人都喜歡用不同的功能將分割的字符串轉換成一個數組。比起猜測舊的功能是怎樣實現的,重新寫一個自己的功能要簡單和有趣多了。

作為這個公理的推論,你可以問問身邊的工程師他們正在奮戰的程式碼怎麼樣?「簡直是一塌糊塗!」他們肯定會這樣說。「我簡直想打掉重來!」

為什麼認為程式碼這麼糟糕呢?「看看這個功能,竟然有兩頁長!完全不知道這些東西為什麼在這裡!完全不知道這些 API 是幹什麼的。」他們會這樣回答你。

 

1154558253.jpg
▲漫畫:讀別人程式碼是一種怎樣的體驗?

曾經, Borland 的創辦人 Philippe Kahn 當初就是向記者們吹噓: Quattro Pro 會比 Microsoft Excel 要好用得多,因為它是從頭開始編寫的,全部都是新的源始碼!

但是,認為新程式碼比舊程式碼好簡直就是荒謬。舊程式碼是已經運行過的,測試過的。無數的 Bug 在被發現前都上線運行過,發現之後工程師們可能在花了好些日子才修復了這些 bug 。這種修復可能是一行程式碼,也可能是幾個字符,無數的時間和精力都花在了這些 bug 修復上。

當你決定拋棄這些舊程式碼從零開始的時候,你也丟掉全部前任努力的結果。

新程式碼一定比舊程式碼好? NO,重寫可能會帶來更大的風險

對技術領導者來說,重寫專案的程式碼代碼也是一個異常艱難的決定。因為從公司層面說,重寫程式碼甚至會威脅產品的市場競爭力。一旦決定重寫程式碼,那麼與競品相比,你可能落後了 2~3 年——在軟體行業,這時間可夠長的。

1156381351
▲你理想中的新程式碼會帶來產品功能的提升

但事實上,即便重寫的新程式碼可以實現舊程式碼的所有功能和需求,但是為產品帶來的市場競爭力只有邊際提升。因為重寫用的新技術、新語言、新框架並沒有給產品帶來質的提昇。

更不用說在重寫的漫長過程中可能會遇到一些意外情況,比如:

1、缺錢:資金鍊的斷裂

1157094204

 

2、缺人:核心工程師離職

1158088674

最終導致效果不佳:達不到原產品應有的所有功能和需求,白白浪費了時間和金錢,也丟掉了市場競爭力。

所以重寫程式碼意味著,你在把自己置身於非常危險的境地,可能幾年後你也寫不出比以前更好的代碼。你只是花了一大筆錢把已經存在的程式碼又寫了一遍。

當你覺得眼前的舊程式碼很爛時,該怎麼辦?

你覺得舊程式碼寫的很爛,那又怎樣呢?它們已經上線,已經在實際運行中承受住了考驗。所以當你發現前任留下的程式碼亂七八糟的時候,不妨冷靜下來,從以下三個方面入手理解程式碼、改善程式碼:

1、程式碼的結構有問題

如果一段網路程式碼突然彈出了自己的對話框,應該是 UI 程式碼需要被處理。這些問題可以被解決掉,你要一次次小心地移動程式碼,重構,改變接口。還需要一位細心的工程師立馬仔細地檢查這些改變是否有問題,從而不打擾到其他人。事實上,甚至比較大的結構變化也可以不扔掉代碼程式碼來完成。

大牛工程師 Joel Spolsky 回憶說,曾經在某個專案中,他和他的團隊花了好幾個月重新架構在一點上:把程式碼動來動去、清理、創建有意義的基類,並創建了模塊之間的完美接口。但是他們始終非常小心翼翼,並沒有產生新的 bug ,也沒有丟掉任何舊程式碼。

2、程式碼的效率不高

曾經, Netscape 的渲染程式碼被傳非常緩慢。但事實上,這只會影響該專案的一小部分,這部分是你可以優化甚至重寫的。你完全不必重寫全部程式碼。優化速度的 1% 工作量,會讓你獲得 99% 的爆炸性提升。

3、程式碼寫得很醜

有些程式碼真的寫的很醜,比如 Joel 曾參與一個專案,開始用下劃線做開始的成員變量協定,但後來改用更標準的「M_」。所以一半的功能用「_」開始,一半用「M」開始,這看起來真的很醜陋。但這個問題 5 分鐘就能解決,而不用從頭開始寫全部的程式碼。

最後,你要記住,從頭開始再寫一遍並不意味著你會寫出比以前更好的程式碼。因為你沒有參與到上一個版本的建立,所以你其實根本就不算有經驗。一旦你準備打掉重寫,你可能會再犯一遍版本一犯過的錯,甚至會產生更多的新問題。

總結

面對糟糕的舊代程式碼 Keep Calm & Carry On!

在大型商業專案中,打掉重來是非常危險的行為。當然,如果你是在做實驗,想到新算法可以隨時重寫。如果你跳槽、或剛接手一個新專案,面對看上去異常混亂的舊程式碼,請冷靜下來,忍住打掉重寫的衝動,想想上面這些經驗之談。

《延伸閱讀》

相關文章

評論