重構(Refactoring)的範例程式碼

最近剛好有機會講Refactoring，用Martin Fowler原書第一章的範例。最早是聽以前的同事老王用這個例子上課，覺得效果很好，兩年前我也用這個例子講過一次。這兩年當中經過更多不同程式碼的洗禮（請參考極品程式碼三部曲1, 2, 3），對這個範例的看法又不一樣。這次講課，我儘可能少說明整個程式的邏輯，也不給聽眾讀懂程式碼的時間，在對全貌了解很有限的前提下，說明如何refactor。隨著翻修的進行，程式碼在做什麼也逐漸明朗。這過程也就順帶說明，refactoring不只是為了整理程式碼，也是讀程式碼(code inspection)的技巧。

閱讀全文>>

極品程式碼--refactoring踢到鐵板（Part 3 後記）

在第一篇和第二篇中，分享了一次Refactoring的經驗。當時覺得最大的考驗是意志力與信念。所以描述(抱怨)問題的困難度，以及心路歷程佔的篇幅最多。現在回頭想來，其實這篇兩篇文章真正分享的實務技巧，似乎可以化約成簡單幾句話:

當程式碼很冗長，變數糾結得很複雜時，可以用extract method來將程式分割成小塊。由於變數的scope過大以及使用不當，extract出來的method將會出現ref以及out的參數。留待後續的refactor動作逐步消除或簡化這些參數。這個方法似乎只適用於C#(或是其他支援ref參數的程式語言)。

有另一點可以分享的經驗，當時也漏寫了。文字比對工具(如Merger, WinMerge)通常用於版本的比對，但是對於Refactoring也是很有幫助的。假想前人用copy-paste複製幾百行的程式碼，

閱讀全文>>

極品程式碼--refactoring踢到鐵板（Part 2）

從事軟體這個行業，其中一個有趣的地方在於，程式碼要給機器（或compiler）看，也同時要給人看。我發現自己寫程式也是依照這樣的順序。迷糊健忘的我，永遠記不住任何一種語言的語法，常常用的library也記不住用法。幾乎都是靠IDE提醒、靠查閱文件，以及一些試誤的過程，直到讓電腦總算照我的意思走。接下來就要開始refactor，整理架構。把程式整理到看起來好讀又自然，再開發下一個功能。如果不在意程式碼好讀，功能一走通就繼續做下一個工作，過一兩天那支程式可能連自己都看不懂。

至於這次遇到的極品程式碼，為甚麼能發展到這麼複雜？歷代貢獻過的原作者們為甚麼能駕馭這樣的怪物，而我發呆幾天了就是看不懂？應該有什麼關鍵是我沒抓到的。(不肯承認自己特別笨。)

閱讀全文>>

極品程式碼--refactoring踢到鐵板（Part 1）

最近遇到一個老舊的.Net系統，一直不斷出問題，而且程式碼複雜到大家都不敢碰。恰巧這陣子在練習refactoring的功力，所以手癢之下，決定拿其中最常惹麻煩的一個功能來翻修。

哇！這隻程式真是可怕。簡直像是經過Obfuscated的程式。正常的coding有可能做出這麼難下手的程式嗎？不知道當時原作者怎麼能想出這麼難懂的程式。只能用極品來形容。真要去追蹤只會頭暈目眩，像是天龍八部的珍瓏棋局一樣，內力不夠的話去盯著它看會不會吐血走火入魔呀！

究竟有多可怕呢？下面舉例講述其中一個字串變數strSysInfo生命週期，一個坎苛多變的命運。

閱讀全文>>

活在現實，擁抱舊有程式碼

軟體開發人員都希望在專案中應用更先進的技術與觀念，使用新的方法、流程與工具。想要開始引進CVS管控原始碼，想用OOAD方法、用jUnit做Test Driven Development等等，想嘗試導入的不勝枚舉。但手上的專案往往不容許我們導入這些︰舊包袱太多，程式架構很亂。既有的程式碼用的是舊技術，新技術放不進去。期待公司下一個專案能夠讓我們重頭好好做。到時候能做個乾淨的架構，不用背舊包袱，而使用新的流程或技術，讓我們真正發揮工作效率。

這個等待其實是不切實際的。一個進步的技術，要試著將它實現在背著舊包袱的現有專案中，並讓它的在這個專案中展現出價值（當然，前提是專案主管允許你這麼做）。為甚麼呢？

閱讀全文>>

將技術債務視覺化

技術債務（Technical Debt）這個詞是Ward Cunningham提出的。當程式設計師為了時效，用一個又快又髒，後續維護成本卻很高的作法解決問題，後續需要多做整理，我們就說他是負債，後續該整理的工作就是"債務"。例如不當地使用copy-paste、做出超複雜沒人懂得的if-else分支，或是該寫註解而沒有寫，都是典型的例子。用"債務"一詞是非常好的比喻，教我們處理技術債務就像處理財務上的債務的方法一樣。

閱讀全文>>