休兵小歇擇日再戰江湖

嗨～各位親愛的朋友，最近小弟前往大陸觀光，所以較無暇上網與大家打屁哈啦，同時也深感往日時常在網上流連忘返實非長久之計，決定痛定思痛，暫時戒網。等 回台再跟大家打屁哈啦囉～ ^_^ ，附上二張照片，左邊是我近日寄居的地方-深圳發展銀行，右邊是深圳第一高樓-地王大廈，嘩～有69層樓高328米耶～

Software Fashion

http://www.softwarereality.com/soapbox/softwarefashion.jsp#id27


蠻搞笑的文章，原來軟體也可名列時尚業呀～
談到一些不適當的技術應用，加上誇大的宣傳、過度的銷售
讓人更能體會所謂的追求軟體時尚是怎麼一回事

生活上的例子就像讓胖妞穿比基尼，讓模特兒穿孕婦裝一樣
而在軟體開發上，就如同使用EJB來開發小規模的商用軟體
將XP應用在短期的專案上；利用taglib來加入一些新的meta-language
最後發覺除了製造混亂外，似乎對開發毫無益處
或是當團隊中的那個人閱讀了GOF後，
就瘋狂的想要把所有可能的pattern塞進設計裡

文中還有一個爆笑的面試對談
面試官：呃～請問你最愛的Design Pattern是那一個呀?
求職者：喔～我愛死Decorator，啥米地方我都想來一下Decorator耶～
(我哩～果然是有怎麼樣的考官就會有怎麼樣的答案)

而當宣傳超過人們能客觀地評估技術的時侯，就是開始發生技術誤用的時刻
就像許多時侯人們選用XML的原因，就是因為它是XML XD
這段調侃XML的部份，讓我想到最近電視常在打的廣告
命運騎寵系統狂飆上市的那隻豬，哈～我哩我還飆豬哩

順便還虧了Sams的Teach Yourself xxx in 21 days系列一把
講這些出版商唯恐天下不亂
還會趕緊出本Teach Your Micro-Horse to Sing in 21 Days!

不過當我們選用某項新技術時，到底是因為它正好適合我們的開發需求
或著只是想到這項新技術寫在履歷表上看起來還蠻不錯的?
啥…你問我是怎麼想的，呃～我只能學呂副總統回答你"嘿嘿嘿"

在Popularity vs. Platform Size那段的最後
提到IT廠商不會再咬第二口蘋果也真是神來之筆
apple fans抱歉了:)

接著就是大戰的開始
提到了三項作者認為有遭到誤用的時尚技術
1. VB.Net
2. Struts
3. XP

講到Struts時一開頭還特別挑戰了Struts的使用者
希望他們儘量放馬過來，講講為啥要用Struts
這裡的用詞有點誇張，講的似乎Struts一無是處
還要透過xml的設定用迂迴的方式增加不必要的層級
啥米用了Struts簡直是花了二倍的功夫
簡單的web ap會變複雜，複雜的web ap卻還是沒簡化到哪裡去

這裡似乎又講到一個職場的現實
這年頭出來找頭路，許多面試官也受到時尚技術的影響
於是乎想寫個web ap(java solution)，似乎無可避免的還得要會Struts
不過最後的結論我蠻同意的
不管是啥米東東啦…XML現在似乎是用的太泛濫了些

對XP的評論更毒
講的是好像XP將開發速度定下了個20哩的速限
超過速限的就要抓起來
因為開發者不愛互相溝通，就來個pair programming
因為開發者不愛跟客戶溝通，就讓客戶加入開發小組中
因為開發者不愛測試，所以寫code前要先寫測試…etc

好了，可想而知在該文後面還有一大團，以上各技術愛好著的反擊
大家有興趣的可以慢慢欣賞
諸如像VB.NET是C#的窮親戚，
或是VB.NET不過就是C#之上的語法糖果之類的爭論

雖然我想作者是故意寫給人家批的
不過所點出的現象很值得大家思考

難道選用熱門的時尚技術
是因為，嘿～大家都在用，呀那個國外大廠也嘛在用，還有大師的加持哩
喔～拜託一下，有沒有就是在我們週遭的成功案例呀

