讀了老師布置的閱讀作業⋯⋯覺得自己英語水平真的是弱爆了
對一些文章的理解有待提高，說一下自己對幾篇相對理解比較深的文章的看法
managing the development of large software systems: concepts and techniques
這篇文章裡雖然並沒有提出瀑布模型這一概念，但其中的思想就是瀑布模型，瀑布模型的特點就是通過設計一系列階段順序來開始乙個專案，從系統需求分析開始直到產品發布和維護，每個階段都會產生迴圈反饋，因此，如果有資訊未被覆蓋或者發現了問題，那麼最好「返回」上乙個階段並進行適當的修改，專案開發程序從乙個階段「流動」到下乙個階段，這也是瀑布模型名稱的由來。
這種模型的優點顯而易見，可以對每個階段設定時間檢查點，而且每乙個階段都只需要對前後兩個階段負責，但是也有一些缺點，比如不會適應使用者需求的變化，就像我們第一次的個人專案，需求改了幾回，如果用瀑布模型，就必須從第乙個階段開始改，一直到軟體需求，需求分析，設計，編碼，測試，運維。
這兩篇閱讀材料都是在講大教堂與集市這兩種不同模式的利弊。大教堂模特點是源**在本模式是公開的，但在軟體的每個版本開發過程是由乙個專屬的團隊所控管的，而集市則正好相反，其源**在本模式也是公開的，不過卻是放在網際網路上供人檢視及開發。很明顯，集市更利於乙個專案的除錯，其開源的方式使得更多的人能夠加入到專案的開發並提供意見，而大教堂只能靠乙個專屬團隊來維護開發這個專案，感覺就像ios一樣。我們小組的專案應該是大教堂模式，在軟體的3.0版，我們團隊進行改進和維護。
在第二篇文章裡，作者給我們從另一方面敲響了警鐘，並不是乙個專案越是開源越好，這樣會使得很多良莠不齊的程式設計師混在一起進行開發，反而使專案變得膿包，是人們不禁懷念起那些大教堂模式下嚴謹優雅的專案來，就是說不要太高估農民修建市集的能力，但也不要像中世紀的教會，完全掌握著聖經的解釋權，辯證的尋找一種平衡才是關鍵。
big ball of mud
直譯「大泥球」，指雜亂無章、錯綜複雜、邋遢不堪、隨意拼貼的大堆**。我覺得這樣的**在現在隨處可見，自己就寫過不少「大泥球」，再比如我們團隊所開發的軟體裡可能也有很多。當然，我覺得在敏捷開發裡，尤其是我們這些水平不高的人在做專案時是不可避免的，因為缺少前期設計、應對需求變化過晚、應對架構變化過晚、碎片式增長這些因素都會導致這一問題，只有提高了自己的水平，才能真正把敏捷開發做到極致。
agile method – by martin fowler
敏捷開發強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的**編寫和團隊組織方法，也更注重作為軟體開發中人的作用。而極限程式設計作為敏捷開發方法的一種，它是一種全新的、生機勃勃的軟體開發方式。它的的出眾之處在於兼顧了質量的兩個方面，即滿足客戶期望的同時，降低缺陷的數量，同時這種方法顛覆了複雜性不斷增加的迴圈。
敏捷開發是我們團隊專案一開始就要確定的開發模式，比如我們每日的daily scrum，遇到問題在一起即使解決，這種溝通和反饋覺得都是敏捷開發的一種體現吧⋯⋯
閱讀作業2王熹篇
看了老師推薦的幾篇文章，對軟體工程的理解真是又加深了很多 感覺比移山之道深奧好多.但是隨之而來的疑惑也非常多，下面可能沒有一一枚舉，因為我認為其中的許多東西需要隔一段時間反覆閱讀就能理解，有新收穫。no silver bullet essence and accidents of software ...
閱讀作業2
看了老師推薦的幾篇文章，對軟體工程的理解真是又加深了很多 感覺比移山之道深奧好多.但是隨之而來的疑惑也非常多，下面可能沒有一一枚舉，因為我認為其中的許多東西需要隔一段時間反覆閱讀就能理解，有新收穫。no silver bullet essence and accidents of software ...
閱讀作業2
經過這幾周的開發，完成了個人專案 結隊專案，團隊專案也完成了一小部分。做了這些開發之後，除了自身能力的提高，我還有其他的一些收穫和感悟與大家一起分享。2.對於兩個人的開發，也即我們的結對程式設計。在這樣的組織方式中負責人貌似就顯得沒那麼重要了，只有兩個人的團隊，乙個負責人，那另乙個叫他什麼好呢？但是...