隨手扎
【閱讀筆記】代碼重構的藝術
目前在服義務役當兵，這本有點忘記啥時看完的了，印象中在入營前。總之，利用放假一點時間寫一下筆記。
喔！對了，我也看完「軟體測試的藝術」了。有時間再來寫。
六六三十六，數中有術，術中有數。
陰陽變理，機在其中。
機不可設，設則不中。
– 《三十六計》
推薦指數：★★★☆☆
本書分成三大部份：
- 第一部份：修改機理
- 第二部份：修改代碼的技術
- 第三部份：解依賴的技術
對我而言有幫助的在後兩個部份，但我也還在理解中。一個是個人經驗不足，有些內容沒有那麼深刻的體會。故如果你跟我一樣沒有多少重構經驗，看這本書可能也會像在霧裡看花。但我仍然覺得有些收穫，所以我會給2-3顆星。而如果你已經有一些重構經驗，但重構的有些痛苦，這本書或許會很適合你。
好的技術書籍一般有兩種情況，一種是介紹一些新奇而有趣的技術，另一種是能將現有的技術闡述或概括得通透淋漓。然而， 實際上還有第三種–既非介紹新奇的技術，也非闡述紀有的技術，而是將長期實踐所證明了的大量技術手法囊括在一起。看起來琳瑯滿目五花八門，但又各有各的用武之地。 這樣的書一般較少見，因為需要長期的累積和時間的洗禮。
本書正式這樣一本書。
– p.6 譯者序 節錄
本書重點無疑在於怎麼重構代碼。
遺留代碼修改算法
- 確定改動點
- 找出測試點
- 解依賴
- 編寫測試
- 修改、重構
– p.32
其中我認為找出測試點與解依賴可能會是最為麻煩之處。
幾乎每個嘗試過既有代碼編寫測試的人都會發現既有代碼對測試是多麼的不友好。這並非一種侷限於特定程序或語言的現象，而是幾乎普遍存在的。一般而言編成語言對測試的支持不太好。要想最終得到易於測試的程序似乎只有兩條路：一條路是邊開發邊編寫測試，另一條路則是在先期花點時間試著對一測試性納入整體的設計考量。人們對於第一種方案的期望甚高，不過若是以業界大量代碼為證的話，第二種方法在過去並沒有取得多大的成功。
在一次次試圖將代碼納入測試中去的過程中，我發覺自己逐漸開始用一種相當獨特的方式來思考代碼。……但後來發現這樣一種看待代碼的方式在我遇到新的不熟悉的編成語言時給我了幫助。– p.42
……然而在另一些情況下，之所以去創建一個新類別唯一的原因就是我們想要編寫受測試的新代碼，而目前還沒有時間去將那個現有類別納入測試。……但接下來會發生意見有趣的事情：一段時間後，你對於總是避開就類別龐大的身軀感到厭煩了，於是開始試圖將他納入測試中。而這像工作的一個盛飯就是去熟悉你要納入測試的類別，所幸的是，因為你常常要去查看這個巨大的為測試類別來決定要從什麼地方抽生出新類別來，也變得越來越了解他。因此把他納入測試也就變得越來越不可怕了。此外，這像工作的另一個部份就是要避開厭煩的情緒。你看著屋子的垃圾會感到厭煩，想要將他門掃地出門。
– p.83
雖然我個人重構經驗不多，但是我也算是看過、去理解過不少人寫的程式(朋友之前的互相交流；學習新的程式語言等)。有些方法我已經在用，也確實感覺有幫助。
理解代碼的方式
- 注記/草圖
- 清單標注
- 職責分離
- 理解方法結構
- 方法提取
- 理解你的修改產生的影響
- 草稿式重構
如何知道你的修改不會破壞已有的東西？其實你可以根本無須考慮這些，這很容易做到：從代碼控制系統中輸出代碼，別去管測試編寫的事情，只管提取方法，移動變量，以你喜歡的方式去進行重構吧，但這麼做了之後你 可得記得別再把這些代碼輸入到服務器 上去了，這種作法叫做"草稿式重構”
- 刪除不用的代碼
– 第16章、對代碼的理解不足
其中 注記/草圖 的方式與jserv一次code review直播說到的類似(1:28:00)。
題外話
目前閱讀：
- 編寫可讀代碼的藝術
待讀書籍：
- 重構-改善既有代碼的設計
- 代碼大全