關于爛代碼的那些事（下）

class Foo {
   boolean foo() {
   ...
   }
 }

 class Foo {
  boolean foo() {
  ...
  }
 }
 

class FooAdaptor {
    private Foo foo;
    boolean foo() {
       return foo.foo().isEmpty();
    }
 }

 class FooAdaptor {
    private Foofoo;
    boolean foo() {
      return foo.foo().isEmpty();
    }
 }
 

</div>

這樣做的好處是修改函數時不需要改動所有調用方，爛代碼的特征之一就是模塊間的耦合比較高，往往一個函數有幾十處調用，牽一發而動全身。而一旦開始全面改造，往往就會把一次看起來很簡單的重構演變成幾周的大工程，這種大規模重構往往是不可靠的。

每次模塊級別的重構都需要精心設計，提前劃分好哪些是需要修改的，哪些是需要用兼容邏輯做過渡的。但實際動手修改的時間都不應該超過一天，如果超過一天就意味著這次重構改動太多，需要控制一下修改節奏了。

1.2.4. 工程級別的重構不能和任何其他任務并行

不安全的重構相對而言影響范圍比較大，比如：

• 修改工程結構
• 修改多個模塊

我更建議這類操作不要用IDE，如果使用IDE，也只使用最簡單的“移動”操作。這類重構單元測試已經完全沒有作用，需要集成測試的覆蓋。不過也不必緊張，如果只做“移動”的話，大部分情況下基本的冒煙測試就可以保證重構的正確性。

這類重構的目的是根據代碼的層次或者類型進行拆分，切斷循環依賴和結構上不合理的地方。如果不知道如何拆分，可以依照如下思路：

1. 優先按部署場景進行拆分，比如一部分代碼是公用的，一部分代碼是自己用的，可以考慮拆成兩個部分。換句話說，A服務的修改能不能影響B服務。
2. 其次按照業務類型拆分，兩個無關的功能可以拆分成兩個部分。換句話說，A功能的修改能不能影響B功能。
3. 除此之外，盡量控制自己的代碼潔癖，不要把代碼切成一大堆豆腐塊，會給日后的維護工作帶來很多不必要的成本。
4. 案可以提前review幾次，多參考一線工程師的意見，避免實際動手時才冒出新的問題。

而這類重構絕對不能跟正常的需求開發并行執行：代碼沖突幾乎無法避免，并且會讓所有人崩潰。我的做法一般是在這類重構前先演練一次：把模塊按大致的想法拖來拖去，通過編譯器找到依賴問題，在日常上線中把容易處理的依賴問題解決掉；然后集中團隊里的精英，通知所有人暫停開發，花最多2、3天時間把所有問題集中突擊掉，新的需求都在新代碼的基礎上進行開發。

如果歷史包袱實在太重，可以把這類重構也拆成幾次做：先大體拆分成幾塊，再分別拆分。無論如何，這類重構務必控制好變更范圍，一次嚴重的合并沖突有可能讓團隊中的所有人幾個周緩不過勁來。

1.3. 重構的周期

典型的重構周期類似下面的過程：

1. 在正常需求開發的同時進行模塊內部的重構，同時理解工程原有代碼。
2. 在需求間隙進行模塊級別的重構，把大模塊拆分為多個小模塊，增加腳手架類，補充單元測試，等等。
3. （如果有必要，比如工程過于巨大導致經常出現相互影響問題）進行一次工程級別的拆分，期間需要暫停所有開發工作，并且這次重構除了移動模塊和移動模塊帶來的修改之外不做任何其他變更。
4. 重復1、2步驟

1.3.1. 一些重構的tips

1. 只重構經常修改的部分，如果代碼一兩年都沒有修改過，那么說明改動的收益很小，重構能改善的只是可維護性，重構不維護的代碼不會帶來收益。
2. 抑制住自己想要多改一點的沖動，一次失敗的重構對代碼質量改進的影響可能是毀滅性的。
3. 重構需要不斷的練習，相比于寫代碼來說，重構或許更難一些。
4. 重構可能需要很長時間，有可能甚至會達到幾年的程度（我之前用斷斷續續兩年多的時間重構了一個項目），主要取決于團隊對于風險的容忍程度。
5. 刪除無用代碼是提高代碼可維護性最有效的方式，切記，切記。
6. 單元測試是重構的基礎，如果對單元測試的概念還不是很清晰，可以參考 使用Spock框架進行單元測試 。

2. 改善性能與健壯性

2.1. 改善性能的80%

性能這個話題越來越多的被人提起，隨便收到一份簡歷不寫上點什么熟悉高并發、做過性能優化之類的似乎都不好意思跟人打招呼。

說個真事，幾年前在我做某公司的ERP項目，里面有個功能是生成一個報表。而使用我們系統的公司里有一個人，他每天要在下班前點一下報表，導出到excel，再發一封郵件出去。

問題是，那個報表每次都要2，3分鐘才能生成。

我當時正年輕氣盛，看到有個兩分鐘才能生成的報表一下就來了興趣，翻出了那段不知道誰寫的代碼，發現里面用了3層循環，每次都會去數據庫查一次數據，再把一堆數據拼起來，一股腦塞進一個tableview里。

