閱讀作業之Big Ball of Mud——洪虹

　　大泥球，是指雜亂無章、錯綜複雜、邋遢不堪、隨意拼貼的大堆代碼。這些年來，為了對付這個泥球，我們看到了多種指導方法，比如SOLID、GRASP和KISS，與其他諸多年代久遠的、提倡高內聚、低耦合的方法一起出現。然而，實際情形沒多大變化，“大泥球”看起來仍然是設計軟體架構的最常見方法。我們現在慣用的敏捷性開發（Agile）的很多方面會直接導致泥球，包括：缺少前期設計、應對需求變化過晚、應對架構變化過晚、片段式增長。

　　我們理想中的代碼是清晰的，優雅的，雲淡風輕，一望無垠，坐在電腦前深呼吸，都能聞到雨後泥土的芬芳。但是現實呢？一開啟編譯器就頭痛。代碼看得眼花，整天去修BUG，還要花半天時間先讀以前的代碼。好不容易改完提交了，第二天卻報出更多的新BUG。

　　其實，我們的軟體，在發布前，其實就已經百病纏身了，隨著功能的增加，便有了BUG，老的BUG改了，可能引入新的BUG。複雜的商業軟體多少都會有BUG。我們思考這樣幾個問題：我們如何發現爛代碼？爛代碼要不要改呢？應該怎麼改？如果爛代碼不是先天性的，那是不是可以預防？

　　很多時候無論花費多少時間試圖去找出完美的軟體結構,客戶總是引入一個變化破壞這個結構,不存在完美結構,只存在那些試圖平衡當前的代價和收益的結構。有時候,我們會把原因歸咎於客戶,責怪他們總是改變需求。有些人認為,只要客戶的需求僅限於他們最初所聲明的,那麼我們的設計就是沒問題的,所以錯就錯在客戶改變了他們的需求。需求變化是非常正常的，JOBS說“使用者根本不知道他想要什麼，直到你把產品交到他的手中”。這種情況也是或多或少存在的。但是，客戶連原始碼都看不到，這種怨念卻是沒道理的。

　　制約程式員編寫高品質代碼的因素有哪些？對需求和設計的理解不透徹，對軟體商務程序不熟悉，沒有開發經驗，不知道怎樣的代碼是好的，對開發工具或開發語言不熟悉，缺少監督體系或不重視品質評估，受情緒因素的影響等因素，其它非代碼因素也起著關鍵作用。很多時候，好的代碼會促生好的代碼，糟糕的代碼也會促生糟糕的代碼。沒人想去整理糟糕的代碼，同樣沒人想把完美的代碼弄得一團糟。因此，保持代碼整潔很重要。

　　函數的第一規則是要短小，第二條規則是要更短小。 我無法證明這個斷言，我給不出任何證實了小函數更好的研究結果，我能說的是，40年來，我寫過各種不同大小的函數，我寫過另人憎惡的長達3000行的厭物，也寫過許多100行到300行的函數，我還寫過20行到30行的。經過漫長的試錯，經驗告訴我，函數就該小。

    ——《代碼整潔之道》

　　我們團隊的代碼中也肯定存在著大泥球，有些已經被發現的我們都已經儘力最佳化，比如我寫使用者排名RANK類的時候需要多次判斷同一調用函數Sum的傳回值,這時候定義一個變數就能避免沒有必要的多次調用，大大提高了代碼效率。當然肯定還存在一些還沒被發現的大泥球，還有待我們進一步檢查。