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：專家系統是一個程序,包含一個廣義推理引擎和一個規則庫,需要輸入數據和假設,通過推理規則庫可誘導產生結論和建議,并提供解釋。推理引擎通?？梢蕴幚砟：蚋怕蕯祿鸵巹t,除了純粹的確定性邏輯。

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　　軟件工程的方法論到底有多少用處?

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

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

轉載于:https://www.cnblogs.com/someonefighting/p/4963118.html

總結

以上是生活随笔為你收集整理的软件工程的瀑布, 大泥球, 教堂，集市，和银弹的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。