l

2016年2月1日 星期一

用設計模式打包怪味道與重構方法

Feb. 01 00:06~01:03

螢幕截圖 2016-01-28 14.51.02

 

最近全部的時間都投入在製作「軟體重構入門實作班」的教材上面。前幾天突發奇想:「怪味道(bad smell)是潛在設計問題,而每個怪味道都有一些常用的重構(refactoring)小技巧可以移除它。在Martin Folwer的《Refactoring》書中有20幾個怪味道,70幾個重構方法,初學者不太容易把怪味道和相對應的重構方法記住。如果從怪味道做為出發點,用設計模式(pattern)的格式重新包裝,提供一個比較高階的概念模型,會不會有助於學習?」

隨手拿了Comments(註解)這個怪味道做了小實驗。

***

Pattern:No Comments

Context:寫註解被視為開發人員的傳統美德,有助於理解程式以及後續的修改與維護。如果你的程式有寫註解你老闆會說你好棒棒。但也有一派人士認為如果程式碼需要透過註解來解釋才可以看得懂,那就表示程式寫得還不夠好。而你相信後者的看法。

Problem:如何移除註解?

Forces

  • 註解是寫在程式碼裡面的文件。和所有的文件一樣,維持程式與文件的一致性是一件耗時且繁瑣的工作。
  • 註解可能間接鼓勵開發人員不用寫出簡潔易讀的程式碼。
  • 開什麼玩笑,程式都寫不出來了還叫我寫註解…Orz。

Solutions:盡其所能寫出自我解釋的程式碼。如果別人需要看註解才知道程式的意圖,套用以下重構方法讓你的程式意圖更明確:Extract Method、Rename、Rename Method、Introduct Assertion….(省略細節)

Resulting Context

  • 開發人員有能力寫出不需透過註解也可被理解的程式。
  • 因為沒有註解所以根本避免註解與程式碼不同步的問題。
  • 有些註解是「好註解」(請參考《Clean Code》),不可一竿子打翻「一船code」。消除所有註解可能反而降低可讀性。

***

懂pattern的鄉民看完這個結合Comments怪味道以及相對應重構方法的例子不知道有沒有覺得比較清楚?Teddy挑了一個最容易整理的怪味道來練習,覺得還滿有意思的。這個例子只是一個快速的概念驗證練習,初步驗證完畢之後Teddy又回頭繼續設計「軟體重構入門實作班」教材的程式範例。等教材都做完之後再找時間試試其他怪味道,有興趣的鄉民也可以自己試看看。

***

友藏內心獨白:是一種吃飽太閒的概念嗎XD。

沒有留言:

張貼留言