老是在講彈性、彈性
切割了許多層來達到所謂的低耦合
到底實不實際

台灣真正的軟體公司到底有幾家呢?
在講究快速開發(結案收錢)的情況下，
設計出那麼多的可擴充性又如何?
我們真的需要那麼多彈性嗎?

覺得國外的成功案例是有時空背景因素在，
而過了水到了台灣後，或許我們又得因應這樣的環境來調整開發的方式。

各位大俠，饒了Java板吧～

流傳在BBS Java版上已久
傳統的年度大戲Copy By XXXXX
再度熱烈上映中．．．

故事的開端總是這樣的
一位盲劍客路見不平拔刀相助
但卻是誤斬好人

好心的僧人心生憐惜
想要為亡者超渡
盲劍客卻連僧人也不放過

公說公有理、婆說你沒道理
老天爺…為啥米躺在哪兒的FAQ都沒有人要理呀

在心中建模型

在【別鬧了，費曼先生】一書中
有一個章節始終讓我百看不厭的就是
『跟數學家抬槓』那段

我很佩服費曼在心中建模型那招
也一直覺得這是個很好的學習方法
不過這方法難就難在如何在心中建立模型

透過不斷的練習
最近我似乎慢慢抓到一點訣竅來哩

其實這道理講起來好像也挺簡單的
不過就是看到新的觀念時
要多思考一下，試著找找看有沒有啥米不對勁的地方
然後再試著用自已的話講出來
這也就是在自已心中建立模型了

直到這一步
才能算是真正將所吸收的東東融會貫通了起來

讀Refactoring一書有感

其實很早就拿到這本書原文電子檔
不過語言上的隔閤卻讓我對這道美食始終難以下嚥
總是翻個二、三頁就去見周公去了
時日一久竟也忘了這本書的存在
真是要感謝侯老師及熊節先生的無償提供前1-6章的中文譯本
火熱下載點：http://www.jjhou.com/jjtbooks-refactoring.htm

首先強烈建議先閱讀本書第一章
因為實在是寫得太黯然、太銷魂啦
我真怕以後看不到這樣的好書該怎麼辦
此章透過一個逐步重構的實例來點出重構技巧的神奇
讓一隻堅硬如石的程式慢慢軟化
相信就算您是個修道多年
信仰忠貞以設計為先的道徒
看完這章大概也會馬上拋開所有禮教
還俗投入重構的美麗新世界中

好吧…我承認這樣講是有點誇張，
但是不誇大哪會有噱頭引您往下看哩

其實重構的步驟也不用想得很複雜
重構的目的並不是為程式增加新功能
只是為了提高程式的可讀性及重用性
重構有時只是改變一下程式碼的位置或取個更有意義的變數名稱，
再將其放置在適當的位置
例如像當A類別內某個函式的頻繁的操作B類別的屬性
或許這就是一個暗示，暗示我們應該讓這函式回歸至B類別處
讓資料和引用這些資料的操作總是在同一個類別之中發生

而Design Pattern則是為Refactoring建立了一個依循的方向
所以當我們透過良好的設計範式來切割類別間的關係時
有些類別間比較複雜的函式根本不會知道外面的世界已經變天哩

再來什麼時候你需要重構哩
例如當你發覺程式寫好一週後，再回去看它時
突然懷疑一週前你是不是有被火星人附身時
你肯定需要重構一下你的程式

另外在書中也提到
我們可依循三次法則
事不過三、三則重構

而若是對於已發佈介面published interface進行重構
則我們可以保留舊介面，用其呼叫新介面
但千萬不要再犯copy-paste的錯誤
並可透過deprecated來標記舊介面
提醒及避免其他人再繼續呼叫這個介面

有時為了撰寫上的方便
我們會讓暫存變數被賦與二次以上的值
像類似這種一時的便宜行事，卻會造成事後對程式的意圖造成理解上的困難
於是像這樣的地方，我們也應該透過重構的技巧來重整它
書中常見的手法就是將拆解成多個足以自我說明其意義的變數
然後我們可將新的暫存變數宣告成final，
便可透過compiler來檢驗是否仍有重覆賦值的缺失

