Q50: 澄清思想才能使事務做到簡單(賈伯斯)。

在軟體發展上善用CRC cards或許可以幫你/妳做到這一點。

Q51: 蘋果之所以成功，包括產品與推廣，乃是因其堅持『簡單至上』的原則，發展軟體系統亦應如斯。

所謂簡單的觀念是：『硬體簡單化，而背後的軟體卻豐富化』(尤其對蘋果產品而言)。簡單的觀念可以運用在軟體系統的發展上(請參考部落格文章：『「簡單」-讓混亂發展成規則』)。P.J. Plauger與B.W. Kernighan認為"Keep it simple to make faster."我想發展軟體應該遵從「簡單」的原則。使用蘋果產品的人士或可參考這一則諺語。

Q49 很少事務比列舉好的範例更實在。

馬克‧吐溫："Few things are harder to put up with a good example." ， 要說明一件事務列舉適當的例子最能說明白，不論教學或某理論的敘述，事實上，在日常生活中，這句話一樣適用，有些人，亂舉一些「543」的例子，不知所云。

Q48: 分析的結果必須反應確切的問題敘述以及可能解決方案的限制，但不一定有作用。

Rebecca Wirfs-Brock: "Analysis results need to reflect an accurate statement of the problem and constrain possible solution, but they don't have to work." 分析是在反應使用者的真實世界，而設計必定會反應實作者的世界，兩者並不一定完全一致，因為設計者仍然必須解決一些實作的問題，因此實作時會加上一些條件，這種現象十分普遍，解決之道可能可以使用敏捷方法或MDA技術，甚至CRC cards技術，因為非正規的發展流程允許參與者提供設計意見而無障礙。

Q47： 如果你能衡量而能用數據表達你所說的，就表示你知道你在說甚麼，否則你的知識是貧乏而且不完整。

這是原自於Lord Kelvin (1883)所說的話："When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knoledage is of a meager and unsatisfactory kind."這則諺語是『軟體度量』的基本之一。

Q46：除非即刻需要而且有意義否則就不要產生文件。

這是所謂Martin's First Law of Documentation，這個規則係來自「敏捷宣言」第二項:『可用的軟體重於詳盡的文件』，這並非叫你不要寫文件，但太多太詳盡的文件不如少一點，發展團隊撰寫與保養的是簡短合理且有結構的文件，這就是Martin的第一文件規則。

Q45：大致對比嚴格錯來得好。

來自 "It is better to be roughly right than precisely wrong." (John Maynard Keynes 英國經濟學家 1883-1946)，這是在呼應Q44諺語。

Q44: 開發沒有終點。只有釋出 (release)。

對於多數的軟體開發，不斷的功能延伸、錯誤修補是很常見的。如果要等到完全的開發完畢才做系統的發佈，恐怕永遠沒有上線的一天。

所以階段性的版本釋出計畫是很重要的。相繼而來的錯誤追蹤管理也很重要。

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.

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所講，『反覆與漸增發展方法』應該是核心所在。

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的『好人難為』一文)。

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)

Q39: Schedule 是用來 Delay 的

Schedule 是用來 delay 的。

出處: 工作時有感而發

作者: 曾暘展

感想: 計畫永遠趕不上變化，Schedule永遠都是變動的，參加過的專案沒有一個不DELAY，衛星發射會DELAY，系統安裝會DELAY，連參加過的國外專案進度也DELAY，

      DELAY輕則半年，重則二年以上，已經到了 Schedule 是參考用的，如果客戶再來個需求變更，那真的只有DELAY到天荒地老。

Q38: 你愈急著開始，你的路愈長。Fred Brooks

The sooner you start, the longer it takes. - Fred Books

這是Brooks在1975出版的『The Mythical Man Month』裡的一句雋語，強調軟體專案的充分準備不致於浪費，如果你跳過需求蒐集，你設計的東西就非客戶所需，如果你的設計不佳，你將會發展一些無意義的程式。以今日的軟體發展法來看，這句格言(dictum)似乎理所當然，而且已歷經三十幾年，其間軟體發展方法也多所改變，但是至今仍然有用，Brooks這句格言是在提醒，從事好的設計仍然是軟體發展的重要過程。

Q37: 除三個錯就會冒出一個錯。這稱為bug的無窮迴圈。

除三個錯就會冒出一個錯。這稱為bug的無窮迴圈。

Q36: 沒有對或錯的模式，只是對手邊的工作是否有大用處。Martin Fowler (1997)

There is no right or wrong model, merely one that is more useful for the job at hand. - Martin Fowler (1997)

這句諺語是 Martin Fowler在解釋『觀念模式』(conceptual model)時所提出的模式塑造原則。軟體發展者因對於許多企業的基本需求往往不完全了解，所以要建立所謂觀念模式，以便能夠了解並簡化問題，這種模式有時稱為範疇模式(domain model)，而是一種人工產品(human artifact)，雖然非軟體本身，但其部分可轉換成實作。

Q35: 為何有些軟體工程師與電腦科學家能夠產生清楚而且優美的設計與程式，但其他人卻不能？關鍵在於抽象觀念。Jeff Kramer

Why is it that some software engineers and computer scientists are able to produce clear, elegant desings and programs, while others cannot? Critical to these questions is the notion of abstraction. Jeff Kramer (CACM 50(4), 2007, pp.36-42).

諺語提供：黃為德教授

Q34. 簡化(處理)變更比企圖防備它更有效，學習相信你對不可預期事故的反應能力，比相信對規劃如何(處理)災難的能力更重要- Martin Fowler and Jim Highsmith

Facilitating change is more effective than attempting to prevent it. Learn to trust in your ability to respond to unpredictable events. It’s more important than trusting in your ability to plan for disaster. Martin Fowler and Jim Highsmith

諺語提供：黃為德教授

Q33: 我總是發現計畫沒什麼用，但計畫的過程是不可避免的。Dwight Eisenhower

I have always found that plans are useless, but planning is indispensable. Dwight Eisenhower.

Q32: 除錯的難度幾乎是寫該程式碼的兩倍。因此，如果你把程式寫的太精巧，那們，你大概不足夠聰明到可以解決你程式的錯誤。B.W. Kernighan

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. B.W. Kernighan.