軟體工程的瀑布, 大泥球, 教堂，集市，和銀彈

標籤：

0x1 No Silver Bullet

1           There is no royal road, but there is a road

軟體工程缺乏一劑良藥，在硬體成本隨著發展速度快速下降的同時，軟體工程的成本並沒有出現明顯的下降，然而，隨著軟體工程持續的、堅持不懈的發展，軟體工程正在發生著重量級的變化。

2           Does It Have to Be Hard?--Essential Difficulties

必須觀察到異常不是軟體進展如此緩慢,而是電腦硬體進步太快。沒有其他技術文明能夠像電腦硬體這樣已經六個數量級在效能價格上漲30年。沒有其他技術可以以這樣的速度提高效能或降低成本的。這些收益從電腦製造裝配行業流轉到加工製造工業。

一個軟體實體的本質是聯鎖的構造概念:資料集,資料項目之間的關係,演算法,以及調用的函數。這本質上是抽象的,這樣一個概念性的構造在不同的表現形式下都是一樣的。它無疑是非常準確和豐富詳細的。軟體設計的難度不在於計算的精確度和功能測試，但是更重要的是規格說明書的設計和概念意義上的結構。

現代軟體系統的固有屬性決定了軟體開發發展的難度:複雜性、整合性,可變性和不可見度。

複雜性：團隊成員之間交流困難導致產品缺陷,成本超支、進度拖延；難以列舉所有程式的可能狀態導致程式是不可靠的；函數調用函數的複雜性使項目難以使用。難以擴充程式新功能而不產生副作用造成結構的複雜性。

一致性：雖然說軟體工程並不是唯一複雜的學科，但是同樣面對複雜物件的物理學家，由於大自然的規律，他們有統一的規律可以遵循。

易變性：軟體產品是嵌入在一個文化的應用程式,受制於使用者,法律,和機器。所有這些變化不斷,他們無情地把改變強加於軟體產品的變化。

不可見度：軟體不像地圖可以繪製出幾何圖層便於理解，在空間中往往是難以理解的。

3           過去的小突破

3.1     進階程式設計語言：它使一個程式的偶發複雜度。抽象的程式包括概念結構:操作、資料類型、序列,和互動。具體的機器嗎是和寄存器,條件,分支,通道,磁碟等相關的。在某種程度上,進階語言構造了一個較低的抽象程式，極大降低了編程的複雜性。

3.2          分時系統：分時系統帶來了一個重大的改進，提高了程式員的生產率和產品品質，

儘管不像進階語言帶來那麼大的作用。但是分時產生了一個截然不同的困難。分時需要及時儲存資訊。批編程的緩慢輪轉意味著會不可避免地忘記細節,如果沒有恰當的時機重新整理記憶體就直接進行編譯和執行。這個中斷是昂貴的,必須不斷地更新記憶體。

3.3          統一的編程環境

4           潛在的良方

4.1          Ada and other high-level language advances.

Ada哲學比Ada語言更多的是一種進步,因為這是模組化的哲學,抽象資料類型的階層。

4.2          Object-oriented programming：提供了封裝機制

4.3          Artificial intelligence：關於人工智慧存在兩種定義，使用電腦來解決問以往只能通過人類的智慧來解決的問題；使用一組特定的編程技術被稱為啟發學習法或基於規則的編程，讓電腦模仿人類解決問題的方式。事實上，真正的人工智慧是無法實現的。

4.4          Expert systems：專家系統是一個程式,包含一個廣義推理引擎和一個規則庫,需要輸入資料和假設,通過推斷規則庫可誘導產生結論和建議,並提供解釋。推理引擎通常可以處理模糊或機率資料和規則,除了純粹的確定性邏輯。

