XP: eXtreme housekeePing

老婆常問我，我對家裏PC整理得那麼好，掃毒、更新、硬碟整理、檔案分類都做得很完整，可是為甚麼對於家務的處理卻一團亂。

其實照顧好自己的PC只是我們這一行的基本功，軟體開發的整個過程牽涉到的管理與維護才是大學問。最近沒工作在家休息，又搬了新家，剛好是改過自新重新做人的好機會。開始努力整理家務以後，愈來愈同意老婆的評語。工作上採用的Extreme Programming(XP)，的確有許多practices可以應用在家務上。沒理由上班說一套，回家做一套。以下就是幾點心得：

閱讀全文>>

SOS 遏止全球暖化！--濃縮版

之前寫了一篇全球暖化如何抑止的文章，但是一些讀者反應全文太長。這裡將全文濃縮為九點重點，與各位分享。如要查證資料來源，或是進一步了解詳細內容，請看前面完整版的Po文。

1. 如果不立即降低甲烷，全人類可能活不過十年。如果不立即降低二氧化碳，人類可能活不過一百年。
2. 甲烷的溫室效果比二氧化碳強好幾十倍，主要來源是畜牧業造成，隨著新興國家的崛起快速惡化。
3. 甲烷的溫室效果短而快，也就是說降低甲烷可以幾年內抑止全球暖化。降低二氧化碳要幾十年才會有效果。
   
4. 跟全球大氣的二氧化碳含量一樣多的巨量甲烷長年冰封在海底與南北極，現今正因為全球暖化而快速釋出。北極冰帽即將溶解殆盡，如果讓這些甲烷完全釋放到大氣中，會導致嚴重的氣候巨變，造成地球大滅絕。
5. 科學家說為時未晚，只是改變要快。扭轉的方法就是減少肉食或吃全素，以及影響周圍的人減少肉食，也請被影響的人再去影響其他人。吃素同時有高效地減碳與減甲烷的作用。素食者即使開悍馬休旅車也比吃肉的人騎單車要環保。
   
6. 因為我們不只希望人類多存活十年，也希望能永續發展，所以油電車、太陽能、種樹等等減碳活動應同時進行，但是只依靠減碳緩不濟急。吃素是最有效也最快速地為地球降溫的方法。
7. 除了環保以外，素食的好處不勝枚舉。多吃蔬果可以改善皮膚、改善身材、增進健康。同時也過著慈悲有愛心的生活。
8. 親友聚會或是婚喪喜慶，是最容易有大量肉食的場合。您如果能影響一次大家在這樣的場合以素食為主，效果是非常大的。由於情況緊急，即使您自己還不能吃素，不能以身作則，也請全力鼓勵與支持身旁的人吃素。
9. 上年紀的長輩如果吃素可以免去多種慢性病，過快樂健康的晚年。

物件模型的觀念與誤解

前一篇post說明了OOA與OOD兩種物件模型的差別。本篇不再刻意強調兩者區別，而一般性地討論物件塑模的方法。也就是說，要怎麼摸索或"設計"出一個好的物件模型。它可以用在分析與設計。

首先指出幾個常見的誤解：

閱讀全文>>

OOA範例：組織架構的樣式

這裡用Martin Fowler的組織架構樣式為範例，說明OOA的威力。本文中難免有說明不清楚的地方，建議還是閱讀Fowler的原文會有完整的說明以及程式碼範例。

組織架構是各式企業應用軟體常遇到的問題。要用物件模型表達樹狀的組織架構關係，例如一個公司分成幾個處(Division)，每個處底下又分部門(Department)，部門下有成員(Person)。最直覺的模型如下：

模型一：靜態模型

閱讀全文>>

OOA與Analysis Patterns

在軟體業界所謂系統分析(SA)，傳統上指的是需求確認，而系統設計(SD)指的是類似開程式規格。SA通常要設計好頁面與資料庫，SD要開出達成這些頁面功能的程式規格，交由程式設計師來實做。

物件導向的技術引進以後，這個分野卻令人混淆了。首先，什麼是物件導向分析(OOA)？感覺上物件技術是很實作面的技術，如繼承、多型。我們畫Class Diagram、Sequence Diagram，這算是設計的行為吧！那麼，開發過程中的什麼practice是在做OOA呢？很多人以為用use cases表達需求就算是做OOA，很不幸的，use cases是表達需求的一個方法，但是跟物件技術沒有太大關係。（即使use cases是物件技術的族群流行的技巧。）

Martin Fowler寫了一篇專文討論這個問題：Is there such a thing as Object Oriented Analysis?文中說：

... analysis is primarily about understanding the domain, while design is about understanding the software that supports that domain.

閱讀全文>>

軟體亂度（Software Entropy）

前面討論過技術債務，這裡介紹另一個有趣的隱喻(Metaphor)：Software Entropy。這是一個很巧妙的比喻，可惜要學過一些物理才能了解。我們平常喜歡用複雜度（Complexity）來說明程式碼有多亂，用義大利麵來比喻混在一起、亂得不得了的程式。改用entropy這個熱力學字眼，是因為軟體系統的發展過程跟熱力學的定律有些共同之處。entropy這個字中文翻譯為亂度，或是熵。我個人認為在軟體領域翻譯成亂度比較好懂。

熱力學第二定律告訴我們︰一個隔絕的系統，在達到平衡前亂度一直增加，也就是說，如果要降低一個系統的亂度，需要外部消耗能量。這個定律告訴了我們電熱器加熱要用電以外，為甚麼冷氣與電冰箱降溫也一樣需要電。

軟體開發也是一樣。無論怎麼努力預防，程式碼會需要不斷修改的。這個自然演進的過程都是在增加程式碼的亂度。除非我們真的排人力與資源去翻修它，這個亂度不可能自己降。

雖然我們遇到可怕的程式碼，總是會想責怪前人留下這個攤子，責怪客戶亂改變需求，責怪主管沒有好好要求等等。這些因素都可能成立，但是不要忘了這個軟體的定律：開發的過程，亂度只會增加，除非注入額外的能量來降低它。擁抱舊有程式碼的同時，也要了解去改善它本來就是要付出相對的代價。

台語笑話一則

阿土：哇買一間透天A樓仔厝
阿西：恭喜！你真好額。新厝一定真舒適。
阿土：哪有，細間又格漏水。"漏"仔厝。
阿西：............................但是透天來講勿會細間啦。
阿土：阮厝尾頂破一孔真大孔。郎對厝內看A著天頂。所以號做透天啦！
阿西：＠＃＄＃＄％＠％