。 《The Cathedral and the Bazaar》一书，是作者埃里克·斯蒂芬·雷蒙（Eric Steven Raymond）所撰写的软件工程方法论。以Linux的核心开发过程以及作者自己主持开发的开放源代码软件──Fetchmail为讨论案例。就两种基础不同的软件发展风格来探讨这些理论：一是大部分商业化世界所采用的“教堂”模式（Cathedral），另一种是Linux世界所用的市集模式(Bazaar)，这是由于对软件除错工作本质相左的假设而导致这两种不同的模式。
简而言之，所谓的大教堂模式（The Cathedral model）：源代码在本模式是公开的，但在软件的每个版本开发过程是由一个专属的团队所控管的。
市集模式（The Bazaar model）：源代码在本模式也是公开的，不过却是放在互联网上供人检视及开发。
书中讲了很多有意思的内容，然而由于有些内容涉及的专业性较强，我看的不太理解，然而书中贯穿始终的一系列格言却是值得我们在做软件工程的过程中反思和理解体会的。
[格言 1] 好軟件都是起源於程式發展者要解決切身之痛.
1. Every good work of software starts by scratching a developer's personal itch.
这句话很实在，的确很多软件的诞生仅仅是由于我们需要用它解决一些身边的问题。这也反映了做软件的初衷——方便人们的生活。这种返璞归真的理念有时候却很容易被人们所遗忘。即便我们做出一款很华丽很强大的软件，但是如果过于复杂倒是用户难以理解使用，反而会带来更多的问题。放弃了初衷，还何谈做好软件？
[格言 2] 優秀的程式師知道要寫程式, 偉大的程式師知道要改寫 (和重覆利用) 程式.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
优秀和伟大的差距在哪？为什么很多软件的第一发明者在历史上都难觅其名？关键就在于伟大的程序员知道将一个程序一个软件不断改革提升，不会有一出世就完美的东西，软件的生命周期是需要不断优化革新的，这样才能不断满足人们的需要，知道如何让它变得更好有时候比创造它更重要。
[格言 3] “計畫好如何捨棄一條路吧, 你遲早會想盡辦法這麼做的.”
3. ``Plan to throw one away; you will, anyhow.''
这是我们在做软件的过程中常常会遇到的状况，可能我们一开始设计的思路很完美，但是有限的时间内我们常常可能无法面面俱到，这样就要求我们有所取舍，砍去最次的功能，有时候这也是一种智慧。
[格言 4] 抱持正確的態度, 就會發現有趣的問題.
4. If you have the right attitude, interesting problems will find you.
做工程的过程中可能会很辛苦很累，但是，如果能够保持着积极地态度，就能从中找到乐趣找到动力。
[格言 5] 當你對一個問題不再感興趣時, 你最後的責任就是找位能勝任的接棒人.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
想起老师上课讲的一句话：“在软件工程中，没有人是不可替代的”。我们可以选择投入其他的工程其他的工作中，前提是你必须要把自己那部分工作交接完成，这也算是作为程序员的责任吧。
[格言 6] 把你的使用者視為協同發展人, 可以讓你傷最少的腦筋, 但做到原始碼的快速改善，程式的除錯有績效.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
程序员有时候要能够从用户的角度去审视我们在做的软件，比如在测试的过程中，我们应当从用户的立场出发，用各种极端的使用方式来考验软件的功能性，这样可以将很多BUG扼杀在萌芽阶段。
[格言 7] 儘早, 經常發表新版本, 並且傾聽使用者的意見.
7. Release early. Release often. And listen to your customers.
正如老师所说，真正好的软件应该是能持续更新的，而这一过程中，用户回馈的信息能起到指导性的作用。
[格言 9] 聰明的資料結構配上笨拙的程式碼要比相反的組合好.
9. Smart data structures and dumb code works a lot better than the other way around.
这句话指出了一个重点——代码在软件工程实践里只是一部分而已，却不是最重要的一部分，数据结构的优劣反而更能影响最终软件的好坏。
[格言 13] 設計上完美, 不是 “沒有東西能再被加入”, 而是“沒有東西能再被移出”.
13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.''
我们所能追求的设计上的完美，不是集所有功能于一身，这是不现实不科学的，我们能做到的就是让软件尽可能地优化，使其尽可能不含有冗余代码。
由于大教堂模式的软件开发让程式除错的时间大幅增加，因为只有少数的开发者可参与修改工作，市集模式则相反。因此，我们的团队用的是市集模式，通过TFS平台，我们小组成员可以看到完整的代码工程，而与我们协作的别的UI小组也能阅读到我们的部分，这样大大加快了工程的进度。这也是此书作者所崇尚的模式。
然而在另一篇文章《A Generation Lost in the Bazaar》中，作者却报以不同的观点，警醒我们不要在市集模式中迷失。他认为，Raymond在其书中称颂的集市模式导致的悲哀的现实：一坨脓包似的权宜代码，被一群盲目的根本不知IT架构为何物的所谓IT“专业人士”永无休止地复制着，粘贴着。这事儿放在今天你也许很难相信，但就是在这令人无比尴尬的混沌之下，沉睡着美轮美奂的Unix大教堂的遗迹，而Unix恰恰是以设计简约、功能实用、执行优雅而著称于世的。
这样极端的思想发差值得我们深思，到底哪一种模式才是真正对我们软件工程开发有帮助的？我觉得，我们应该在二者之间找到一种平衡，不能极端地倾向于某一边。就像我们看待理想模型那样，我们需要做的应该是在最适当的地方选用最恰当的模式去解决问题，而非坐着讨论哪一种模式需要被淘汰。