[閱讀] 管理、修改、重構遺留程式碼的技術

章節連結

進入軟體相關行業,接手他人的程式碼一起協作是工程師日常。若團隊的程式碼不易修改、或是不容易了解其運作邏輯,那麼就算你現在拼了命的想要逃跑,日後也會花費更多時間和心力來處理。這本書算是集合作者的長期開發經驗和心血,來帶領諸多新鮮人少走點冤枉路。
working-effectively-with-legacy-code


書籍資料

書籍名稱:管理、修改、重構遺留程式碼的技術
原文名稱: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 的我來說,在理解上會有點困難度。不過藉由書中所提到的不少精采範例,可以讓自己在編寫程式的時候,盡量減少依賴程度和語意化程式碼。
按讚加入粉絲團

延伸閱讀

GA瀏覽人氣:49