我的閱讀&我的總結

助教推薦的這些文章都是軟件工程的經典之做，讀完以後對這學期的軟工學習有了更深的認識。才以爲學習軟件工程以前寫的都不算是軟件工程，只是些程序。真正的軟件工程歷史悠久，其對程序員帶來的痛苦伴隨着不少代人，許多經典的軟件工程著做和討論都是幾十年前就完成的，雖然軟件行業突飛猛進，但其中的哲學和根本卻從未改變。

軟件工程中到底有沒有銀彈呢？

No Silver Bullet --Essence andAccident in Software Engineering

在西方文化中，狼人是一種十分可怕的怪物。其最恐怖的地方在於，他們會突然從十分熟悉的人變爲惡魔。就像中國的黑狗血能夠制服妖怪同樣，狼人的剋星是銀彈(Silver Bullets)。做者用狼人來比喻軟件工程，銀彈以比喻能夠克服軟件工程中困難的通用方法。人們渴望獲得銀彈，但就像題目所直截了當地描繪的那樣，做者認爲並不存在這種通用方法。

首先，從軟件開發近10年的歷史（文章寫於1986年）上來看，不存在一種單獨的開發、技術或管理技巧能夠徹底保證效率、可靠性、簡易性的提升。
其次，軟件開發中存在一些本質的困難。

• 硬件速度的增長相對軟件開發的進步是十分快的。
• 軟件自己內在的困難（複雜性、整合性、不斷變化性、不可見性）和不斷出現的意外。

在解決這些問題的過程當中，工程師們取得了一系列突破：高級程序設計語言、時間共享、統一的編程環境。Brooks還提出了一些可能銀彈：高級程序設計語言、面向對象編程、甚至是如今火爆的人工智能和其中的專家系統、自動化編程等，但這些候選的銀彈都有不足之處，有些在當時甚至如今都不現實。最後，Brooks提出在目前沒有所謂銀彈的狀況下，細化需求、快速原型設計、優秀的設計人員是軟件工程的解決方案。

There is a Silver Bullet

這篇文章（2004年）是對上一篇文章No Silver Bullet的補充和反駁。開始的引用部分，做者引用了上一篇文章做者Brooks的話，提出狼人和銀彈的概念。首先，做者回顧了工業的發展史，尤爲是最近的信息革命的誕生。以後，做者介紹了從軟件工程誕生起的一系列討論和成果，包括我正在讀的《人月神話》和同做者Fred Brooks的文章「No Silver Bullet: Essence and Accidents of Software Engineering"(也就是上一篇文章)。就Brooks沒有銀彈的論點進行反駁。

Cox認爲，構建易用和可服用的組件是解決軟件工程問題的關鍵，更高級的抽象，也就是面向對象程序設計是所謂的銀彈。

根據本文做者Brad J. Cox的履歷，他是「Object-Oriented Programming: An Evolutionary Approach「的做者，也是Objective-C系統構建環境的創造者。不難理解他對面向對象編程的熟悉和推崇，認爲面向對象就是軟件工程中的銀彈也就能夠理解了。

Big Ball of Mud

所謂的大泥球是指沒有清晰結構的系統。在實際開發中，咱們經常爲了趕作feature，在沒有充分設計和調研的狀況下寫出大量快速但不可複用的代碼。隨着feature越作越多，剛開始設計不足的問題就凸顯出來。代碼中的垃圾愈來愈多，整個項目變得難以維護和進一步開發。

CatB - Cathedral and the Bazaar

這本書（最開始是一篇論文，以後書寫成書）是Eric S. Raymond根據他對Linux內核的觀察和管理開源項目的經驗撰寫而成的。在書中，Raymond提出了自由軟件開發的2種模型。教堂模型和即便模型。教堂模型指只有release版的源碼公開，而集市模型中，全部源碼公開，外界能夠看到開發的全過程。Raymond相比之下更加推崇集市模型。他認爲，更多的公開會暴露更多的bugs。

咱們的團隊採用的是集市模型，即全部的開發過程均可以在GitHub上看到。

Lost in CatB

文中做者舉了2個例子。一個是關於十年前（2000年先後）他親身經歷的.COM的火爆，另一個是做者在使用FreeBSD過程當中，因爲軟件的依賴和代碼的複用，而迷失在集市中。

