個人閱讀作業+總結

助教推薦的那些文章都是軟件工程上的經典文章，閱讀後感受到軟件工程本身的深度，之前學習的軟件工程都只是皮毛之中的皮毛而已。隨著軟件規模的越來越龐大，軟件工程已經成為了軟件開發中的必備知識。在軟件工程中有很多前人的思考和經歷在其中，細細品讀下來還是十分有趣、有用的。

No Silver Bullet - Essence and Accidents of Software Engineering - Brooks

鏈接

所有的軟件在構建過程中都會遇到根本性的任務：組成抽象軟件實體的復雜概念，防不勝防的意外以及在一定的時間和空間限制下，從抽象的軟件概念到具體的編程語言乃至機器語言的編碼過程。作者提到幾乎大部分高效的軟件生產性的獲得需要人為的想一些方法將意外的任務盡可能減少。他將軟件比喻成西方神話中可怕的狼人，將一勞永逸的解決方案比喻成為唯一對狼人有效的銀彈，並在文中敘述軟件工程中並沒有這樣的一個“銀彈”，能讓人高效管理軟件工程而不出半點差錯。但他也提出了一些方法，雖然不能達到“銀彈”的級別，但多多少少對軟件的管理有較大的幫助：

• 積極探索巨大的市場以避免重新制造可以買到的輪子；
• 將快速的原型作為叠代計劃中的一部分來滿足軟件的要求；
• 增量開發，對於軟件的新功能、測試等等需求做增量開發，向系統中添加新的過程和函數。
• 物盡其用，善用人才。

big ball of mud

鏈接

雖然高度關註高級軟件架構模式，但事實上標準的軟件架構實際上很少被討論。一個大球泥是一個隨便的，即使是隨意的，結構化的系統。在實際開發中，我們往往為了追求更多的功能不加設計的添加代碼使得軟件整個結構越來越臃腫最終導致成為一個完美的大泥球，使得在上面開發或者維護的成本極其高，任誰也不想也不能在上面進行有效的開發。

• 大教堂模型中，每個軟件版本都提供了源代碼，但在兩個發行版之間開發的代碼僅限於一組獨立的軟件開發人員。以GNU Emacs和GCC為例。
• 集市模型，在該代碼開發了互聯網鑒於公眾。Raymond 稱Linux內核項目的領導者Linus Torvalds是這個過程的發明者。雷蒙德還提供了他自己實現這個模型的Fetchmail項目的傳聞。

在我們的開發中，目前使用的開發過程更合適的模型描述是大教堂模型。開發軟件過程中並沒有使用互聯網進行“集市”一般的開發，一般都是自己或者幾個人固定進行開發。

Worse?Better?

有了正確的事情，設計師同樣關心簡單性，正確性，一致性和完整性。隨著越來越好，設計人員幾乎完全關註實現的簡單性和性能，並且只在正確性，一致性和完整性方面工作，只是為了完成工作，為了簡單起見而犧牲了其他任何品質。然而，這個論點是，使用越差越好的程序設計和實現的程序可以比正確的版本更快地寫出來，可以運行在更廣泛的計算機上，容易攜帶，如果足夠好，將被接受得更快，最終將得到改善，並且一般來說，比右派方案表現出更好的生存特征。更糟糕的是程序就像病毒一樣迅速傳播，很快普及。隨著時間的推移，如果他們成功了，
他們會得到改善。

具體來想我認為作者提出的更加糟糕的軟件指的就是軟件首先不論質量怎樣需要盡可能快速的實現需求並發布，並進行快速的叠代更新以達到最後的好的質量。這樣可以在市場上占有先機更容易獲得成功。而正確的就進入市場晚可能獲取成功需要的努力就更大。

敏捷！

• 敏捷方法是適應性的而不是預測性的。 工程方法傾向於在很長一段時間內詳細規劃軟件過程的大部分內容，直到事情發生變化，這種方法運行良好。 所以他們的本性就是抵制變化。 敏捷方法，但是，歡迎改變。 他們試圖成為適應和改變的過程，甚至改變自己。
• 敏捷方法是以人為本而不是以過程為導向的。 工程方法的目標是定義一個恰當地使用它的流程。 敏捷方法斷言，沒有一個過程能夠彌補開發團隊的技能，所以一個過程的作用是支持開發團隊的工作。

我們在實際開發過程中其實使用到了敏捷的一些思想，比如快速叠代，在每一輪叠代之間收集用戶反饋以達到一個方向的修正；是事情驅動的，剛開始做完初步的設計後隨著事情的變化快速修改設計並再開發。

個人閱讀&個人總結