敏捷軟體開發 原則, 樣式, 及實務

因為讀碩士關係很久沒好好咬一本磚頭書了（教科書跟論文不算的話...）
好不容易這幾天看完，乘著記憶猶新打一下筆記

先說說整體感想，
這是個可以看到很多思考過程的書，而不是條列式列一推優缺點的，也沒甚麼亂憑空喊話。
隨處可見用直接用程式碼跟UML思考（不是輔助用喔！），對我這程式黑手而言好多了。
翻譯也是上上之作，基本上直接靠敘述用中文思考就ok。

內容

• 1,2章：不免俗的還是宣揚一下門派心法及教義。
• 3,4,5章：敏捷開發中耳熟能詳開發方式， Plan, Test, Refactor。
• 6章：兩個人共同寫一個保齡球計分，藉由互相討論慢慢組合出一個程式來，而不是一個人悶著頭寫，可以看得出來Plan, Test, Refactor是慢慢延生出來。說實話，這種互動對我而言是一個很妙的體驗，而且居然能產生出個還挺精美的程式，跟中間思考過程比起，我想對於搭擋編程的認識或許是更重要。
• 7章：嗅出程式那裏會壞掉。
• 8. SRP： 類別改變的原因只有一個。
• 9. OCP： 可對外擴充並對內部修改封閉，但要決定封閉跟擴充那些東西是很困難的，這要來自抽象化慨念本身的合理性，抗拒草率的抽象畫跟抽象化本身一樣重要。
• 10. Liskov代換：子類別必須可以替換他們的父類別。
• 11. DIP：高階與低階應依賴於同一抽象概念，實做細節要依賴抽象。
• 12. ISP：介面必須切割成它應該做的事，也就是內聚力。
• 13~17章：薪資系統，主要有一些簡化靜態結構的Patterns，像Command, Singleton, NullObject之類的。
• 17~19章：思考如何修改或擴充系統，也是前面的幾個Pattern的真正延伸，我覺得這邊也很棒，而不像有些書只說Pattern好，也不知道好在哪...orz。
• 20~22章：用測量方式量化依賴度跟穩定度，過程大略還懂，不過真的要自己做就沒法度了。
• 23~27章：氣象台研究，複雜的互動，處理不同版本差異，外部Library處理的Patterns應用。
• 28~30章：教育訓練系統，只看懂用Vistor做報表...囧。

總結

• 個人及互動勝過流程與工具
• 可用的軟體勝過詳盡的文件

良好溝通做出來的可用軟體才是好軟體。

JavaTwo參加感想

平常在學校老是裝Java之神招搖撞騙
難得這次JavaTwo有機會再吸收點日月精華
於是早早就報了名，以利日後妖言惑眾

我不太會認路，於是早了幾分鐘出門
一上捷運，就鎖定一個休閒背包裝筆電的宅男
果然跟著跟著就到了台北國際會議中心

一進場，廣告就強力放送
「Java can do everything ....」
「Java is everywhere, in your computer~~~ in your cellphone~~~ ....」
All right, All right, i got it.

梅老師比我早到許久
我挑老師旁邊的位置坐下，寒喧幾句殺殺時間

不消一會兒，開場時間就到了
當然不可免俗的必須來個總經理跟教育長的Opening
類似歡迎各位大金主駕到云云
好了快下台啦，我知道您老比咱家校長還會講

首先第一個就是重頭戲
Thinking in Java作者 Bruce Eckel 的演講
然後這外國大叔居然給我滑雪摔斷了左腿，在家裝死
昇陽!退錢阿!!?以為我為何乖乖的掏出1200NTD!?
開玩笑的，其實我來之前就知道了，不過還是感覺很可惜的
取而代之是介紹Dynamic Language on the JVM(JPython)一段影片(附中文字幕)，