如今Web技術從新火爆起來，NodeJS、Angular、Vue、TypeScript等各類技術層出不窮，前端成爲一個技術更新飛快的領域，但在不少時候缺少一個標準，這已經被全部人包括衆多前端工程師所吐槽。我以前由於實習的須要而接觸過前端，使用Angular框架構建一個dashboard以向用戶顯示必要的信息。追隨最新的概念和技術，我構建了一個Single-page Application，使用Webpack等工具鏈進行打包......最後完成這個項目時，node_modules裏已經有多達200M的依賴包，project.json裏面的構建依賴和開發依賴也有近百個，每一個依賴包都有3級版本號，有時候更改一個最小的版本號都會致使構建失敗。不少包的做用我到最後也不清楚具體做用，有些究竟有沒有用我也不清楚。由於開發過程當中有棄用的代碼，然而它們的依賴卻留了下來。依賴包的遞歸依賴更是數不勝數。兩個包可能會依賴另一個包，但它們須要的版本號可能不一樣！雖然最後勉強完成了這個項目，但開發中的痛苦令我對前端敬而遠之。軟件工程的彼得定律在這裏也能夠充分體現。

The Rise of "Worse is Better"

壞便是好。這樣說其實有必定的誤導性，矯枉過正了，它只是相比較完美的設計來講的。「壞便是好」的哲學是：

• 簡易性
• 正確性
• 一致性
• 完整性

Unix和C語言的設計就是典型的例子。尤爲是Unix，有了設計完美但失敗的Multics的陪襯，壞便是好的成功也就更加明顯了。在計算機網絡中，TCP/IP的成功和ISO 7層模型的失敗也是這樣的例子。

「壞既是好」告訴咱們不要追求天衣無縫，而是強調簡易、正確、一致、完整的重要性。

Is Worse Really Better

這篇文章和上一篇文章的做者相同，都是Richard P. Gabriel。Gabriel在這篇文章中並非徹底否認了他以前的觀點，而是對以前的文章進行了反思，回答了一些外界關於「Worse is Better」的爭論，重申了壞便是好的4個哲學。

瀑布模型

最先學習瀑布模型是在「經濟管理」課上，在生產領域，將生產過程用瀑布模型安排是一種比較廣泛的作法。在軟件工程中，瀑布模型具體爲「"系統需求-->軟件需求-->分析-->程序設計-->編碼-->測試-->運行"。瀑布模型是一種比較傳統的模型，有它本身的缺點。針對這些缺點，軟件工程師們又提出了其它的一些模型，如大小瀑布模型。

咱們在實際開發中採用的就是瀑布模型。緣由在於它的簡單清晰，對於咱們的項目也已經足夠了。

敏捷

咱們團隊的開發流程十分敏捷。

Alpha版本快速作出一個可玩版本，既能夠知足用戶需求，觀察用戶反饋，又可讓團隊成員熟悉開發和團隊，爲beta階段的徹底重構打好基礎。
每日立會，控制在15分鐘，討論工做進度和明日安排。
常常結對編程甚至集體編程。

敏捷已死

做者做爲提出敏捷開發宣言（Manifesto of Agile Software Development）的核心成員之一，高調地宣稱敏捷已死，其其實是爲了讓敏捷從新恢復初心，即敏捷的核心價值觀：

• 我的和互動高於流程和工具
• 工做軟件高於理解文檔
• 客戶協做高於合同協商
• 變化響應高於計劃遵循
  因爲敏捷這個概念在軟件開發中愈來愈火，敏捷這個詞已經成爲一個商家的噱頭，甚至不少團隊爲了敏捷而敏捷。就像做者說的那樣這個濫用的詞已變得再也不有意義，由於它轉換成了一個品牌。一旦敏捷一詞變得毫無心義，開發人員就不能再認爲它是一個有價值的實踐。迴歸本質纔是如今敏捷的追隨者應該作的。敏捷已死，放棄「敏捷」這個詞，轉而堅持敏捷的核心價值觀，用另外的詞來表達這種價值，才能保護咱們的付出。

敏捷未死

這篇文章話糙理不糙，雖然充滿了許多「fucking", "sucks"等屏蔽詞彙，但做者勇敢地捍衛了他所推崇的敏捷開發，一條一條地反駁另外一篇批評敏捷的文章。

方法論

我以爲軟件工程的方法論對於軟件開發的發展是很重要的。但在實際項目中，團隊沒必要拘泥於具體的方法論，不然可能會陷入無休止的意識形態之爭；而是要具體項目、具體團隊，具體分析。