英文水準實在有限,閱讀十分困難.還好有有道和wiki.
《沒有銀彈：軟體工程的本質性與附屬性工作》是Brooks用來說明軟體開發沒有所謂的超級高效的方法，強調軟體的複雜性本質，Brooks預見到随着工具的改善，所謂的附加性問題會漸漸改善，這也是現在我們可以看見确實是有此方面的改善，各種各樣的開發工具，盡量在改善那些在開發過程中出現的附加性問題。同時Brooks認為本質性的困難是最難解的。看了下這個大叔寫的 人月神話 簡介 ，發現他人月中的關于人員和時間論述讓我有很深的感受,溝通是開發中非常重要的一環，開發人員變多的時候，不知道如何去和每個人進行有效的溝通，進度的控制也變得非常困難.銀彈存在文章中是說使用一些複用性比較好的元件,來改善軟體工程中的問題，我覺得這和面向對象思想有共通之處的，繼承和多态對代碼複用性提高,增強效率都有很好的作用。Ps：不知道當時Brooks寫出這篇文章是不是和陷入泥潭的OS/360有關…
大泥球這個部分讓我想到了學長的代碼，真的，在閱讀學長代碼的時候發現的種種bug找到了理論依據，由于他們實在再上一屆學長的代碼基礎上改的，有很多的功能隻是僞實作，導緻我們今年在接手的時候就是一個略顯雜亂的系統，我們一邊嘗試去猜他的意圖，一邊進行移植，造成了很大困擾。
我想我們團隊算是使用市集模式吧，每個人負責一個部分，通過溝通來确定各個版本的管理。
Lost in catb 這邊文章批評那種對程式代碼無腦拿來主義，大量備援，導緻程式品質下降。在我們的項目中，
我正是從事這種"複制粘貼"活動，把C#的代碼移植到JAVA上，有的地方我并不了解，但是同樣要盡量去保持和原來代碼的功能一緻，有的時候由于"泥球"的原因，還要适當增加，我同時在懷疑自己會不會是在往這個泥球上加泥……
瀑布模型是由W.W.Royce在1970年首次提出的軟體開發模型，在瀑布模型中，軟體開發被分為需求分析，設計，實作，測試 (确認)， 內建，和維護這樣的步驟依序進行。
瀑布模型的設計是根據軟體生存周期從上到下來進行設計的，但是缺乏一定的靈活性，或者說不夠靈活，這種開發方式雖然有點老，但是需求明确的時候依然算是一種有效的開發方法。