上了大學之後其實就沒有很多時間去讀書了，與其說軟工作業時給我們布置了一些任務，但是也是在另一方面讓我們得到了更多的知識的填補，因為平常能夠接觸的書籍很少，平常自己也是一個很不愛看書的人，是以我覺得這樣的作業對我來說還是有所收益，盡管很多東西要去斟酌閱讀，但是也好比呆呆的程式設計好得多啦。在閱讀這些内容的過程中也能逐漸明白書中看到的一句話，代碼首先是為了人而寫，并不是為了機器。
好了，那我來談談我的閱讀感受吧，當然我也會認真的面對自己的情況去面對這次作業。
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和測試，但是我覺得我在個人的工作完成上十分不滿意，也是因為我前段時間的身體情況耽誤了太久，不過我希望在之後的團隊項目的工作中自己可以打起精神吧，不希望自己因為自己的不足而感到失落，我應該投入到團隊的合作中去發揮更大的力量才是我應該繼續要做的事情。