我們在做任何系統的時候，都不要指望系統一開始時需求確定，就再也不會變化，這是不現實也不科學的想法，而既然需求是一定會變化的，那麼如何在面對需求的變化時，設計軟體的可以相對容易修改，不至於說，新需求一來，就要把整個程式推倒重來。

夠用的程式碼

曾經一個同事跟我吐槽過，隊友工作四五年了，程式碼質量依然不咋樣，命名不規範，邏輯嘛，除了自己外，誰也看不懂，註釋更是鳳毛麟角，但是這樣的程式碼卻能正常執行著，每次出bug，都能迅速定位，每個變數和方法，不看程式碼都能說出來，並且bug還不高，很神奇。

是的，這個問題現在社會中還真很常見，命名混亂，不加註釋，這是目前很普遍的現象。我也遇到一些朋友，有的甚至寫了快十年的程式碼了，依然寫的一坨一坨的，看了都難受，還有一部分完全是看不懂的命名和邏輯，但bug率卻很低，對於這樣的程式碼應該怎麼定義？豬隊友寫的蠢玩意？還真不能這樣定義，如果這個工程自始至終只有一個人維護，那個人也維護的很好，那它似乎就成了夠用的程式碼。當然，這樣的程式碼肯定算不上好程式碼，如果作者離職了，那功能模組只能選擇重構了，維護的成本是顯而易見的。反而言之，寫的再優雅，程式碼跟詩一樣，但bug滿螢幕都是，也是爛程式碼，就好像一篇好文章到處錯別字一樣，看的也頭疼。

爛程式碼的主要由來

相信很多朋友都遇到過，原本一個很普通的需求，在經歷過N次迭代和修改後，bug的不斷修復，再加上大量冗餘的程式碼，已經形成一個龐大的模組，隨著版本的不斷迭代，維護起來的成本也隨著越來越大，再過上一段時間，有個相似的需求，想要複用裡面的邏輯，這時才意識到程式碼裡做了各種特定場景的專用邏輯，可複用性和靈活性太差，為了趕進度只好拷程式碼然後改一改。問題解決的同時，問題也加倍了，這樣就形成了一種惡性迴圈，夠用程式碼漸漸也會為了一個重大的負擔，維護，越來越覺得力不從心。

絕大部分的爛程式碼都是由夠用的程式碼演化而來，當自己還能快速維護的時候，這就是夠用的程式碼，但作者離職或者作者也越來越難維護的時候，就形成了爛程式碼。

是否真的要重構？

不可否認，從維護成本上看，重構確實是一個很不錯的方案，重構的成本比原基礎維護的成本更小，也更方便以後的維護。有些公司甚至在多次版本迭代後，直接把整個專案推到重構，這樣的事情不僅僅發生在小公司，在一些大公司，也是會發生多次。

從技術上來說，重構複雜程式碼時要做三件事：理解舊程式碼、分解舊程式碼、構建新程式碼。而待重構的舊程式碼往往難以理解，尤其是在多次迭代且多人經手的模組；模組之間過度耦合導致牽一髮而動全身，不易控制影響範圍；舊程式碼不易測試導致無法保證新程式碼的正確性，尤其是在產品文件不全的時候。這三個操作，每個操作都是很難的。對於重構，不一定要用到某些設計模式才顯得合理，在文件健全的情況下，你可以先畫圖，把一個大的模組拆分拆解，面向這些拆解後的功能模組程式設計，看起來會更好一點。

但對於一些人來說，重構並不是一個好的方式，只會浪費更多的時間，花了大量時間，辛辛苦苦重構的程式碼，卻在很不輕易間，又回到了原來的難以維護的狀態。比如，有些人寫程式碼寫成一種習慣了，就像一個人生活的房間，本來就是髒亂差的那種（爛程式碼），請了保潔阿姨打掃後（重構），生活了一段時間後，臭襪子不分東西，菸頭不分南北，各種零食袋遍地都是，再次回到了髒亂差的時代，只有平時生活中養成一個好的習慣，拋棄一些不好的習性，才能寫出更優質的程式碼。

建議：重構，並不是萬能的，重構後的程式碼，當再次經歷後續幾個版本修改後，程式碼又顯的雜亂無章，那一坨坨程式碼總是在不斷的重演。既然無法確定需求日後是否會修改，那我們只能通過提高程式碼質量來應對，以不變應萬變，合理設計介面，每次更改需求時多思考，對於多次使用的程式碼進行封裝提取，儘可能少的改動既有的邏輯。

必要的重構

大量重複或冗餘的程式碼–>上文提到，可複用性和靈活性太差，為了趕進度只好拷程式碼然後改一改，這樣的情況還是比較常見的，如果同一個類中有相同的程式碼塊，請把它提煉成一個獨立的方法，如果不同類中具有相同的程式碼，請把它提煉成一個新類。

過大的類和過長的方法–>過大的類往往是類抽象不合理的結果，類抽象不合理將降低了程式碼的複用率。親身體驗，當看到一個龐大的類的時候，內心就有點慫了，尤其是一些不規範的寫法後，看了顯得很蛋疼。過長的方法由於包含的邏輯過於複雜，錯誤機率將直線上升，而可讀性則直線下降，類的健壯性很容易被打破，可讀性和可維護性都不太好。當看到一個過長的方法時，需要想辦法將其劃分為多個小方法，以便於提高可讀性和可維護性。

高耦合性–>當增刪改一個小功能時，牽一髮而動全身，功能模組與功能模組之間直接用類耦合，這些都是不合理的，這些都是抽象設計的不夠理想，功能程式碼太過分散所引起的，面向介面程式設計思想還需要提高，儘可能拋開面向實現程式設計。

臃腫的類–>類之所以會臃腫，是因為開發者缺乏對最基本的編碼原則，即“單一職責原則”（SRP）的理解。這些類往往會變得很臃腫，是由於不同的且在功能上缺少關聯的方法都放在了相同的類裡面。

不規範的書寫–>不規範的命名、錯誤的書寫習慣、缺乏必要的註釋、亂七八糟的邏輯等，形成了一坨爛程式碼，別人沒法維護，自己維護越來越乏力。

建議：最好別把希望寄託於重構，應該在日常開發中更加註重書寫習慣，才能節約更多的時間，把規範養成一種習慣。總結的應該不全，目前只能想到這麼幾條，也歡迎各位補充。

總結

“一個程式設計師用在寫程式上的時間大概佔他的工作時間的10-20%，大部分的程式設計師每天大約能寫出10-12行的能進入最終的產品的程式碼——不管他的技術水平有多高。好的程式設計師花去90%的時間在思考、研究和實驗，來找出最優方案。差的程式設計師花去90%的時間在除錯問題程式、盲目的修改程式，期望某種寫法能可行。”這句話摘抄自《鮮為人知的程式設計真相》，我很喜歡這句話，做好碼前思考和準備，才能寫出更優質的程式碼，一個良好的習慣，勝於一切。

微信掃我