A thing is well designed if it adapts to the people who use it. For code, that means it must adapt by changing.
如果一個東西能夠適應使用它的人，那麼它就是好的設計。對於代碼來說，這意味著它必須通過改變來適應。
基於這個日新月異的時代，人們想要的東西一直在變，有時候連客戶都不知道自己想要的東西到底是什麼。需求的變更也是家常便飯。
加上系統本身也是在不斷地完善壯大，更新的過程也是變更的過程。
從這個角度來看，只要你寫出來的東西，還有人在用。你自己對它還有優化的意願。那麼，代碼註定是需要不停改變的。
所以，改變是代碼的宿命。設計的意義就是為了讓代碼容易被改變。
作者提到說到底那麼更加細節的設計原則，都只是為了實現ETC原則而已。
想想也確實是如此。從最基礎的面向對象來說，封裝可以更方便地更改屬性的訪問權限，更方便更改方法內部的具體實現；繼承可以更方便的「更改」父類的行為；多態可以更方便更改不同的實現……
作者甚至提到，命名規則也同樣有助於實現ETC原則。命名規範有助於更容易讀懂代碼，我們需要先讀懂代碼才能修改代碼。哈哈哈，無法反駁。
作者同時提到，ETC不是一種規則，而是一種價值觀。它是我們在多個選項中做出選擇的依據。
在寫下某段代碼之前不妨想想，這段代碼是讓改變變得更簡單了還是更困難啦？
當然，把作為價值觀的前提是，我們需要知道怎麼判斷哪種寫法更有利於改變。
如果我們暫時也不知道該怎麼判斷的時候。作者給了兩個方法。
1. 試著讓你寫的東西可以被替換。這樣，即便寫的東西不行，到時候全被換掉也是可以的。
根據我本人的愚見，其實我並不是很能理解這一條，我感覺讓寫的東西可以被替換，和讓寫的東西更容易更改，沒什麼區別吧。
2. 在注釋中寫上當時都有哪些選擇，為什麼選了這一個。到時候這個地方需要修改的時候，可以作為一種依據。
這一點和昨天提到的寫文檔的時候要寫上原因是一個道理吧，可見注釋是真的非常重要。
要讓ETC變成一種日常思考的習慣。只有通過刻意練習，才能把它內化。不然看完就忘了，對往後的編碼並沒有多大的裨益。
作者提到了一種方法，給我們的編輯器增加一個配置，在每次保存的時候，都彈出一個提示，「剛剛寫的東西，容易修改嗎？滿足ETC嗎？」。
字數：784
耗時：60分
··················END··················