Anti-Pattern：追求泛用性而不計所造成的overhead代價
（如果您還沒看過這則寓言的前半Part 1，請先看過。）
話說因為悲憫人類的智慧未開展，生活艱辛而精神緊繃，上帝將這原先是天界才有的享受，放到了人間來。就這樣，人類幾乎純由心智活動就能建造事物。
沒有施工技術以及材料的限制，以前只有超級豪宅專屬的設施，或是007電影中的基地才有的設備，現在在一般家庭都見怪不怪了。例如從屋頂到管道間接好幾個反射鏡，將自然陽光引進地下室的游泳池。一個書架可以成為通往書房的隱藏旋轉門。每個房間都可以洗手，每個牆角的都有內嵌隱藏垃圾桶，桶頂還有強力吸塵器，自動將垃圾都吸到垃圾間的大垃圾桶集中。每面地板都埋藏空調用的熱水管，冬天赤腳走在地板上，腳板也能保持溫暖。由於不用材料與營建成本，這些設施如果設計師沒有全都放進來，似乎就太寒酸了。
雖然上帝讓我們不需要施工建造了，但是其他物理限制還是存在。例如管線仍然不能重疊交叉，不同急性的電線相觸會短路。電線的粗細以及水管的管徑仍需要足以符合住戶的用電用水量所需。這麼大量的管線已經夠錯綜複雜，要藏在有限的牆壁與樑柱中，變得極端擁擠。加上設計師間的創意競爭，讓這個情形惡化得越來越嚴重。
人類舖橋造路蓋房子，用太多地球資源，而且造成各種污染，工安事件不斷。更糟糕的是，常常有不良設計，造成無數的心血資源的浪費。而營建的技術不良或偷工減料，也使得即使良好的設計，運轉起來也往往問題百出。人類受夠了，不斷跟上帝祈求：既然上帝賜給人類這麼好的創造力，就不要讓營建那麼困難吧。
慈悲的上帝應許虔誠的祈求，決定讓人類藉由實際的體驗來學習智慧。
上帝更改了宇宙的一些物理法則，並祝福了地球︰
從此地球上一切的設施不用營建，只要設計即自動瞬間建造出來，而且成品定是設計師所期待最好的品質，完美地符合設計。例如Autocad 2120版開始，設計師用它畫一跟樑柱，施工位置自然會出現一根樑柱，不用綁鋼筋灌混凝土，不用打地基。如果調整設計，將那跟樑柱刪除，樑柱也自動憑空消失。不用拆除也不用廢土清運。
一位專業的程式開發人員，每天接觸的技術與技能很多，使用的API、Framework各不相同。做為技術主管該做的叮嚀與規定似乎多如牛毛，不勝枚舉。假設Java有了程式規範，Ajax時代來臨了，是不是Javascript也應該有規範?程式要記錄Log，到底該記多細?可以規定程式碼要加註解，可是有的人只在顯而易見處加註解，洋洋灑灑，只是讓程式版面更亂。有的高手懂得只在關鍵處加上恰到好處的註解，雖然看起來註解很少，但程式碼卻更好讀。另一個問題是Refactoring，重構是好技術，但是實際上執行起來會是破壞多還是建設多？不懂自己怎麼能當那麼多年的技術主管，這麼多問題還是無解，想來真是汗顏。
最近在這個問題上有了新的體會，還沒充分地驗證正不正確，先在此分享：
對於技術人員，第一步該要求的是要能照顧自己。基於為自己考慮(而對其他人無害)的立場做好該做的事。而不用先要求主動對同儕與客戶的立場的考慮太多。假設能照顧好自己就有80分，為團隊著想是90分，為客戶著想是100分。第一個目標就是要求80分，達到80分以前其他的要求，多少有些好高騖遠，不切實際。
在第一篇和第二篇中，分享了一次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就用得很順手，因為它應用到求學時接受的純數學訓練。
從事軟體這個行業，其中一個有趣的地方在於，程式碼要給機器（或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。
大野耐一在他的書中說，會計用語的折舊費、帳面價值，是為了會計與稅法方便而定出來的概念，但大多人忘記它跟設備實際的使用價值沒有一點關聯。混淆了這點，就會有以下的錯誤想法：
Toyota Production System, 簡稱TPS，是豐田發展出來的一套生產方法。雖說是生產方法，這個方法及背後的哲學也可以應用在許多不同行業，也可以視為一套管理的技巧。對軟體同業而言，可以將TPS比喻為「製造業的Extreme Programming」，或是「製造業的Agile Methodology」。不過這麼說在先後順序上不太對。TPS是豐田從二十世紀初起，累積了五十年以上的改善方法，在1950年代就已經大致成型。我個人猜想，Extreme Programming的概念相當程度是受到TPS的啟發；就像傳統的軟體工程，大多是源自西方工業工程的方法改良而來的。
順帶一提，資訊界愛用的Just-in-Time這個詞，就是TPS的術語，豐田喜一郎提出來的。
發表文章
所有留言