0x2 big ball of mud

         我認為這依賴於良好的編程習慣，如果能夠在編程的同時進行系統化模組化測試，那麼編程效率就會大大提高，處理Bug的速度也會加快。

         除此之外，代碼是需要不斷進行完善精簡的，不能因為眼前的Bug就隨便修改代碼，破壞了當初設計的代碼的結構，軟體的架構也非常重要。

所謂大泥球，是指雜亂無章、錯綜複雜、邋遢不堪、隨意拼貼的大堆代碼。這些年來，為了對付這個泥球，多種指導方法一起出現，然而實際情形沒多大變化，“大泥球”看起來仍然是設計軟體架構的最常見方法。我們現在慣用的敏捷性開發的很多方面會直接導致泥球，包括：缺少前期設計、應對需求變化過晚、應對架構變化過晚、片段式增長。

那麼我們如何發現爛代碼？爛代碼要不要改呢？應該怎麼改？如果爛代碼不是先天性的，那是不是可以預防？

程式是面向使用者的，為了方便應用的更新，應提前設計好程式的結構，便於後續最佳化。

　　我們團隊的代碼中也肯定存在著大泥球，這需要我們不斷進行完善。

0x3　　CatB – Cathedral and the Bazaar

         我感受比較深的一句話是——如果你把公測參與者作為最寶貴的資源來對待，那麼他們就會成為你最寶貴的資源。我們需要擴大軟體的使用者群，這樣才能更好的完善功能。

         儘早和盡量頻繁的發布是Linux開發模式的一個重要部分。然而對於一個大型工程來說這並不是個好辦法。因為早期版本幾乎就是問題版的同義字，而過早地發布會把使用者的耐心消耗殆盡 。但是隨著功能的完善，可以進行預發布來測試軟體的穩定性。

0x4　Lost in CatB這些情況在你的團隊中出現過麼?

作者主要講述了開源軟體中的過度依賴問題。我自己在寫程式的過程中，常常為了方便調試把測試檔案放的到處都是，也沒有集中在同一個目錄下，這樣在後期的軟體維護過程中造成了很大的不便。

在今後的開發中，我們團隊將固定好軟體結構架構，保持結構思路的清晰。

 

0x5　Managing the development of large software systems: concepts and techniques

我覺得瀑布模型的其核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協作，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。瀑布模型將軟體生命週期劃分為軟體計劃、需求分析和定義、軟體設計、軟體實現、軟體測試、軟體運行和維護這6個階段，規定了它們自上而下、相互銜接的固定次序，如同瀑布流水逐級下落。

瀑布模型有利於大型軟體開發過程中人員的組織及管理，有利於軟體開發方法和工具的研究與使用，從而提高了大型軟體項目開發的品質和效率。而對於我們這種較小規模的軟體開發項目，瀑布模型並無裨益。

0x 6　　軟體工程的方法論到底有多少用處?

         現代軟體工程方法論大致可以分為重方法論和敏捷方法論兩大陣營，在很多書籍中將它們之間的區別總結為"文檔量"的重與輕，實際上有些以偏蓋全！如果從對開發工作的影響角度看，它們之間更重要的區別在於：重方法論更加強調前期設計，為未來設計；而敏捷方法論則更加強調只為現在設計，未來再重構它！而就是這個最為本質的區別才是根據項目實際特點進行正確選擇的基礎。

在軟體技術的發展道路中，方法論起著決定性的作用。軟體技術人員有必要站在哲學的高度、從方法論的角度，重新審視軟體開發過程中各個環節，深刻體會軟體工程和方法論的聯絡，從而改進和發展的現有的軟體工程技術，消化吸收先進的思想、方法和技術，提高軟體的品質和生產率，以適應現實世界對軟體產業新的要求。軟體工程應運而生。為了更好地發展和改進軟體工程技術，我們有必要從方法論的各個角度分析軟體工程的方法、工具和過程，從而有的放矢地改進軟體工程中各個過程的思想、方法、模式和規則.

軟體工程的瀑布, 大泥球, 教堂，集市，和銀彈