發表文章

目前顯示的是 十二月, 2008的文章

Bug 與 皇上

一夥程式設計師正在啟奏當今皇上。『今年有什麼偉大的成就嗎?』皇上問道。

程式設計師私下討論了一會兒,然後回話:『比起去年,我們今年多修正了50% 的Bug』

皇上滿臉困惑的看著他們。他們顯然並不知道『Bug』是什麼。他低聲與宰相商量一會兒,然後轉向這些程式設計師,面露慍色。『你們犯了品質管制不良之罪。明年起不得在有任何的Bug!』他當庭宣下這道聖旨。

當然啦,明年當這夥程式設計師再度向皇上奏報時,就完全不提 Bug 的事了。

以上是取自 G.M. Weinberg 的著作 Quality Software Management v1: System thinking 的中譯本:軟體管理學-系統化思考 內的一個小故事。Prof. Wenberg 是我個人滿喜歡的一位軟體工程作家,他總是能用淺顯易懂的小故事道破許多軟體工程的問題。把這本好書推薦給大家,有空的話真的可以好好看看。

漫談Agile Modeling

圖片
自從2002年Scott W. Ambler寫了一本叫"Agile Modeling - Effective Practices for eXtremProgramming and the Unified Process"以來,Agile Modeling(AM)的觀念與方法逐漸大行其道,由於AM的觀念可用之於各種物件導向軟體發展方法上,因此希望來輕鬆談談AM這種方法論(methodology),以收拋磚引玉之效,同時也呼應『目』與『F』那篇文章。這篇文章所談的大部分來自Ambler的說法,我只不過摘要式地加以闡述,但仍然可做為軟體工程師創製模式時借鏡。 依照Ambler的定義,AM是一種渾沌、實用為基礎的方法論,其有效地用於模式化與文件化軟體系統,「渾沌」(chaordic)一詞可說道盡AM的精神,依個人的詮釋是「不受限但處理的事物漸趨規則」之意,也就是說,規則來自於渾沌的演進,至於此地所說的方法論(methodology)並非指發展軟體的方法,而是指每天由軟體專家們應用的一些常規(practices),這些常規依照AM原則與真義(value)而定。Ambler依他的經驗,擬定了核心與補充原則共17項,以及共21項的常規,至於AM的真義有4項來自於XP(Bechk 2000),但加上「謙卑」(humility)一項,而形成Ambler所說的AM真義,我想這5項真義值得加以簡單說明,因為所有的原則都源自於這5項真義: 溝通(Communication):發展團隊成員之間以及專案相關人士間的溝通必須有效。簡單(Simplicity):發展符合需要的最簡單的解決方案。反應(Feedback):盡早並且時常獲取對工作的回應。勇氣(Courage):要有嘗試新技術的勇氣,而且成為決策。謙卑(Humility):必須謙卑允許別人提供對於你專案工作的意見。這五項真義以及各項常規與原則是引自於敏捷聯盟(Agile Alliance)的四項敏捷宣言,因篇幅受限,我不便在此地詳述這些17項原則與21項常規,讀者如有興趣可參考Ambler著作Agile Modeling,或網頁:http://www.agilemodeling.com/,不過我希望討論其中最主要與實用的「簡單」這一項真義所在。 Unix的發展者之一P.J.Plauger曾在1974年著作一本叫&quo…