前半段是在介紹
Dynamic Language (動態語言，如Javascript,Python) 的好處
跟一般強型別語言(Java, C#)的差異，
以及他對學習 Language的一些看法
（又看到Martin Fowler的名字了，最近好像一直看到？）

後半段再講
Python 跟 Java 不同的語法比較
{}區塊跟用縮排
變數宣告跟回傳
物件的建構方式，等等

對我而言，聽起來滿有意思的
之前都是自己亂摸亂玩而已，跟本沒在比較兩個語言的差異
被這樣一比較，興奮感突然又冒上來
做一半的SpringPetStore Python移植版，又想再拿出來玩玩

「這根本是來介紹Python的」老師?道
「阿！？喔喔？真的ㄝ」
被騙了．．．突然才想起這裡是"Java" TWO，怎麼會變成Python
瘸腳大叔難怪不敢來 ，大概是怕被蓋布袋？

話再講回來，
可以看出Bruce Eckel 真的對Programming Language很有熱忱，
或許該用狂熱形容
而且鑽研的非常深入，不能見到本人心中又多了點惆悵

第二場是
FreeSoftware與OpenSource的Licence，
我沒何興趣，
主要是講一些自由軟體授權上的分別，
什麼BSD,GNU,copyleft,Business Model?
喔～這隨便啦，等我發達了再來煩惱這個

結果整個上午就結束了，廣告都亂演, Where is Java ?
～～～午餐還不錯吃

ok, Java did come in the afternoon
三個時段各有三個不同主題的場次，我當然都挑A
因為我喜歡後端資無趣資料庫，
另一邊的那種就交給有藝術天份的天才煩惱吧

1.EJB3的理想與現實
我來這的主要目的之二，真的是來對了

首先EJB的歷史
EJB1. 先進的思考，小巧玲瓏，功能很少
EJB2. 技術的進步，變的功能龐大，也變的更難用沒彈性
最後被Hibernate+Spring聯手幹掉
EJB3. 打不過它們，就加入它們，３以後變成只有規格跟一些介面
實作就交給Hibernate & Spring (還有他們的對手)

簡介一下EJB3架構跟SimpleCode，這裡不多寫

後半談主講人使用過的感想（理想與現實比較好聽），
全部都在講JPA(Java Persistence Application)，好幾個想法跟我之前使用時感覺一樣
Annotation設定果然比XML設定好用
EntryManager陽春陽春
EJB3萬歲，EJB2死死去

還有些我沒用過，沒啥感覺，
不過大哥是對的！聽他的就是

最後是各家ORM的實作品比較
不愧是業界高手，還能分析比較，
我只用過Hibernate，而且都只是基本語法

不過我下個專案打算追隨大哥 ，用看看EclipseLink(不過這好像是Oracle的....)

2.在雲端上喝咖啡(Hadoop)

介紹Cloud computing，
相信大家都很熟的，不熟的自己點共筆找！

介紹MapReduce
一樣自己點共筆找吧，都在深網技術(Deep Web下面)

聽著聽著，我快睡死了
但是左邊的男同學居然還能抄筆記
還有右邊的女同學，妳聽得津津有味就算了，
不用狂點頭表示贊同啦，我會心虛的

強忍睡意，終於到了DEMO時刻
Hadoop雖然是JavaCode ，但是還是很複雜，
用了大概八九個Class才搞定吧
這時候怎麼不來個Class Diagram or Sequence Diagram?
而且我也還不太了解要怎麼真正做到分散式的運算

這種東西果然是要自己摸才會...orz

3.lwdba-開放原始碼的輕量級資料庫存取程式庫

lwdba ，一個Relational Database的程式庫
簡單講，功能比ＪＤＢＣ強大，但是比Hibernates(JPA)弱小
當然學習門檻低跟環境設定複雜度會更簡化
專案主持人兼主講人同時也是Thinking in Java的中文譯者：王建興先生

整場都在講lwdba的使用方法

雖然沒用過，但是我感到很親切．．
因為我也做過類似封裝ＪＤＢＣ的事，如同往事歷歷在目
建議同學有機會可以用用，尤其沒經驗又要寫資料庫應用的，
會比直接用JDBC少非常多麻煩，
我應該也會用看看

最後的最後，總經理跟教育長的老梗Ending
抽獎時間，老師那張差一號中iphone，殘念

總結，
原本是打算做的看熱鬧的鄉民，不過意外的收穫頗多，
實體戰利品: Duke一隻，Sun牌T-Shirt一件，背包一個，筆記本與筆少許，補習班宣傳單無數
技術面的話聽到Python與Java比較，EJB3高手用後感，lwdba 原設計者的建議跟想法

當然有下次我還會去，我跟某外國B大叔不一樣，打斷腿我也去

寫給大家的平面設計書

平面設計，一項平凡又艱深的課題

隨手翻幾頁後個感想
嗯，好極了
顯然看起來大家是包含了我，


內容：

書前半是用四項原則

• 相近 Proximity
• 對齊 Alignment
• 重覆 Repetition
• 對比 Contrast

並舉出實例來展現，

後半段則是講各種字型及大小造成視覺上的差異


心得：

貫通本書，大概感覺是
掌握設計基本原則
然後大膽實驗，用心體會

再來就是多做多看
聽起來跟台上老師的廢話一樣XD...

不過我還是有感受到一些設計原則

1. 留白：眼睛是需要休息的，連續讀字也是很累的
2. 邊線：所有的圖文字，都需要一條看不到的隱形線支撐
3. 對比：要一眼就看出有差異(例如12px的字對上24px的字)
4. 字型：原來字型還有自己所屬的Family

總結：

原來平面設計這麼博大精深，我還是回去寫程式好了 ...Q口Q

FFXI

FFXI(Final Fantasy 11)
http://www.playonline.com/ff11us/index.shtml

一個我玩了6年的網路遊戲
總遊戲時數快破萬了，也經歷過大大小小事
可是居然沒替它寫過任何文章，真是詭異

不過沒關係，從現在開始好了
先貼幾張近況照片




萬事起頭難，先這樣就好

輕快好Java(Better,Faster,Lighter Java)

最近在玩RoR 10分鐘架站
突然想到一個問題，

「如果不靠框架和IDE，寫一個有購物車的網站要會多少東西？」
嗯..Web API, HTML , SQL (Java就不用說了)

「如果不靠框架和IDE，寫一個結構良好有購物車的網站要會多少東西？」
OOP? Hibernate + Spring + Structs ?

「如果不靠框架和IDE，寫一個結構良好且有分析文件的有購物車的網站要會多少東西？」

OOAD? UML? JUDE? Word + Excel (文書處理也很重要阿)

「如果不靠框架和IDE，寫一個結構良好且有分析文件且美觀的有購物車的網站要會多少東西？」

CSS ? Dreamweaver ? Photoshop ? 照相技術?

「如果...」

好吧..真是夠了
於是又把這本書挖出來懷念一下

心得：

全書就只有五個宗旨

1. 保持簡單
2. 一次做好一件事
   
3. 力求通透
4. 開放擴充
   
5. 吃什麼像什麼

是阿，我老母也懂阿，這不是看起來跟廢話一樣
可是有寫過複雜一點程式(約一萬行上下)的人就知道
每一樣都好難

說實話，這種講玄學的書，我還不夠格寫心得
不過我可以提出一個我的經驗

有天，我接到個需求，一個別人的ASP程式需要call我的Java程式，
嗯，這是個不同語言溝通的問題
答案很簡單，顯然是WebService，
是阿，但是重點是我用的是UltraEdit，如何在純文字模式下建立WebService
SOAP,xml,WSDL,UDDI,AXIS...立即排山倒海而來
　
　奮鬥了一個下午之後，我真的受不了了
　「有人知道如何不用工具直接建WebService嗎？」
「．．．」（辦公室安靜無聲）

　「有人知道如何不用工具直接建WebService嗎？」
「＃※＃※＃※＃※」（JavaWorld又好多火星文了）

　當下我只覺得用FTP傳txt才是好主意
「這怪東西實在太複雜拉...囧」

總結：

我很喜歡這本書，
就同序所寫，這本是寫給「受挫的人看的」(沒錯，就是我！)
內容不一定每人都同意，不過我相信能不同意的一定是天才

每看一次心中就無比暢快，總算有人出來發聲了

昨天,今天,明天

小時候，我媽是個銀行會計襄理
工作的銀行後門就有個幼稚園
平時就把我寄放在那，下班後就一起回家

因為古時電腦不發達，銀行少，業務相對多
傳票支票現金疊的滿滿跟山一樣，常常都要忙到六點多才能回家，
所有人都一樣

每天放學到下班中間
一個小鬼在銀行裡面活蹦亂跳

「媽咪~~偶功課寫完了 -w-//」
「乖～拿這邊的白紙去畫畫，不要吵摟」
於是我拿了一堆印壞報表紙畫無敵鐵金剛

「媽咪~~偶肚子餓了 >o< ... 」
「乖～這裡有１０塊先去買麵包吃，不要吵摟」
於是我買了四個小餐包，吃的渣掉滿地

「媽咪~~好無聊想回家睡覺了 zzz ... 」
「乖～先去後面趴著回家在叫你，不要吵摟」
於是不知誰的辦公桌被我沾滿口水

沒錯，是每天


連帶童年也分非常的銀行文化

那時不過六歲，我知道傳票跟支票的差別(因為叔叔都叫我幫忙拿)
那時不過六歲，我知道什麼叫會計年度(因為那天都好晚才能回家)
那時不過六歲，我知道開關金庫的方法(因為關好門才能回家)
那時不過六歲，我知道哪些數字容易混淆，比方說:17,06 (因為阿姨都叫我幫忙抓)
那時不過六歲，我知道會計襄理的章要蓋在支票的哪格(因為我媽蓋不完叫我幫忙蓋)

幼小的記憶真是好蠢，是吧
但我相信不只我一個


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


歲月不饒人，今天，銀行滿街而立，科技進步，網路發達，
每個行員加班都是推業務，
誰還對帳？誰還對傳票？誰還戴眼鏡仔細看17跟06？

我以為不會有這種故事了，那只是個時代的悲劇

直到我看到ＸＸ軟體公司的一個精美桌上月曆，
每個月份都有一幅員工子女畫的圖，還有寫給父母的話

爸爸都很晚回家／媽媽在家還工作／一星期見不到幾次面／假日都沒辦法帶我出去玩
1-12月都差不多內容

我驚覺，故事不過換個地點罷了
而且內容更加驚心動魄，
只慶幸，演員數目少了一點點


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


最近有個在軟體公司上班的朋友離職了，
每天工作超過１４小時，程式一改再改，CMMI也只是助纣為虐
舊的人一直跑，新人一直補，整間公司不知道再幹麻．．．

罄竹難書

跟他聊天的時候又回憶到此事，
我把故事說給他聽，再一直感謝他的英勇奮鬥
「時代考驗青年，青年創造時代」這種都出來了

「放屁！」他只回我兩個字


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


很多人跟我說，寫程式的宿命就是這樣，加不完的班，改不完的Code
(如果還加上補不完的文件...)

如果有時光機回到２０年前，你跟我講會計年度結帳那天能準時回家
六歲的我會笑你不懂

所以我不相信宿命之類的，既然電腦能改變別人人生，為何不能改變我們自己的？

看看每個新技術背後，不都是想多擺脫一些這種"宿命"？
看看每個方法論背後，不都是想多解脫一些這種"包袱"？
[Mythical Man-Month][Peopleware]兩本書加起來都50年了

沒有銀彈，還是要尋找，最少我們有好幾顆銅彈了

或許有天我發覺我自己也是被宿命玩弄，
也許有一天我會很累想放棄，
但是不在此時，不在此地

人月神話

這是一本軟體專案開發的書
而且是40年前的
嗯？40年前？那時候我都沒出生勒，
而且我懷疑那時候的字典根本沒有「Computer」這個單字！

站在書店翻著這書心中還一直唸「這我早知了」
但是不爭氣還是買了

心得概要：

其實都是一些很古老的"老梗"
一直到今天 ,該死人類還是玩不出新把戲

1. 程式設計有苦也有樂，樂趣在能輕鬆創造，就跟魔法一樣；苦在必須事事完美，最常出現的bug總是很蠢 ,etc:大小寫,正負號,if先後順序
2. 人月是個神話：人多並不會贏，因為寫程式工作大都是連續且不可分割 ，十幾個人一起做再加上溝通的時間，搞不好比兩三個人做慢
3. 系統需要整體概念，這個讓一個人決定就好
4. 為何進度會落後這麼多，因為每天落後一點點；所以定mileStone的時候要夠明確，明確到自己騙不了自己
5. 文件的寫法？該寫那些？總是配合人類需要，而不是電腦需要：直覺，經濟，人性
6. 越成功的系統，開發者與客戶間的互動越頻繁
7. 沒有銀彈：其實拿來打電腦那一個現在不錯了(雖然java裡面那些api，還是多的跟怪物一樣，一堆還要套Design Pattern，看懂Design Pattern也要花不少時間，不過總比跟記憶體跟CPU排程搏命好)，可是打人類的那把卻越來越噁心(一堆怪方法論，怪工具，怪技術都出來了)
   
8. 軟體工程這條路還很漫長XD

總結：

其實書的內容比我寫的還多很多，像是跟預估跟第二系統之類的，有些則是我太年輕沒辦法體會(OS/360??組語寫薪資系統???)，但每每看到某個片段，就好像看到人生以前的走馬燈，歷歷在目，又好像能預測接下來的歲月，如猶在耳，只能說這條路還很漫長，但我相信走下去一定有終點，一定有！