而對於Java為何選擇pass by value而非pass by reference有疑問的人
可以看一下Remove Assignments to Parameters這個重構手法
其實重點就在於強化程式的清晰度及減少非預期的邊際效應

相信你一定有這種經驗
看到一個超肥的大型函式…讓人一時之間慌了手腳不知從何剖析它
這時我們可運用必殺技Replace Method with Method Object
將此大型函式獨立宣告成一個物件
如此一來函式內的變數就成了該物件的欄位
然後我們就可任意肢解這個大型函式，而不必傳遞任何參數
使其各自成為精巧且更具可讀性的小型函式

另外書中有段話雖然跟重構無關，但我覺得實在是講得太好了
也順便節錄一下
"懶惰是程式員的美德
所以能立即查閱的東西
千萬別記在腦子裡
免得把腦袋塞爆"

而書中有些教條式的守則
我想就算一時間不能體會
背起來也是無妨
例如：見到黑影就開槍
喔～不對、不對....
是看到switch就想到polymorphism
或是
當你感覺需要撰寫註解前請先嘗試重構，試著讓所有註釋都變得多餘
(設計良好的程式本身就應具有解譯自身意圖的能力)

在第四章提到了撰寫自我測試程式的重要性
測試是重構的前提
而一般慣用的手法都是寫test main()
不過缺點就在於難以執行多種測試
所以在此章裡介紹了如何透過JUnit來執行測試

總的瀏覽本書前一至六章一遍後
我想起我的前小組長也十分愛玩重構的遊戲
每每看到我寫得亂七八糟的垃圾一到他手裡就被重構的井然有序
內心深處總是覺得十分的佩服…
曾幾何時我幾乎認為那是我達不到的彼岸

因為覺得自已即不是記憶力超強的陳俊生
也不是火星來的假面怪客
能在腦中憑空勾勒出理想中的設計模型

不過現在若是能一步步透過書中所介紹的重構技巧…
或許能使得平凡如我，也能有機會一窺外星人的境界

也記得有陣子我看到OO就很煩
總感到造成追縱程式流程的困難，就是在不斷的delegation之後
看了本書中p.61間接層及重構後
仔細想想才體會到原來間接層所帶來的利益為何

慢慢發覺我的壞習慣是太愛追根究底
實際上好的切割及命名法則，可使我們更能憑著直覺，
來理解程式的執行

而一如GOF的Design Pattern般的鉅作
本書照慣例創造了許多術語
不過感覺上各項重構的命名是容易會意的多，若是為了溝通方便
其實倒是蠻容易記憶的
請想像一下以下的討論場景

強者H：嘿…我覺得這裡該嘗試用Extract Method來重構
小呆P：嘩～醬子這個Method得傳入一狗票參數耶
強者H：呀不然這邊再搞個Preserve Whole Object
小呆P：鳴鳴鳴…Object之間的界定還是很難搞定呀
強者H：好吧…那就出必殺技Replace Method with Method Object吧
小呆P：救命!!! 我頭昏了啦 @_@

是不是覺得有了術語的協助，其實更能增進溝通的效率呢?

雖然從現實角度來看一個軟體專案的執行
往往都因deadline緊迫而壓縮整個開發的時程
這個時候去考量重構來讓往後開發或維護更加順利似乎是有點緩不濟急
不過方法在這裡，如何巧妙的應用及選擇合適的時機點切入
相信就要由聰明的您自已來判斷了

最後我想這本書讓我感到最珍貴的
就在於作者Erich Gamma將平時一些難以言傳的重構技巧
作一個有系統的整理及說明
讓想要學習重構技巧的人能感到有所依循
跟隨著大師的腳步前進
相信總是比憑著自已的直覺要來的準確的多

看到這裡，大家有沒有開始覺得手癢起來了呢?
對於你一直看不爽的code，現在就讓我們動手來肢解它們吧!!!

後記：
雖然書中也提到重構不是建構軟體的銀子彈
至多只能算是把銀鉗子
但我還是感到十分的興奮
迫不及待的想把讀後心得分享出來
並且開始對Smalltalk產生了好奇心
有沒人要來澆盆冷水的呀 ：p