上了大學之后其實就沒有很多時間去讀書了，與其說軟工作業時給我們布置了一些任務，但是也是在另一方面讓我們得到了更多的知識的填補，因為平常能夠接觸的書籍很少，平常自己也是一個很不愛看書的人，所以我覺得這樣的作業對我來說還是有所收益，盡管很多東西要去斟酌閱讀，但是也好比呆呆的編程好得多啦。在閱讀這些內容的過程中也能逐漸明白書中看到的一句話，代碼首先是為了人而寫，并不是為了機器。
好了，那我來談談我的閱讀感受吧，當然我也會認真的面對自己的情況去面對這次作業。
A. 關于 — 銀彈
我的理解呢，如果沒有銀彈，那么就是意味著現在情況下，沒有任何一種技術還有方法可以使得軟件工程生產力可以在十年內等同的提高十倍。我認為軟件開發中困難的部分是規格化、設計和測試這些概念上的結構，而不是對概念進行表達和對實現逼真程度進行驗證。當然，我們還是會犯一些語法錯誤，但是和絕大多數系統中的概念錯誤相比，它們是微不足道的。如果這是事實，那么軟件開發總是非常困難的，天生就沒有銀彈。
其實在團隊分工的開始，我們確實是有了比較好的團隊分配，最后也基本達到了軟件當初的一些主要需求，但是在開發的過程中來說，沒有想象的那么容易，因為我們每個人都是在互相的摸索如何合作更默契，并且自己也是出于一個摸索軟件的過程中，我們不斷的在面臨問題，解決問題，達到最后要求。對于障礙這種問題，我們并不能期待出現銀彈為我們打平障礙一路暢通，就像是我們學習變成從面相過程到面相對象一樣，這一路的荊棘我們都是一路斬過走過，有過積累有過自己的學習，才能夠在程序設計或者學習的過程中更快的完成自己的目標，這些都是我們必須要去做的和經歷的。
所以對于項目本身而言，我們需要踏踏實實完成我們的工作，對于學習而言，我們應當穩扎穩打，著重基礎，沒有任何捷徑可走。
B — 大泥球問題
大泥球單從字面上去理解就可以提現到，混亂邋遢，事實上呢這也是象征了代碼的一種情況，代碼的前期的設計不完全，缺乏開發經驗以及技巧都是造成我們混亂邋遢有缺陷的一切原因，所以可以把大泥球發生的原因歸結為：一次性代碼，碎片式增長，為了讓軟件有正確性，Copy過程導致問題移植，缺少前期設計，應對需求變化過晚。在團隊項目中，我最近負責的部分很少，因為我最近一直也是在跑醫院，這也是屬于我們大泥球的一部分原因吧，因為團隊合作的缺陷也會導致很多不可避免的問題。
不過我相信團隊合作就應該是這樣，會有自己的任務，也會有自己的失誤，往往盡量減少自己IDE失誤會給團隊帶來最大的收益，這也是我自己本身所追求的，我也會盡力在之后的工作中完成我自己的這個愿景吧。但是文章里提到“大泥球”似乎仍然是最常見的軟件設計，很難避免。盡管涌現出各種鼓勵、促進良好結構代碼的開發方法，軟件技藝運動也在不斷成長，但是“大泥球”仍然是最常見的軟件設計，即使人們已經從過去惡劣的設計中學到了東西，但在新的開發過程中，大泥球仍未消失。
C —?CatB – Cathedral and the Bazaa
我們在開發項目的過程中，采用的是大教堂的開發模式，我們將所有源代碼都放到github上去，我們可以分享我們的代碼我們可以一起閱讀其他人寫的代碼。我覺得我們的項目現在是在不斷分配需求，然后實現任務的過程中前進的。但是我們缺少了很多的項目跟蹤，我自己也是這段期間參加項目比較少，可能也是跟我個人情況比較特殊一些吧。不過我們的項目也是在具體的需求上做到了基本的要求。
不論是市集模式還是大教堂模式，都有其優缺點所在（這在上文中已經可以看出），關鍵是找到其適用的場景。這個觀點雖然中庸，不過確實是實話。我以為，大教堂模式，適用于小的項目，或者是團隊中有一個技術大牛帶領，不需要過多的人來指點。而市集模式，則是那種涉及的方面比較廣泛的項目，且不論如何，應該有一個幾個人的團體對于項目的整體走向、代碼有絕對的控制力，否則，會造成Kamp所說的那種混亂局面。
我們當前的項目（學霸系統的UI之用戶管理部分），可以說是類似于大教堂模式。之所以說，類似，是我們的源碼并非在互聯網上公開的，只是相像而已。一來因為項目比較小，如果非要應用市集模式，可能會有意見無法統一，浪費資源的問題。
D — Worse is Better
我認為這個文章主要講的是簡單的暴力的往往可以壓制一切，我們通常都會追求簡單的設計，實現結果也要簡單，成就我們需求的簡單性。為了簡單性，正確性，一致性，完整性都會做出一些犧牲。有時候完整性和程序的一些絕對正確性會給程序帶來很大的結構復雜，并且因為復雜也會相對的付出一些代價。
E — 瀑布
嚴格把軟件項目的開發分隔成各個開發階段：需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等。
使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出，下一階段的工作就不展開。?
強調文檔，在開發的后期才會看到軟件的模樣。在這種情況下，文檔的重要性仿佛已經超過了代碼的重要性。
瀑布模型把開發人員定義為流水線上的工人。由于各階段的開發人員只能接觸到自己工作范圍內的東西，所以對客戶需求的理解程度高低不等。對于客戶需求變更，編碼人員會比設計人員更容易產生很強的抵觸情緒。
在每個開發階段都會有一些信息刻意的不讓其他開發階段的人員知道（本意是為了提到效率，但實際上有時候產生的是互相的理解偏差）。
瀑布模型產生的管理文檔(計劃書，進度表)等，能讓不太了解該項目的人也能看懂項目的進度情況（只有能看懂百分比就行），很適合向領導匯報用。所以管理人員比較喜歡瀑布模型，但是開發人員不喜歡，因為它束縛了開發人員的創造性。
既然叫做瀑布，就意味著不應該走回頭路。否則如果出現返工，付出的代價會很大。
軟件生命周期前期造成的Bug的影響比后期的大的多。
F — 敏捷開發
而軟件存在的意義就是與現實相適應。敏捷開發的核心即：符合現實的軟件。一個符合現實的軟件，才能夠可持續地與現實共同發展。一旦軟件與現實背離，軟件的生命周期也就到了結束的時候了。
現實的世界是動態變化的，人類造出來的東西，往往是落后于世界的變化的。如，地圖造出來之后，可能又多修了幾條路，幾個建筑；剛買了一款高配置的計算機，幾個月后，自己的機器配置又處于被甩的地位了……這些變化，人是被迫要去接受。因為這些東西屬于硬件，人在目前還無法輕易地改變硬件。
而與此不同的軟件，則是另外一種現象了。改變軟件的代價是相當低廉的。改變軟件，實際上只是改變硬盤上的磁性。改變軟件的容易性，帶來的結果是：?一、軟件開發者容易以自己的想象來決定軟件怎么做。?開發出一個無用的軟件，比起因為出錯而要毀掉待出售的10萬張地圖，比起因為工藝漏洞而要招回已經出售的計算機來講，代價太低廉了。?二、軟件更加具備符合現實的條件。?開發者讓軟件與現實相適應，所要付出的代價非常低廉，當然對于敏捷開發我們也會有一些相應的辦法：Scrum meeting 以及 個人學習團隊互助的編程。
在Scrum meeting 上 ：?每天都會進行scum meeting匯報，包括今天自己完成了什么任務，明天的計劃是什么。并生成每天的燃盡圖，顯示整體項目進度。這樣的做法可以監督每一個成員每天按時按量完成自己的任務，保證項目的整體進度。
在個人學習和團隊互助的編程過程中 ： 我們都會自己有階段性的學習，然后在學習之后我們會進行交流，分享不懂不會的地方最后進行一個匯總，交給編程能力或者對語言比較熟悉的同學對這些我們收集到的問題進行解答。
所以，敏捷開發的核心就是符合現實的軟件。為了造出符合現實的軟件，才有了進一步的價值觀及方法論。
G — 團隊項目
我們的團隊項目是"BUAAMOOC“，我負責的部分是PM和測試，但是我覺得我在個人的工作完成上十分不滿意，也是因為我前段時間的身體情況耽誤了太久，不過我希望在之后的團隊項目的工作中自己可以打起精神吧，不希望自己因為自己的不足而感到失落，我應該投入到團隊的合作中去發揮更大的力量才是我應該繼續要做的事情。
