代碼整潔之道

第1章 整潔代碼
1.1 要有代碼
1.2 糟糕的代碼
1.3 混亂的代價
1.3.1 華麗新設計
1.3.2 態度
1.3.3 迷題
1.3.4 整潔代碼的藝術
1.3.5 什麽是整潔代碼
1.4 思想流派
1.5 我們是作者
1.6 童子軍軍規
1.7 前傳與原則
1.8 小結
1.9 文獻
第2章 有意義的命名
2.1 介紹
2.2 名副其實
2.3 避免誤導
2.4 做有意義的區分
2.5 使用讀得出來的名稱
2.6 使用可搜索的名稱
2.7 避免使用編碼
2.7.1 匈牙利語標記法
2.7.2 成員前綴
2.7.3 接口和實現
2.8 避免思維映射
2.9 類名
2.10 方法名
2.11 別扮可愛
2.12 每個概念對應一個詞
2.13 別用雙關語
2.14 使用解決方案領域名稱
2.15 使用源自所涉問題領域的名稱
2.16 添加有意義的語境
2.17 不要添加沒用的語境
2.18 最後的話
第3章 函數
3.1 短小
3.2 只做一件事
3.3 每個函數一個抽象層級
3.4 switch語句
3.5 使用描述性的名稱
3.6 函數參數
3.6.1 一元函數的普遍形式
3.6.2 標識參數
3.6.3 二元函數
3.6.4 三元函數
3.6.5 參數對象
3.6.6 參數列表
3.6.7 動詞與關鍵字
3.7 無副作用
3.8 分隔指令與詢問
3.9 使用異常替代返回錯誤碼
3.9.1 抽離Try/Catch代碼塊
3.9.2 錯誤處理就是一件事
3.9.3 Error.java依賴磁鐵
3.10 別重復自己
3.11 結構化編程
3.12 如何寫出這樣的函數
3.13 小結
3.14 SetupTeardownIncluder程序
3.15 文獻
第4章 注釋
第5章 格式
第6章 對象和數據結構
第7章 錯誤處理
第8章 邊界
第9章 單元測試
第10章 類
第11章 系統
第12章 迭進
第13章 並發編程
第14章 逐步改進
第15章 JUnit內幕
第16章 重構SerialDate
第17章 味道與啟發
附錄A 並發編程II
附錄B org.jfree.date.SerialDate
結束語

樂嚼（Ga-J01）是在丹麥最受歡迎的糖果品種之一，它濃郁的甘草味道，完美地彌補了此地潮濕且時常寒冷的天氣。對於我們這些丹麥人，樂嚼的妙處還在於包裝盒頂上印制的哲言慧語。今早我買了一包兩件裝，在其包裝盒上發現這句丹麥諺語：

AErlighed i sma ting er ikke nogen lille ting.

「小處誠實非小事。」這句話正好是我想在這里說的。以小見大。本書寫到了一些價值殊勝的小主題。

神在細節之中，建築師Ludwig mies van der Rohe（路德維希·密斯·范·德·羅）如是說。這句話引發了有關軟件開發、特別是敏捷軟件開發中架構所處地位的若干爭論。鮑勃（Bob）和我時常發現自己沉湎於此類對話中。沒錯，Ludwig mies van der Rohe的確專注於效用和基於宏偉架構之上的永恆建築形式。然而，他也為自己設計的每所房屋挑選每個門把手。為什麽？因為小處見大。

就TDD話題展開目前仍在繼續的「辯論」時，鮑勃和我認識到，我們均同意軟件架構在開發中占據重要地位，但就其確切意義而言，我們之間還有分歧。然而，這種矛與盾孰利的討論相對而言並不重要，因為在項目開始之時，我們理所當然應該讓專業人士投入些許時間去思考及規划。20世紀90年代末期有關僅以測試和代碼驅動設計的概念已一去不返。相對於任何宏偉願景，對細節的關注甚至是更為關鍵的專業性基礎。首先，開發者通過小型實踐獲得可用於大型實踐的技能和信用度。其次，宏大建築中最細小的部分，比如關不緊的門、有點兒沒鋪平的地板，甚至是凌亂的桌面，都會將整個大局的魅力毀滅殆盡。這就是整潔代碼之所系。

架構只是軟件開發用到的借喻之一，主要用在那種等同於建築師交付毛坯房一般交付初始軟件產品的場合。在Serum和敏捷（Agile）的日子里，人們關注的是快速將產品推向市場。我們要求工廠全速運轉、生產軟件。這就是人類工廠：懂思考、會感受的編碼人，他們由產品備忘或用戶故事開始創造產品。來自制造業的借喻在這種場合大行其道。例如，Serum就從裝配線式的日本汽車生產方式中獲益良多。

