《修改代碼的藝術》 - 書摘精要

(序) 需求總是在改變；

(前言)

沒有編寫測試的代碼是糟糕的代碼；

編程可以是一項回報豐厚並讓人感覺是一種享受的工作；

(P4) 在不改變軟件行爲的前提下改善其設計的舉動稱爲重構；

(P6)

問題總是不可避免；

要想保持熟練，唯一的途徑就是經常練習；

(P8) 精湛的軟件改動就像精湛的外科手術一樣，除了細心之外還要有深厚的技術。如果沒有輔以正確的工具和技術，即便“小心下手”也起不到多大作用；

(P11) 一個需要耗時十分之一秒才能執行完的單元測試，就已算是一個慢的單元測試了；

(P14)

依賴性是軟件開發中最爲關鍵的問題之一；

遺留代碼的困境 —— 我們在修改該代碼時，應當有測試在周圍“護”着。而爲了將這些測試安置妥當，我們往往又得先去修改代碼；

(P22) 遵循爲獨立單元編寫測試的理念，我們最終寫出來的就會是短小而易於理解的一個個測試，這會使得我們的代碼變得更易理解；

(P40) 重構 —— 對軟件內部結構的一種調整，目的是在不改變軟件的外在行爲的前提下，提高其可理解性，降低其修改成本；

(P72)

依賴倒置原則 ——

如果你的代碼依賴於一個接口，那麼這個依賴一般來說是很次要的。除非這個接口發生改變，否則你的代碼是無需改變的，而接口的改動頻率通常情況下要遠遠低於接口背後的那些代碼。在接口不變的前提下，不管是修改實現了該接口的類，還是添加實現了該接口的新類，接口的客戶代碼都不會受到影響；

因爲這個原因，較好的做法是讓代碼依賴於接口或抽象類，而不是依賴於具體類。當代碼依賴的是較爲穩定的東西時，因特定改動而導致大規模重編譯的可能性也就被降到了最低；

當爲瞭解依賴而往設計中引入了額外的接口和包之後，重新構建整個系統的時間就會稍微變長一點。因爲有更多的文件要去編譯。但基於需要被重編譯的文件而進行的局部重建的平均時耗反而大大縮短了；

(P79) 測試驅動開發與遺留代碼 —— 測試驅動開發的最有價值的一個方面是它使得我們可以在同一時間只關注於一件事情。要麼是在編碼，要麼是在重構；永遠也不會在同一時刻做兩件事情；

(P116) 好的設計應當是可測試的，不具可測試性的設計是糟糕的；

(P180) “CRC” —— “類”(Class)、“職責”(Responsibility)和“協作”(Collaboration)；

(P200) 單一職責原則 —— 每個類應該僅承擔一個職責：它在系統中的意圖應當是單一的，且修改它的原因應該只有一個；

(P212) 接口隔離原則 —— 如果一個類體積較大，那麼很可能它的客戶並不會使用其所有方法。通常我們會看到特定用戶使用特定的一組方法。如果我們給特定用戶使用的那組方法創建一個接口，並讓這個大類實現該接口，那麼用戶便可以使用“屬於它的”那個接口來訪問我們的類了。這種做法有利於信息隱藏，此外也減少了系統中存在的依賴。即當我們的大類發生改變的時候，其客戶代碼便不再需要重新編譯了；

(P231) 開放/封閉原則 —— 開放/封閉原則是由Bertrand Meyer首先提出的。其背後的理念是：代碼對於擴展應該是開放的，而對於修改則應該是封閉的。也就是說，對於一個好的設計，我們無需對代碼做太多的修改就可以添加新的特性；

(P249) 編程是關於同一時間只做一件事情的藝術；

(P260) 接口應傳達職責而非實現細節，這樣的接口令代碼易於閱讀和維護；

(P289) 提取接口時並不一定要提取類上的所有公有方法，你可以依靠編譯器來幫助你發現哪些方法需要加到接口上去；