面對這種代碼，我還能做什么呢？

• 我立刻把那個三層循環干掉了，通過一個存儲過程直接輸出數據。
• sql數據計算的邏輯也被我精簡了，一些沒必要做的外聯操作被我干掉了。
• 我還發現很多ctrl+v生成的無用的控件（那時還是用的delphi），那些控件密密麻麻的貼在顯示界面上，只是被前面的大table擋住了，我當然也把這些玩意都刪掉了；
• 打開界面的時候還做了一些雜七雜八的工作（比如去數據庫里更新點擊數之類的），我把這些放到了異步任務里。
• 后面我又覺得沒必要每次打開界面都要加載所有數據（那個tableview有幾千行，幾百列！），于是我hack了默認的tableview，每次打開的時候先計算當前實際顯示了多少內容，把參數發給存儲過程，初始化只加載這些數據，剩下的再通過線程異步加載。

做了這些之后，界面只需要不到1s就能展示出來了，不過我要說的不是這個。

后來我去客戶公司給那個操作員演示新的模塊的時候，點一下，刷，數據出來了。那個人很驚恐的看著我，然后問我，是不是數據不準了。

再后來，我又加了一個功能，那個模塊每次打開之后都會顯示一個進度條，上面的標題是“正在校驗數據……”，進度條走完大概要1分鐘左右，我跟那人說校驗數據計算量很大，會比較慢。當然，實際上那60秒里程序毛事都沒做，只是在一點點的更新那個進度條（我還做了個彩蛋，在讀進度的時候按上上下下左右左右BABA的話就可以加速10倍讀條…）。客戶很開心，說感覺數據準確多了，當然，他沒發現彩蛋。

我寫了這么多，是想讓你明白一個事實：大部分程序對性能并不敏感。而少數對性能敏感的程序里，一大半可以靠調節參數解決性能問題；最后那一小撮需要修改代碼優化性能的程序里，性價比高的工作又是少數。

什么是性價比？回到剛才的例子里，我做了那么多事，每件事的收益是多少？

• 把三層循環sql改成了存儲過程，大概讓我花了一天時間，讓加載時間從3分鐘變成了2秒，模塊加載變成了”唰“的一下。
• 后面的一坨事情大概花了我一周多時間，尤其是hack那個tableview，讓我連周末都搭進去了。而所有的優化加起來，大概優化了1秒左右，這個數據是通過日志查到的：即使是我自己，打開模塊也沒感覺出有什么明顯區別。

我現在遇到的很多面試者說程序優化時總是喜歡說一些玄乎的東西：調用棧、尾遞歸、內聯函數、GC調優……但是當我問他們：把一個普通函數改成內聯函數是把原來運行速度是多少的程序優化成多少了，卻很少有人答出來；或者是扭扭捏捏的說，應該很多，因為這個函數會被調用很多遍。我再問會被調用多少遍，每遍是多長時間，就答不上來了。

所以關于性能優化，我有兩個觀點：

1. 優化主要部分，把一次網絡IO改為內存計算帶來的收益遠大于捯飭編譯器優化之類的東西。這部分內容可以參考Numbers you should know；或者自己寫一個for循環，做一個無限i++的程序，看看一秒鐘i能累加多少次，感受一下cpu和內存的性能。
2. 性能優化之后要有量化數據，明確的說出優化后哪個指標提升了多少。如果有人因為”提升性能“之類的理由寫了一堆讓人無法理解的代碼，請務必讓他給出性能數據：這很有可能是一坨沒有什么收益的爛代碼。

至于具體的優化措施，無外乎幾類：

1. 讓計算靠近存儲
2. 優化算法的時間復雜度
3. 減少無用的操作
4. 并行計算

關于性能優化的話題還可以講很多內容，不過對于這篇文章來說有點跑題，這里就不再詳細展開了。

2.2. 決定健壯性的20%

前一陣聽一個技術分享，說是他們在編程的時候要考慮太陽黑子對cpu計算的影響，或者是農民伯伯的豬把基站拱塌了之類的特殊場景。如果要優化程序的健壯性，那么有時候就不得不去考慮這些極端情況對程序的影響。

大部分的人應該不用考慮太陽黑子之類的高深的問題，但是我們需要考慮一些常見的特殊場景，大部分程序員的代碼對于一些特殊場景都會有或多或少考慮不周全的地方，例如：

• 用戶輸入
• 并發
• 網絡IO

常規的方法確實能夠發現代碼中的一些bug，但是到了復雜的生產環境中時，總會出現一些完全沒有想到的問題。雖然我也想了很久，遺憾的是，對于健壯性來說，我并沒有找到什么立竿見影的解決方案，因此，我只能謹慎的提出一點點建議：

• 更多的測試測試的目的是保證代碼質量，而不僅僅是經歷一個流程。對于這類測試，往往越接近實際使用環境越好。關于測試又是一個巨大的話題，這里就先不展開了。
• 謹慎發明輪子例如UI庫、并發庫、IO client等等，在能滿足要求的情況下盡量采用成熟的解決方案，所謂的“成熟”也就意味著經歷了更多實際使用環境下的測試，大部分情況下這種測試的效果是更好的。