即使是在汽車工業里，大量工作也並不在於生產而在於維護——或避免維護。對於軟件而言，百分之八十或更多的工作量集中在我們美其名曰「維護」的事情上：其實就是修修補補。與其接受西方關於制造好軟件的傳統看法，不如將其看作建築工業中的房屋修理工，或者汽車領域的汽修工。日本式管理對於這種事怎麽說的呢？

大約在1951年，一種名為「全員生產維護」（Tota1 Productive Maintenancc，TPM）的質量保證手段在日本出現。它關注維護甚於關注生產。TPM的主要支柱之一是所謂的5S原則體系。5S是土套規程，用「規程」這個詞，是為了讀者便於理解。5S原則真實是精益（Lcan）——西方視野中的一個時髦詞，也是在軟件領域漸領風騷的時髦詞——的基石所在。正如鮑勃大叔（unclc Bob）在前言中寫到的，良好的軟件實踐遵循這些規程：專注、鎮定和思考。這並非總只有關實作，有關推動工廠設備以最高速庋運轉。5S哲學包括以下概念：

·整理（Seiri），或謂組織（想想英語中的sort（分類、排序）一詞）。搞清楚事物之所在——通過恰當地命名之類的手段——至關重要。覺得命名標識無關緊要？讀讀後面的章節吧。

·整頓（Seiton），或謂整齊（想想英文中的systcmatizc（系統化）一詞）。有句美國老話說：物皆有其位，而後物盡歸其位（A place for everything，and everything in its place）。每段代碼都該在你希望它所在的地方——如杲不在那里，就需要重構了。

·清楚（Seiso），或謂清潔（想想英文中的shinc（ 亮）一詞）。清理工作地的拉線、油污和邊角廢料。對於那種四處遺棄的帶注釋的代碼及反映過往或期望的無注釋代碼，本書作者怎麽說的來著？除之而後快。

·清潔（Sciketsu），或謂標准化。有關如何保持工作地清潔的組內共識。本書有沒有提到在開發組內使用一貫的代碼風格和實踐手段？這些標准從哪里來？讀讀看。

·身美（Shitsuke），或謂紀律（自律）。在實踐中貫徹規程，並時時體現於個人工作上，而且要樂於改進。

如果你接受挑戰——沒錯，就是挑戰，鬩讀並應用本書，你就會理解和贊賞上述最後一條。我們最終是在駛向一種負責任的專業精神之根源所在，這種專業性隸屬於一個關注產品生命周期的專業領域。在我們遵循TPM來維護機動車和其他機械時，停機維護——等待缺陷顯現出來——並不常見。我們更上一層樓：每天檢查機械，在磨損機件停止工作之前就換掉它，或者按常例每1000英里（約1609.3km）就更換潤滑油、防止磨損和開裂。對手代碼，應無情地做重構。還可以更進一步，就像TPM運動在50多年前的創新：一開始就打造更易維護的機械。寫出可讀的代碼，重要程度不亞於寫出可執行的代碼。1960年左右，圍繞TPM引入的終極實踐（ultimate practice），關注用全新機械瞀代舊機械。誡如Fred Brokks所言，我們或許應該每7年就重做一次軟件的主要模塊，清理緩慢陳腐的代碼。距許我們該把重構周期從以年計縮短到以周、以天甚至以小時計。那便是細節所在了。

細節中自有天地，而在生活中應用此類手段時也有微言大義，就像我們一成不變地對那些源自日本的做法寄予厚望一般。這並非只是東方的生活觀；英美民間也遍是這類警句。上引「整頓」（Seiton）二字就曾出現在某位俄亥俄州牧師的筆下，他把齊整看作是「盪滌種種罪惡之良方」。「清楚」（Seiso）又如何呢？整潔近乎虔誠（Cleanliness is next to godliness）。一張臟亂的桌子足以奪去一所麗宅的光彩。老話怎麽說「身美」（Shitsuke）的？寺小節者不虧大節（He who is faithful in little is faithful in much）。對於時時准備在恰當時機做重構，為未來的「大」決定夯實基礎，而不是置諸腦後，有什麽說法嗎？及時一針省九針（A stitch in time saves nine）。早起的鳥兒有蟲吃（The early bird catches the worm）。日事日畢（Don』t put off until tomorrow what you can do today）。在精益實踐落入軟件咨詢師之手前，這就是其所謂「最後時機」的本義所在。擺正單項工作在整體中的位置昵？巨木生於樹籽（Mighty oaks from little acorns grow）。如何在日常生活中做好簡單的防備性工作昵？防病好過治病（An ounce of prevention is worth a pound of cure）。一天一蘋果，醫生遠離我（An apple a day keeps the doctor away）。整潔代碼以其對細節的關注，榮耀了深埋於我們現有、或曾有、或該有的壯麗文化之下的智薏根源。

即便是在宏偉的建築作品中，我們也聽到夫注細節的回響。想想Ludwig mies van der Rohe的門把手吧。那正是整理（seiri）。認真對待每個變量名。你當用為自己第一個孩子命名般的謹慎來給變量命名。

┅┅