遺留系統重建實戰

最近終於把《遺留系統重建實戰》看完了,有一種被深深震憾的感覺;你知道在看一本書時,能深刻地把自己的經驗投射在字裡行間是多爽的一件事嗎?每看一段文字,就好像在講自己的故事,那種「作者你為什麼這麼懂!?」的感覺真的會讓人感動得掉淚!‬如果說《鳳凰專案》是講組識變革和工作方法,那這本《遺留系統重建實戰》就是講專案重構與重建的方法與過程。

雖然它出版的時間只有兩年多 (這裡是指原文書) ,但在我心中它已經是經典了!以下我簡單做個導讀。

第一章很生動地描寫出了舊有軟體專案的特徵與樣貌,還有它為什麼會變成這樣,以及我們在維護時的心境。你會發現作者在字裡行間的描述都很貼近我們所面對的真實狀況,不得不說作者這一路走來也是很苦呀。

第二章講的是你為什麼會對這些舊專案有負面的觀感,所以在重構之前我們要先深入瞭解專案以找到這些痛點。透過一些工具的輔助,我們可以將這些痛點數據化與可視化,以便把重構的時間花在有價值的地方。

第三章要開始準備重構了,這邊講的重點是決定該重構還是重寫,要讓整個團隊瞭解整個計劃有哪些風險,並得到上頭的批准。我自己也有這方面的經驗分享,請參考:《面對 Legacy Code ,該重構還是重寫?》

第四章進入重構程式碼的階段,強調在重構程式碼時要注意的事情,還有如何透過工具和方法來協助重構。本章也用一些例子來說明該被重構的程式碼特徵,以及該怎麼補上自動化測試。作者也推薦《修改代碼的藝術》這本書 (中譯本已絕版) ,我前陣子也剛看完

第五章講的是重搭整個專案架構,畢竟有時只重構程式碼可能無法讓維護難度減低。本章講到怎麼把一大塊的單體架構分解成較小的模組,然後介紹幾個常見的專案系統架構,並分析了它們的優缺點。

第六章就是講舊專案沒救了要重寫,前提是你已經試過各種藥方要幫它重構。本章介紹了該針對哪些地方重寫的分析,瞭解舊有程式裡有實作哪些規格、避開什麼問題,以及各種新舊資料庫的轉移方法。

接下來的章節開始進入 DevOps 的部份。

第七章介紹了怎麼讓開發環境的建置自動化,目標是讓新人在接手專案時,可以快速地進入狀況,而不必花費心力在建立開發環境上;重點是專案的說明文件,以及如何使用自動化工具來快速建立開發環境,並且在本機就可以獨立運作。

第八章講到怎麼把自動化建置延伸到測試環境和線上環境,而且最好是放在雲端服務上以減輕維運負擔。另外就是不要讓各個運行環境有所差異,導致出現在特定環境才會發生的問題。

第九章提到建置、持續整合以及佈署的自動化。儘可能更換掉過時的工具,因為新的建置用的工具鏈通常會更容易使用且易於維護。

第十章也是最後一章,這邊算是前面章節的回顧。儘可能要使用現代化的技術來開發,團隊之間也要互相公開資訊;然後做好持續改善,並將一切自動化。可以的話要讓程式或系統儘可能地小,將它們分解後會更容易維護。

當然上面只是對這本書介紹個大概,但我相信如果你也對舊專案很困擾的話,這個導讀應該能引起你對這本書的興趣。可惜我太晚知道有這本書,所以在重建某個專案時真的是跌跌撞撞;不過也因為有這樣的經驗,才會對這本書的內容特別有感觸。之後有機會的話,我會分享一下我們真實的經驗給大家。