重意味着嚴謹、繁瑣，輕則意味着迅捷、零散。應當輕還是重？這是個問題
通過這次的閱讀任務，我想從這兩個方面談軟件工程的輕與重：開發流程模式 與 開發團隊模式
開發流程模式的輕與重：
Managing the development of large software systems: concepts and techniques
理想的瀑布模型：
系統需求——>軟件需求——>分析——>程序設計——>編碼——>測試——>運行
an implementation steps to develop a large computer program for delivery to customer
這個模型是如此簡潔，以至於我在上大學后很長一段時間就認為這就是軟件開發唯一的模式（在長期地獨立進行小型結構化編程訓練）。事到如今，我固然意識到了我的圖森破，瀑布開發模式已不再適用於大部分軟件的開發，但其中原因並不那么簡單，這些原因也在向我們展示着軟件工程不同於人類其他工程模式的特點，給從事軟件開發的我們以啟示。
早期的瀑布模型可歸為軟件開發工程方法（engineering methodologies），這種模式的特點是將設計與實施一分為二，這種思路在其他工程領域是理所應當的，如果建設者在建造橋梁過程中同時進行施工和設計是不可想象的。然而，軟件開發過程事實上的確有很多不同之處，當開發團隊正在編碼時發現需求分析工作有所缺陷（這在軟件開發中是非常常見的），他們不得不重新做需求分析、修改之前的設計、進而修改代碼。如果來自瀑布上層工作的缺陷僅僅帶來下層的修改工作應該說是很幸運的了，如果開發團隊篤信工程方法，他們不認為導致他們返工的意外情況會不時出現，他們會及其嚴謹地按照當前及其嚴密而步驟清晰的設計來實施（這就是常見的工程模式）。如果當他們大功告成時發現他們的產品不符合用戶的需求，那么恐怕就是前功盡棄，要推倒重做了。由此，瀑布模型又衍生出了一些變化的版本，如不同步驟間具有交互的模型，但即便如此其模式仍顯得古板，而且需要大量文檔的支持。隨着軟件工程方法的不斷實踐，這個重量級的辦法在大多數軟件開發過程中越發顯得笨重而低效。
The New Methodology
Most software development is a chaotic activity, often characterized by the phrase "code and fix". The software is written without much of an underlying plan, and the design of the system is cobbled together from many short term decisions.
在非正規的軟件開發過程中，上述這種情況是很常見的。code and fix應該是最早的軟件開發模式，工程模式是它的后來者，而兩者互相之間並不能取代另一方。code and fix 對小型項目很管用，但對於大項目來說會導致系統的混亂以及調試困難。工程模式使得大型軟件項目開發變得嚴謹有序，但是軟件開發的特性決定編碼的時候總會出現總體設計考慮不到的問題，局部的code and fix是難以避免的。這種超輕量級的開發模式雖無章法，但暫且算一種“方法”。
敏捷型方法（agile methodologies）的發展是對這些工程方法的反叛。 對許多人來說，這類方法的吸引之處在於對繁文縟節的官僚過程的反叛。它們 在無過程和過於繁瑣的過程中達到了一種平衡，使得能以不多的步驟過程獲取 較滿意的結果。
敏捷型與工程型方法有一些顯著的區別。其中一個顯而易見的不同反映在文檔 上。敏捷型不是很面向文檔，對於一項任務，它們通常只要求盡可能少的文檔。 從許多方面來看，它們更象是“面向源碼”（code-oriented〕。事實上，它們 認為最根本的文檔應該是源碼。
但是，我並不以為文檔方面的特點是敏捷型方法的根本之點。文檔減 少僅僅是個表象，它其實反映的是兩個更深層的特點：
- 敏捷型方法是“適應性”而非“預見性”。 工程方法試圖對一個軟件開發項目在很長的時間跨度內作出詳細的計划， 然后依計划進行開發。這類方法在一般情況下工作良好，但（需求、環境等） 有變化時就不太靈了。因此它們本質上是拒絕變化的。而敏捷型方法則歡迎 變化。其實，它們的目的就是成為適應變化的過程，甚至能允許改變自身來適 應變化。
- 敏捷型方法是“面向人”的(people-oriented) 而非“面向過程”的 (process-oriented)。 工程型方法的目標是定義一個過程，不管是誰用都工作。而敏捷型方法 則認為沒有任何過程能代替開發組的技能，過程起的作用是對開發組的 工作提供支持。
軟件開發的特性，不完全的總結如下：
1.設計工作與實施過程難以分離，軟件開發本身是創造性的工作而不是重復性的工作
2.具體操作（編碼）過程會出現很多難以預計的問題
3.面向各個不同應用領域的軟件需要應對各種不同的需求，需求分析人員缺乏軟件開發專業知識，開發團隊也不了解應用領域的知識，需求分析在軟件開發過程中是遞進地、不斷完善的
4.軟件本身實質上僅僅是代碼，代碼是靈活的，修改代碼的代價較小（相對土木工程等），同時測試版本很容易實現。沒有什么比軟件本身更能向人展示、說明產品情況的了
基於以上特性，新方法學提倡：迭代式的開發模式以應對長遠計划的困難，將軟件設計與編碼結合，不停地發布測試版本同時完善需求；適應性的客戶，客戶必須適應這種非一次性計划的模式，與團隊保持緊密聯系，及時地給予回饋，並相信開發團隊能夠保質保量完成工作；以人為本的管理理念，軟件開發是創造性的，開發人員應當是高素質、自覺地，工作應由術人員負責管理而不是領導，由業務專家提供指導建議。
敏捷型方法不僅尊重軟件開發的特性，也受到技術人員的歡迎。在開發流程的輕與重之間，敏捷型方法趨於一種平衡。作為不斷發展的新方法，這是一種模式上的突破。
開發團隊模式的輕與重：
Cathedral and the Bazaar
當開源運動"如火如荼"的進行之時，我還是個小學生。如今浪潮已經過去，我只能憑借資料和腦補想象那種盛況了。
<<Cathedral and the Bazaar>>作者 Eric S. Raymond 基於他對linux內核開發過程的觀察和開源軟件項目的管理經驗，提出了19條開源開發守則。盡管此書在開源工作者之中廣泛流傳並備受推崇，但開源開發至今仍顯露出眾多問題。
所謂質量，只有在某人對它負責時才有意義，而這個“某人”只能是一個人，不能是幾個人——二重奏除外
——Frederick P. Brooks
Lost in CatB
當開源帶來極高的生產率的同時，軟件的質量也遭到嚴重的破壞。Raymond認為開源意味着更多開發者，更多的開發者意味着更少的bug能夠溜掉，從而提高軟件的質量。然而正如上面這句話所說的，實際情況是，如果一個有bug的程序到了10個開源開發者手中，也許會有7個人發現bug，其中5個人會修改（倆人放棄），1個人會上報給程序的提供者完善程序，而剩下3個人用它寫出了依然有bug的程序並流傳到更多人那里。
開源雖然創造了史無前例的全民編程熱潮，但也導致了無責任、非專業、凌亂的軟件開發。在浪潮退去后，傳統的緊密聯系的團隊開發，依然是現在軟件開發模式的主流。
在開源的輕與傳統的重之間，似乎還沒有像敏捷性方法在開發流程上取得成功那樣有一個比較完美的平衡點，或許android可以算是一個正面例子，但開源僅限於應用層面，系統開發仍然是傳統、封閉的。
big ball of mud
大泥球發生的主要原因可以歸結為：
- 一次性代碼
- 碎片式增長
- 為了讓軟件不出問題
- Copy/paste導致問題轉移（有問題的代碼被復制到很多地方，不斷蔓延）
大泥球之罪的根源可以說就是code and fix，如果 code and fix 是無法回避的，那么大泥球也無法徹底規避。然而，有責任感、專業的技術人員能夠幫助減少泥球。
No Silver Bullet - Essence and Accidents of Software Engineering
軟件產業為什么沒有像我們的計算機硬件、工業產品那樣在近幾十年里生產率翻了數十番，從渴望不可及到走進千家萬戶，這是此篇文章討論的核心問題。
作者Brooks認為，附加性的困難會隨着工具的改善而逐漸淡化，反而是本質性的困難最難以解決，因為大部分的活動是發生在人們的腦海里，缺乏有效的輔助工具。依造Brooks的說法有下列幾項：
- 復雜性（complexity）：軟件要解決的問題，通常牽扯到計算步驟，這是一種人為、抽象化的智能活動，多半是復雜的。
- 隱匿性（invisibility）：尚未完成的軟件是看不見的，即使利用圖標說明，也常無法充分呈現其結構，使得人們在溝通上面臨極大的困難。
- 配合性（conformity）：在大型軟件環境中，各子系統的接口必須協同一致。由於時間和環境的演變，要維持這樣的一致性通常十分困難。
- 易變性（changeability）：軟件所應用的環境常是由人群、法規、硬件設備、應用領域等，各因素所匯集而成，而這些因素皆會快速變化。
Brooks對銀彈寄希望於實現現代設計與模塊化概念的特征的程序設計語言（如Ada）和面向對象程序設計技術，但如今事實證明這些並沒有解決軟件工程生產率面臨的基本問題。對很多人而言，編程的創造性正是吸引他們的地方，但如果軟件開發仍然是一件創造性的工作，而創造與實現兩個步驟難以分開（如在上文軟件開發特性中提到的），那么其生產率的低下就是不可避免的。
自動化的軟件開發是銀彈的終極形式，但實現的方法仍遙遙無期。不過我相信終有一天，軟件開發能夠像編譯工作一樣，由少部分專業人士的努力徹底解放軟件生產力。