在第一篇和第二篇中，分享了一次Refactoring的經驗。當時覺得最大的考驗是意志力與信念。所以描述(抱怨)問題的困難度，以及心路歷程佔的篇幅最多。現在回頭想來，其實這篇兩篇文章真正分享的實務技巧，似乎可以化約成簡單幾句話:
當程式碼很冗長，變數糾結得很複雜時，可以用extract method來將程式分割成小塊。由於變數的scope過大以及使用不當，extract出來的method將會出現ref以及out的參數。留待後續的refactor動作逐步消除或簡化這些參數。這個方法似乎只適用於C#(或是其他支援ref參數的程式語言)。
誰才是捉得到耗子的好貓？
在Open Source領域中，Java跟PHP兩項技術都非常活躍。不過兩者的方向似乎不一樣。Java感覺上較擅長於MiddleWare與Framework的創新與精進，而PHP則有許多成功的應用軟體。Java有非常優秀的OR Mapping工具如Hibernate，MVC framework如Struts, Webwork，還有Spring、Wicket、iBatis、Sun自己推的EJB等等，真是百花齊放。但是你如果要找Open Source的討論區、Blog、內容管理系統、或是Wiki等應用系統，就是PHP的選擇多而且活躍。像是phpBB, 維基百科的引擎MediaWiki, XOOPS, JOOMLA等。
如果進一步觀察這個現象，又會開始令人覺得耐人尋味。PHP這些活躍的計畫，常常沒有用太複雜先進的架構，往往就是把『組合SQL指令的程式碼』跟『頁面』寫在一起。MediaWiki就自己說他們的程式碼又複雜又髒。但是維基百科用的正是MediaWiki這套軟體呀！想像它的資料量與瀏覽及更新人次。誰說MediaWiki是不好的軟體？而Java有那麼多優雅的架構與工具做基礎，照理說更容易做出好的應用軟體才對。但是這麼多年來，為甚麼應用軟體仍然是PHP的天下？
對軟體服務業而言，這四十年來資訊技術最重要的發明是什麼？
我的答案是『物件導向技術』以及『關聯式資料庫』這兩項。
我一直是物件技術的擁護者。工作上常常宣揚Design Patterns和Analysis Patterns的重要，喜歡把老舊的程式Refactor翻修成物件的架構。做SA時頭腦中的模型都是繼承、多型與patterns。何況Agile Methodology要透過物件技術才能發揮得淋漓盡致。
另一方面，可能是因為純數學背景的關係，我也很喜歡關聯式資料庫。SQL語法基本上就是充滿了集合論的風格（select from多個table就是做Cartesion Product，where條件就是由Axiom Schema of Separation定義集合的property，還有union, intersection等集合運算）。剛進這一行，SQL就用得很順手，因為它應用到求學時接受的純數學訓練。
今年冬天的天氣不是很舒服，很多同事親友都得了重感冒，連號稱不太生病（？）的老婆大人也咳嗽好久了，令人有些擔心。氣象報告說這波寒流更冷，會持續好幾天。天氣冷還能接受，但是每天天色陰陰暗暗，連沒太多煩惱的我也有點消沉懶散。（好像我原本就一直是這樣，不該牽拖天氣。）不過，新春就要到了。想起這首史特勞斯（Johann Strauss II）的春之聲(Frühlingsstimmen)，很好聽的一首歌：
這是1987年的維也納新年音樂會，卡拉揚指揮，花腔女高音Kathleen Battle的演唱。這首歌雖然聆賞起來悅耳輕鬆，聽說其實非常難唱，所以市面上的錄音版本不多。卡拉揚對歌者很嚴格，樂團常不留給聲樂太多呼吸的空間。但是這次演出，Battle以嬌小的體型展現高度的技巧，配合得非常好。
春天就要來了，振作呀，不要被寒冬打敗！希望這首歌能讓大家都記起春天的喜悅。
（古典音樂透過網路，經過壓縮，音質影響都蠻明顯的。這場音樂會，Sony Music有出DVD。這個系列（Herbert von Karajan - His Legacy for Home Video）在台灣賣得很便宜，常有打折，而且畫質音質都不錯。很值得買，我自己買了好幾張，都很滿意。）
從事軟體這個行業，其中一個有趣的地方在於，程式碼要給機器（或compiler）看，也同時要給人看。我發現自己寫程式也是依照這樣的順序。迷糊健忘的我，永遠記不住任何一種語言的語法，常常用的library也記不住用法。幾乎都是靠IDE提醒、靠查閱文件，以及一些試誤的過程，直到讓電腦總算照我的意思走。接下來就要開始refactor，整理架構。把程式整理到看起來好讀又自然，再開發下一個功能。如果不在意程式碼好讀，功能一走通就繼續做下一個工作，過一兩天那支程式可能連自己都看不懂。
至於這次遇到的極品程式碼，為甚麼能發展到這麼複雜？歷代貢獻過的原作者們為甚麼能駕馭這樣的怪物，而我發呆幾天了就是看不懂？應該有什麼關鍵是我沒抓到的。(不肯承認自己特別笨。)
最近遇到一個老舊的.Net系統，一直不斷出問題，而且程式碼複雜到大家都不敢碰。恰巧這陣子在練習refactoring的功力，所以手癢之下，決定拿其中最常惹麻煩的一個功能來翻修。
哇！這隻程式真是可怕。簡直像是經過Obfuscated的程式。正常的coding有可能做出這麼難下手的程式嗎？不知道當時原作者怎麼能想出這麼難懂的程式。只能用極品來形容。真要去追蹤只會頭暈目眩，像是天龍八部的珍瓏棋局一樣，內力不夠的話去盯著它看會不會吐血走火入魔呀！
究竟有多可怕呢？下面舉例講述其中一個字串變數strSysInfo生命週期，一個坎苛多變的命運。
因為我非常懶得上電影院，家中也沒裝第四台，所以看電影機會不多。不過還是慕名地去劇院看了海角七號這部有趣的電影。
我覺得這部電影成功的原因是：
1. 這是台灣少見的，很徹底的寫實主義的電影。很真實，讓大多數人都有共鳴。
2. 選擇了非常討好的題材。一群失意的藝術愛好者，最後在舞台上大獲成功，這個題材總是容易賣座。
導演在這麼拮据的經費和資源下拍攝，但是仍能兼顧票房考量，我個人是很認同的。電影、表演藝術或是音樂工作者都應該要記得觀眾與票房。李安導演也常說，他的目標就是要拍好商業片。
最近跟親友聊到環保的議題，發現很多人根本不知道，現代畜牧業對資源的損耗是很劇烈的。
例如水資源，先不提畜牧所污染的水源，畜牧本身就需耗用大量潔淨的水。只要少買一個速食店的漢堡，省下來的水資源足夠一個人一個半月的洗澡用水。當政府或環保團體呼籲我們節約用水，使用省水龍頭，放裝滿水的寶特瓶在馬桶水箱中，用洗米水洗碗筷與澆花等等措施，真正的最大效果是求得心安。以及能省一點水費。但是即使全民都徹底實踐家庭節水措施，對於整體水資源的節省量還是微乎其微的。比不上每天少吃一口牛肉所能省下來的水。
今天在Martin Fowler的Bliki上的Inversion Of Control那篇看到這段。這點之前我似乎隱隱中了解，不過說不出明確的定義。
Library是讓你呼叫的程式，而Framework會呼叫你寫的程式。或者說使用Framework時，你寫的程式是為了給Framework呼叫。像Servlet寫出來，是要放在Web Container給AP Server呼叫的。我們寫的Servlet有點像是Event程式一樣。
所以JavaMail是Library，而MVC Framework就是名副其實的Framework。Log4J是Library，JUnit是Framework。
發表文章
所有留言