3. 改善生存環境

看了上面的那么多東西之后，你可以想一下這么個場景：

任何一個對代碼有追求的程序員都有可能遇到這種問題，技術在更新，需求在變化，公司人員會流動，而代碼質量總會在不經意間偷偷的變差……

想要改善代碼質量，最后往往就會變成改善生存環境。

3.1.1. 統一環境

團隊需要一套統一的編碼規范、統一的語言版本、統一的編輯器配置、統一的文件編碼，如果有條件最好能使用統一的操作系統，這能避免很多無意義的工作。

就好像最近渣浪給開發全部換成了統一的macbook，一夜之間以前的很多問題都變得不是問題了：字符集、換行符、IDE之類的問題只要一個配置文件就解決了，不再有各種稀奇古怪的代碼沖突或者不兼容的問題，也不會有人突然提交上來一些編碼格式稀奇古怪的文件了。

3.1.2. 代碼倉庫

代碼倉庫基本上已經是每個公司的標配，而現在的代碼倉庫除了儲存代碼，還可以承擔一些團隊溝通、代碼review甚至工作流程方面的任務，如今這類開源的系統很多，像gitlab(github)、Phabricator這類優秀的工具都能讓代碼管理變得簡單很多。

代碼倉庫的意義在于讓更多的人能夠獲得和修改代碼，從而提高代碼的生命周期，而代碼本身的生命周期足夠持久，對代碼質量做的優化才有意義。

3.1.3. 持續反饋

大多數爛代碼就像癌癥一樣，當爛代碼已經產生了可以感覺到的影響時，基本已經是晚期，很難治好了。

因此提前發現代碼變爛的趨勢很重要，這類工作可以依賴類似于checkstyle，findbug之類的靜態檢查工具，及時發現代碼質量下滑的趨勢，例如：

1. 每天都在產生大量的新代碼
2. 測試覆蓋率下降
3. 靜態檢查的問題增多

有了代碼倉庫之后，就可以把這種工具與倉庫的觸發機制結合起來，每次提交的時候做覆蓋率、靜態代碼檢查等工作，jenkins+sonarqube或者類似的工具就可以完成基本的流程：伴隨著代碼提交進行各種靜態檢查、運行各種測試、生成報告并供人參考。

在實踐中會發現，關于持續反饋的五花八門的工具很多，但是真正有用的往往只有那么一兩個，大部分人并不會去在每次提交代碼之后再打開一個網頁點擊“生成報告”，或者去登陸什么系統看一下測試的覆蓋率是不是變低了，因此一個一站式的系統大多數情況下會表現的更好。

當然，關于持續集成還可以做的更多，篇幅所限，就不多說了。

3.1.4. 質量文化

不同的團隊文化會對技術產生微妙的影響，關于代碼質量沒有什么共同的文化，每個公司都有自己的一套觀點，并且似乎都能說得通。

對于我自己來說，關于代碼質量是這樣的觀點：

1. 爛代碼無法避免
2. 爛代碼無法接受
3. 爛代碼可以改進
4. 好的代碼能讓工作更開心一些

如何讓大多數人認同關于代碼質量的觀點實際上是有一些難度的，大部分技術人員對代碼質量的觀點是既不贊成、也不反對的中立態度。但是想要提升代碼質量僅僅依靠一個人是絕對不夠的：寫爛代碼的成本實在是太低了，以至于一個實習生花上一個禮拜就可以毀了你花了半年精心設計的工程。

所以在提高代碼質量時，務必想辦法拉上團隊里的其他人一起。這里推薦《布道之道：引領團隊擁抱技術創新》這本書，里面大部分的觀點對于代碼質量也是可以借鑒的。

雖然“引導團隊提高代碼質量”這件事情一開始會很辛苦，但是一旦有了一些支持者，并且有了可以參考的模板之后，剩下的工作就簡單多了。

4. 最后再說兩句

優化代碼質量是一件很有意思，也很有挑戰性的事情，而挑戰不光來自于代碼原本有多爛，要改進的也并不只是代碼本身，還有工具、習慣、練習、開發流程、甚至團隊文化這些方方面面的事情。

寫這一系列文章前前后后花了半年多時間，一直處在寫一點刪一點的狀態：我自身關于代碼質量的想法和實踐也在經歷著不斷變化。我更希望能寫出一些能夠實踐落地的東西，而不是喊喊口號，忽悠忽悠“敏捷開發”、“測試驅動”之類的幾個名詞就結束了。

但是在寫文章的過程中就會慢慢發現，很多問題的改進方法確實不是一兩篇文章可以說明白的，問題之間往往又相互關聯，全都展開說甚至超出了一本書的信息量，所以這篇文章也只能刪去了很多內容。

我參與過很多代碼質量很好的項目，也參與過一些質量很爛的項目，改進了很多項目，也放棄了一些項目。無論如何，關于爛代碼，我決定引用一下《布道之道》這本書里的一句話：

</div>

來自： http://blog.2baxb.me/archives/1499