重構 - List of Sound Bites(原音重現)

以下節錄《重構-改善即有的設計》一書最後一篇的重點清單，此章我認為是《重構-改善即有的設計》此書中最重要的一章，它提出讓程式裡不應該有的壞味道。

p.7
When you find you have to add a feature to a program, and the program’s code is no structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.
如果你發現自己需要為或式添加一個特性，而程式碼結構使你無法很方便地那麼做，那就先重構那個程式，使特性的添加比較容易進行，然後再添加特性。
p.8
Before you start refactoring, check that you have a solid suite of tests. These must be self-checking.
重構前，先檢查自己是否有一套可靠的測試機制。這些測試必須有自我檢驗能力。
p.13
Refactoring changes the programs in small steps. If you make a mistake, it is easy to find the bug.
重構技術係以微小的步伐修改程式。如果你犯下錯誤，很容易便可發現它。
p.15
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
任何一個傻瓜都能寫出電腦可以理解的程式碼。唯有寫出人類容易理解的程式碼，才是優秀的程式員。
p.53
Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior of the software.
重構 (名詞)：對軟體內部結樣的一種調整，目的是在不改變「軟體之可察行為」前提下，提高其可理解性，降低其修改成本。
p.54
Refactor (verb): to restructure software by applying a series of refactorings without changing the observable behavior of the software.
重構 (重詞)：使用一系列重構準則（手法），在不改變「軟體之可察行為」前提下，調整其結構。
p.58
Three strikes and you refactor.
事不過三，三則重構。
p.65
Don’t publish interfaces prematurely. Modify your code ownership policies to smooth refactoring.
不要過早發佈介面。請修改你的程式碼擁有權政策，使重構更順暢。
p.88
When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.
當你感覺需要撰寫註釋，請先嘗試重構，試著讓所有註釋都變得多餘。
p.90
Make sure all tests are fully automatic and that they check their own results.
確保所有測試都完全自動化，讓它們檢查自己的測試結果。
p.90
A suite of tests is a powerful bug detector that decapitates the time it takes to find bugs.
一整組測試就是一個強大的臭蟲偵測器，能夠大大縮減搜尋臭蟲所需的時間。
p.94
Run your tests frequently. Localize tests whenever you compile – every test at least every day.
頻繁地執行測試。每次編譯請把測試也考慮進去 – 每天至少執行每個測試一次。
p.97
When you get a bug report, start by writing a unit test that exposes the bug.
每檔你接獲臭蟲提報，請先撰寫一個單元測試來揭發這隻臭蟲。
p.98
It is better to write and run incomplete tests than not to run complete tests.
編寫未臻完善的測試並實際執行，好過對完美測試的無盡等待。
p.99
Think of the boundary conditions under which things might go wrong and concentrate your tests there.
考慮可能出錯的邊界條件，把測試火力集中在那兒。
p.100
Don’t forget to test the exceptions are raised when things are expected to go wrong.
當事情被大家認為應該會出錯時，別忘了檢查彼時是否有異常被如期拋出。
p.101
Don’t let the fear that testing can’t catch all bugs stop you from writing the tests that will catch most bugs.
不要因為「測試無法捕捉所有臭蟲」，就不撰寫測試碼，因為測試的確可以捕捉到大多數臭蟲。

我個人是對p.88這一條有些意見。但事後想想，他的意思應該是讓程式自我解釋，不過這有很大的難度。相反的，在一些教科書或實作上，我們希望註解是越清楚越好。