大教堂和市集
《大教堂與市集》（The Cathedral and the Bazaar）是埃里克·史蒂芬·雷蒙（Eric Steven Raymond）所撰寫的軟體工程方法論。以Linux的核心開發過程以及作者自己主持開發的開放原始碼軟體──Fetchmail為討論案例。
- 好軟體都是起源於程式發展者要解決切身之痛。[2]
- 優秀的程式師知道要寫程式，偉大的程式師知道要改寫(和重覆利用)程式。[3]
- 計畫好如何捨棄一條路吧，你遲早會想盡辦法這麼做的。[4][5]
- 抱持正確的態度，就會發現有趣的問題。[6]
- 當你對一個問題不再感興趣時，你最後的責任就是找位能勝任的接棒人。[7]
- 把你的使用者視為協同發展人，可以讓你傷最少的腦筋，但做到原始碼的快速改善，程式的除錯有績效。[8]
- 儘早，經常發表新版本，並且傾聽使用者的意見。[9]
- 以足夠多的 beta 版測試者和協同發展者做基礎，幾乎程式中的每一個問題都可以很快地找出來，並且對某些人而言,，針對發現的問題的解決方法是顯而易見的。[10]
- 聰明的資料結構配上笨拙的程式碼要比相反的組合好。[11][12]
- 如果你視 beta 版測試者如同你最珍貴的資源，那麼他們會以此做為回報。[13]
- 體認你使用者提供的巧思，以獲取好點子，有時候越後到的越好。[14]
- 通常，最適切和最有創意的解題法來自發覺自己對問題原先的觀念是錯誤的。[15]
- 設計上完美，不是「沒有東西能再被加入」，而是「沒有東西能再被移出」。[16]
- 任何的工具以我們所知道的方法來使用都會有用，但一個真正了不起的工具會以你從未想過的使用方法來發揮它的功能。[17]
- 寫作任何的通信閘軟體時，要盡可能地不去擾動到通訊的資料流 -- 並且絕對不要丟掉其中任何的資訊，除非接收方強迫你這麼做。[18]
- 當你設計的語言不是嚴謹到「完全 Turing」，你可以採用比較平易的語法。[19]
- 一個保密系統是否安全依存於它隱藏的秘密，注意不要有「虛擬秘密」。[20][21]
- 為了要解有趣的問題，開始找你感興趣的問題吧！[22]
- 假如專案發展協調者擁有至少跟網際網路一樣好的媒體，而他也不靠強制力來領導，那麼一群人必定勝過一個人。[23]
註解
編輯- ↑ 參考資料︰教堂觀與市集觀
- ↑ 原文︰Every good work of software starts by scratching a developer's personal itch.
- ↑ 原文︰Good programmers know what to write. Great ones know what to rewrite (and reuse).
- ↑ 原文︰Plan to throw one away; you will, anyhow.
- ↑ 出處︰Frederick P. Brooks, Jr，《人月神話：軟體專案管理之道》，台北：經濟新潮社，2004年：第十一章 ISBN 9867889185
- ↑ 原文︰If you have the right attitude, interesting problems will find you.
- ↑ 原文︰When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
- ↑ 原文︰Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
- ↑ 原文︰Release early. Release often. And listen to your customers.
- ↑ 原文︰Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
- ↑ 原文︰Smart data structures and dumb code works a lot better than the other way around.
- ↑ 說明︰相反的組合指笨拙的資料結構配上聰明的程式碼
- ↑ 原文︰If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
- ↑ 原文︰The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
- ↑ 原文︰Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
- ↑ 原文︰Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
- ↑ 原文︰Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
- ↑ 原文︰When writing gateway software of any kind, take pains to disturb the data stream as little as possible -- and *never* throw away information unless the recipient forces you to!
- ↑ 原文︰When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
- ↑ 原文︰A security system is only as secure as its secret. Beware of pseudo-secrets.
- ↑ 說明︰以 fetchmail 為例，隱藏的秘密是指「通行密碼」；「虛擬秘密」是指把通行密碼編碼後存於設定檔中。
- ↑ 原文︰To solve an interesting problem, start by finding a problem that is interesting to you.
- ↑ 原文︰Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
