對於多數的軟體開發，不斷的功能延伸、錯誤修補是很常見的。如果要等到完全的開發完畢才做系統的發佈，恐怕永遠沒有上線的一天。
所以階段性的版本釋出計畫是很重要的。相繼而來的錯誤追蹤管理也很重要。
2012年7月29日 星期日
2011年6月27日 星期一
Q43: 如果你想毀掉一個人的一天，就給他一個程式; 如果你想毀掉一個人的一生，就教他寫程式
If you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime.
2010年9月19日 星期日
Q42 反覆發展法僅適用在你希望能成功的軟體專案
You should use iterative development only on projects that you want to succeed. - Martin Fowler
『反覆與漸增』(iteative and incremental)是大部份近代軟體發展法的核心，如UP，XP，SCRUM等，這是大家都懂，但卻不容易做到的觀念，何謂反覆發展(iterative development)?就是『接受改變』(embrace change)(Beck2000)。我曾翻看去年幾篇部落格文章，諸如"千奇百怪的需求"、"好人難為"、"早點來"等，內容都談到發展者對客戶或老闆的需求改變，心裡十分痛苦，我也曾在相關的意見箱哩，說這種現象並不希奇，問題是你要用何種發展方法來應付這種『自然現象』，Agile methods，MDA，或者遵守一些設計原則，如OCP，DIP ...，或者一些設計樣式(design patterns)！我看都可以， 不過不管用何種方法，就如Martin Fowler所講，『反覆與漸增發展方法』應該是核心所在。
『反覆與漸增』(iteative and incremental)是大部份近代軟體發展法的核心，如UP，XP，SCRUM等，這是大家都懂，但卻不容易做到的觀念，何謂反覆發展(iterative development)?就是『接受改變』(embrace change)(Beck2000)。我曾翻看去年幾篇部落格文章，諸如"千奇百怪的需求"、"好人難為"、"早點來"等，內容都談到發展者對客戶或老闆的需求改變，心裡十分痛苦，我也曾在相關的意見箱哩，說這種現象並不希奇，問題是你要用何種發展方法來應付這種『自然現象』，Agile methods，MDA，或者遵守一些設計原則，如OCP，DIP ...，或者一些設計樣式(design patterns)！我看都可以， 不過不管用何種方法，就如Martin Fowler所講，『反覆與漸增發展方法』應該是核心所在。
2010年2月5日 星期五
Q41: 好的軟體設計者必須考慮軟體如何成長與改變，以及何種因素最可能成為改變的焦點。
A good (software) designer will consider how software will grow and change and what elements are most likely to be focal points for change. - Rebecca Wirfs-Brock and Alan McKean (2003)
我曾經在本部落格提到過軟體設計的兩項原則：Open-Closed Principle (OCP)與Dependency Inversion Principle (DIP)，這兩項原則都是教我們如何處理『改變』。不過1996年A. Cockburn 提出一項非常重要的軟體設計原則：Protected Variations (PV)，事實上，PV涵蓋OCP與DIP，但更為廣泛(有機會再來談談PV)。改變有兩種：『改變點』(variation point)，就是存在於現存的系統或需求內，另外一種是『演化點』(evolution point)，也就是將來可能產生的改變，這則諺語主要指後者，我個人認為設計者如果能時時刻刻注意這些設計原則，或可避免產生『好人難為』的窘境(請參考薛念林教授post的『好人難為』一文)。
我曾經在本部落格提到過軟體設計的兩項原則：Open-Closed Principle (OCP)與Dependency Inversion Principle (DIP)，這兩項原則都是教我們如何處理『改變』。不過1996年A. Cockburn 提出一項非常重要的軟體設計原則：Protected Variations (PV)，事實上，PV涵蓋OCP與DIP，但更為廣泛(有機會再來談談PV)。改變有兩種：『改變點』(variation point)，就是存在於現存的系統或需求內，另外一種是『演化點』(evolution point)，也就是將來可能產生的改變，這則諺語主要指後者，我個人認為設計者如果能時時刻刻注意這些設計原則，或可避免產生『好人難為』的窘境(請參考薛念林教授post的『好人難為』一文)。
2010年1月7日 星期四
Q40: 製作電腦程式仍然是人類所曾承擔過最困難的工作之一；要精通程式製作需要才能(諸如分析、溝通...等能力)，創造力，智慧，邏輯，創建與使用抽象，以及經驗 ─ 即使有最好的工具。
Programming a computer is still one of the most difficult tasks ever undertaken by humankind; becoming proficient in programming requires talent, creativity, intelligence, logic, the ability to build and use abstractions, and experience - even when the best tools are available. - Timothy Budd (Introduction to Object-Oriented Programming, 1991, pp.2)
2009年12月12日 星期六
Q39: Schedule 是用來 Delay 的
Schedule 是用來 delay 的。
出處: 工作時有感而發
作者: 曾暘展
感想: 計畫永遠趕不上變化，Schedule永遠都是變動的，參加過的專案沒有一個不DELAY，衛星發射會DELAY，系統安裝會DELAY，連參加過的國外專案進度也DELAY，
DELAY輕則半年，重則二年以上，已經到了 Schedule 是參考用的，如果客戶再來個需求變更，那真的只有DELAY到天荒地老。
2009年10月28日 星期三
Q38: 你愈急著開始，你的路愈長。Fred Brooks
The sooner you start, the longer it takes. - Fred Books
這是Brooks在1975出版的『The Mythical Man Month』裡的一句雋語，強調軟體專案的充分準備不致於浪費，如果你跳過需求蒐集，你設計的東西就非客戶所需，如果你的設計不佳，你將會發展一些無意義的程式。以今日的軟體發展法來看，這句格言(dictum)似乎理所當然，而且已歷經三十幾年，其間軟體發展方法也多所改變，但是至今仍然有用，Brooks這句格言是在提醒，從事好的設計仍然是軟體發展的重要過程。
這是Brooks在1975出版的『The Mythical Man Month』裡的一句雋語，強調軟體專案的充分準備不致於浪費，如果你跳過需求蒐集，你設計的東西就非客戶所需，如果你的設計不佳，你將會發展一些無意義的程式。以今日的軟體發展法來看，這句格言(dictum)似乎理所當然，而且已歷經三十幾年，其間軟體發展方法也多所改變，但是至今仍然有用，Brooks這句格言是在提醒，從事好的設計仍然是軟體發展的重要過程。
訂閱：
文章 (Atom)