我的爛Code重構之路

在《軟體構築美學 pdf p.16 》提到軟體開發中鐵三角的概念。

而作者則提出另一個水平的觀點:

軟體開發的天平
天平左邊放的是(預估的)時程和資源,代表我們希望盡量減少的部分。
天平右邊放的是品質和功能,我們希望這部分愈多愈好。
重點在於天平必須隨時保持平衡,如果要增加一項功能,就必須增加適量的時間和資源來維持平衡。
如果經費不足,你就得做出選擇:要犧牲品質還是功能。

時程短、範圍大、資源少

壓時程,趕工作,結果導向,那麼產出的程式碼就必定含有技術債(這是指我),最少有以下二個缺點:

  1. 以「功能分解」分解為主
  2. 未能含有測試

功能分解

功能分解

指以「函數」為主的開發方式,雖然設計成Class,但Class內其實就是把幾千行的程式分類為數十個函數方法,如果以Main(指程式進入點)的角度來看,程式的回應符合我預期會動就好,管你Class內的程式碼怎麼實作。由封裝的角度看來,也是如此,我給你最後的"return 結果"符合呼叫者的預期就好,你管我如何實作。

功能分解的寫法很容易產生副作用,頂多只是把早期Library的做法放入一組有名稱的Class之中。這樣的Class再往下分析,它就是一組端士刀的組合,換句話說就是「職責不單一」了。

夏天到了,想想,你想切西瓜,但你只有端士刀能用是什麼感覺,如果能有個職責單一的切西瓜神器不知道有多好?

切西瓜神器 From: www.best73.com

未能含有測試

記得 91 在 TDD 課程說過:「如果你的程式,測試加不上去,測試很難寫,很難獨立對它進行測試,那代表你production code寫太爛。」一個職責不單一的Class,想要補測試都難。以我上課時的統計(中部地區)來看,天平都不是站在品質的這邊,更不要說寫測試了。

盡早重構 - 還債的第一步

債什麼時候要還,我覺的和上層很大關係。也就是在《軟體構築美學 p.19, p21》裡提到的政治因素,書中有很多說明,真的是字字珠璣的一本書。

債早還晚還都是要還的,只差看你是解 bug 時再還,還是盡早重構來還。

在《軟體構築美學 p.17》中討論「大幅重寫」與「重構」,如果債已深(通常就是留到解 bug 時),大多會偏向感覺希望能大幅重寫的思考方式。

重構

盡早的重構,並將職責畫分出來。

盡早的好處在於,程式的印象還很新,每個函數、作用等都還清楚,畫分也容易些。程式寫久的人都有這樣的經驗,一個月後問你,當初這段程式為什麼這樣寫?最常得到的的第一答案是不知道

重構前後程式碼比較

分析的過程中,因為程式是自己寫的,也清楚整體的架構與變化點。變化點也就是重構的重點。

重構前後類別圖比較

不敢說是債已經還了,最少建立了責任清楚的Class。接下來希望能有時間把測試補上。

工商時間

社群大牛認證

要學測試當然要找有經社群大牛口碑認證的 91 哥開的「自動測試與 TDD 實務開發班」。不知道是哪一位,點過去就有講師介紹了。 :D

1 則留言:

  1. 算晚輩資淺,還有很多先輩不認識,除了91,TED,投影片裏的先輩大名分別是

    回覆刪除

感謝您的留言,如果我的文章你喜歡或對你有幫助,按個「讚」或「分享」它,我會很高興的。