程式設計師,千萬不要重寫程式碼

qwzs112發表於2015-12-06

  如果你跳槽、或剛接手一個新專案,面對看上去異常混亂的舊程式碼,請冷靜下來,忍住推倒重寫的衝動。

程式設計師,千萬不要重寫程式碼

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

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

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

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

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

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

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

讀別人的程式碼是種什麼樣的體驗

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

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

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

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

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

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

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

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

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

 1、缺錢:資金鍊的斷裂

  2、缺人:核心程式設計師離職

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

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

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

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

  1、程式碼的結構有問題

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

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

  2、程式碼的效率不高

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

  3、程式碼寫得很醜

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

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

  總結

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

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

相關文章