進入軟體相關行業，接手他人的程式碼一起協作是工程師日常。若團隊的程式碼不易修改、或是不容易了解其運作邏輯，那麼就算你現在拼了命的想要逃跑，日後也會花費更多時間和心力來處理。這本書算是集合作者的長期開發經驗和心血，來帶領諸多新鮮人少走點冤枉路。
書籍資料
書籍名稱：管理、修改、重構遺留程式碼的技術
原文名稱：Working Effectively with Legacy Code
作者：Robert C.Martin Series
ISBN：9789864344000
博客來推薦連結：https://tinyurl.com/yce47h82
1. 第一印象的主觀想法
轉職後開始進入正式的開發環境中打滾，面對成千上百行、複雜程度也加倍的程式碼，往往就迷失於其中。若想要快快完成功能，程式碼的品質卻又經不起考驗。到頭來，藉由這本書導正了自己在開發上的心態缺陷。若是求快和逃避改動，最後到頭來要花費的時間可能更多。在評估自己的工作負擔上，測試和反覆調教的時間是要估算進去的。
2. 認同之處和分段筆記
這本書個人認為隨著自身的經驗累積， 會有一些新的觀點產出以及理解原先不明白的地方。因此，下面只記載部分段落。
Chapter 1 – 修改軟體
起因：添加新特性、修正 Bug、改善設計架構、最佳化資源運用(效能提昇)
-
使用者在意的是行為，在添加新行為的時候，儘量不改動他們早已習慣的模式，或是多了 Bug
-
若你對程式碼進行重構 (Refactoring)，要對每一步環節進行測試並驗證其正確性
-
保留既有行為不變，是最具有挑戰的工作
-
問題總是無法避免，所以別等它長大後，才能動手解決
|
添加特性
|
修正 Bug
|
重構
|
最佳化
|
|
|
結構
|
改變
|
改變
|
改變
|
—
|
|
新功能
|
改變
|
—
|
—
|
—
|
|
原有功能
|
—
|
改變
|
—
|
—
|
|
資源使用
|
—
|
—
|
—
|
改變
|
Chapter 2 – 帶著回饋工作
單元測試可以獨力的針對某一段程式碼進行測試，幫助了解問題
依賴性(Dependency)是軟體開發中最為關鍵的問題，遺留程式碼就是要解決過多的依賴性
確定變動、找出測試點、解依賴、編寫測試和重構
Chapter 4 – 接縫模型
為既有程式碼編寫測試，都會發現非常的困難，這是很正常的。
透過 seam 來解除依賴性，這邊的細節直接看書會比較快，畢竟有太多的程式碼範例。
Chapter 13 – 修改時應該怎樣寫測試
特徵測試，描述系統的實際行為 – 先寫一個你知道會出錯的斷言，然後修改到可以通過。用這樣的方式來了解函式的運作。
Chapter 15 – 到處都是 API 呼叫
如果你發現那些 API 多半不是我們能夠控制的話，那就很難去做改善了。當然，你也可以將其依照職責拆分出各個不同的邏輯區塊，並替這些區塊編寫測試、重新命名、外覆類別 (Wrapper Class)等。
Chapter 16 – 對程式碼的理解不足
寫下草圖，力求理解方法結構和職責分離，並刪除不會用到的程式碼
Chapter 22 – 要修改一個巨型方法，卻沒辦法編寫測試
-
進行少部分的提取，並加以語意化，力求達成一個函式僅做一件事
-
將同類的方法放到一塊，並逐條進行測試
-
只提取你所了解的部份，可以從傳入和輸出的變數總和越小的著手
Chapter 23 – 降低修改的風險
程式設計是同一時間只做一件事的藝術，可以用同儕來協助
多一雙眼睛來看總是好的
3. 總結
本篇主要是以 Java 程式碼做示範，對於初學為 JavaScript 的我來說，在理解上會有點困難度。不過藉由書中所提到的不少精采範例，可以讓自己在編寫程式的時候，盡量減少依賴程度和語意化程式碼。
按讚加入粉絲團
