閱讀作業二之The Cathedral and the Bazaar和A Generation Lost in the Bazaar——洪虹

。　　《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恰恰是以設計簡約、功能實用、執行優雅而著稱於世的。

　　這樣極端的思想發差值得我們深思，到底哪一種模式才是真正對我們軟體工程開發有協助的？我覺得，我們應該在二者之間找到一種平衡，不能極端地傾向於某一邊。就像我們看待理想模型那樣，我們需要做的應該是在最適當的地方選用最恰當的模式去解決問題，而非坐著討論哪一種模式需要被淘汰。