又快到農曆的年根兒了，每到這個時候忙碌了一年的人們都會總結總結自己一年的經歷，清點清點一年的所得，像是對自己的犒勞，也像是對自己的盤問。學習軟體工程17周，課上課下也算是沒少忙，確實也是時候總結一下自己的所得和所失了。
總的來說，這一學期的繁忙程度遠遠超越了前面幾個學期，雖然前面幾個學期的每一次回望我也都會有這學期比上學期還要艱難的感覺。但是這回的壓力之大確實是客觀擺在這裡的，從開學伊始就投身戰鬥，一直到昨天剛提交了編譯原理的大作業，再到接下來的幾天裡還要為期末考核各種忙碌。忙確實是忙過了，也算是沒有虛度光陰，但是究竟得到了什麼，只怕還是要靜下心來細細點數一番了。之前的部落格位址點選這裡
part1：總結m1/m2：
軟體工程的「做中學」的教學思路是非常正確的，我也能偶爾聽得到接受傳統軟工教學模式薰陶的同學們在抱怨說什麼也學不到，而且從我的親身的實踐中我也能感受得到有些概念就是針對實踐中的情況提出來的，所以將經驗化的東西概念化往往會在接受上具有一定的抽象性，而這種抽象性是要通過實踐過程的重現才能理解概念自身的提出的原委和概念本身的適用性和侷限性。我們團隊中有兩位實驗班的學生他們的選課表中本來是沒有這門課的，但是為了感受真正的軟體工程的實踐環節，他們幾經「折騰」終於在自己課表上加上了這門課。於是我們的團隊一開始就抱著非常強的實戰的信念開始這個旅程。
在選題上我們選擇了往屆的題目，而且將往屆的**全部推倒重構了，於是在實踐上就相當於是乙個新的自選專案一樣。在m1階段我們面臨的問題是團隊與團隊之間的銜接的問題，在m1過程中我們顯然是過分陶醉於自己的開發之中沒有顧及團隊間的合作，導致最終銜接不到位，展示資料比較匱乏，效果不是非常好。而且在m1開發的階段我們對於團隊的整體的協調性不是很好，一些常見的甚至是低階的但是卻致命的錯誤都在我們的團隊上出現了，我們團隊曾經因為scrum meeting 事件一度將面臨崩潰，好在成員們臨危不亂團結一致，才沒有造成軍心渙散。
到了m2階段我們重視了團隊間的合作，甚至為了團隊間的更好的合作我們將前端的介面做了比較大的改動，但是無奈的是後期的各種大作業紛至沓來，時間成為了最致命的問題，原本設計好的計畫沒有很好被完成。也搞得自己很崩潰。但是在這個過程中我們非常重視組建的合作，原本的m1階段搞不定的合作問題，都通過統一的介面使得整體上可以完成資料的正常流動了。
part2
在前面的作業中我說對於測試部分不是非常的理解，其實乙個重要的原因是自己以前所寫的**過於簡短了，沒有真正的可以達到工程的級別，這學期我們有資料庫的大作業，編譯的大作業，軟體工程的大作業，這幾個大作業每個都是數千行**的級別，可以算得上是小小的工程了。在這個過程中我是真的充分感受到額（了）測試的重要性，我在寫編譯原理的大作業的時候往往會被某乙個bug困擾一整天，到最後才發現居然不是演算法的問題也不是邏輯的問題，而是非常邊邊角角的低階錯誤，這種錯誤只要稍作測試就會被發現，但是當它整合到數千行**裡面再做整體的測試時簡直是要了命了，一天天被整得「嗚呼哀哉」。真的就像哥倫比亞號飛船的發射失敗起源於乙個運算溢位那樣的無奈和細微。可見測試不是浪費時間而是保證後向的無憂。
再者就是對於市場模式的理解我還是不太懂，但是我知道的是軟體開發面向的是使用者，這一點我在開發的過程中和在課堂上以及在和小夥伴們的討論中有著非常深的感受，我們需要從需求到實現逐步求精迭代迴圈，以使用者的反饋和需求作為調整的策略。這一點我想我是不會忘的，也算是和市場相關的理解吧。
對於開源的問題也有了深一步的理解，在軟工實踐的過程中我們使用github作為託管，在使用github之餘，我也會看到有很多的專案在github上，我們可以將專案fork下來然後在其基礎上進行自己的修改甚至成為專案的contributer的一員。這個也許就是開源最直接的表現了吧，**透明，人人皆可參與。毫無疑問這種模式不僅可以加速軟體週期還可以有效提高**的健壯性。但是受到快播案的審判的提醒，縱然是分享精神不死，開源精神不滅，其他人的勞動成果的合法性是否可以獲得保護、如何獲得保護、憑什麼獲得保護，這些問題不得不提，不得不思考。所以其實現階段對於開源的利弊的評估我是不太清楚的，角度太多，情況太複雜，這算是乙個新的問題吧。
第一次讀到大泥球的定義的時候倍感新奇，感覺形象而生動，好像又學到了乙個有意思的稱謂，但是到了後來alpha階段的**統計和總結的時候我們發現原來我們的**好多的部分就是泥球啊，甚至直到m2的開發階段還是不斷在與泥球作鬥爭，所以泥球成為了通過閱讀軟體工程**留下的印象最深的詞了。
同時對於敏捷開發裡面的兩個特徵也是印象深刻：適應性而非**性、以人為本。這兩個特徵也在我們的團隊上體現得非常好，也是對於敏捷開發過程貼切的概括。在這個過程中我對於教堂式開發和集市式開發有了新的理解。一開始我認為我們的專案是教堂式的，因為只有團隊內部的人員在維護沒有團隊之外的人可以參與進來，整個的開發是相對封閉的，但是在團隊的某位大神指教之後我發現我們的團隊用集市式開發來定義也不算錯，雖然我們對外是教堂式的，但是對內確實是集市式的，因為我們的每乙個人都了解其他人在做什麼，都能參與其他人的工作，可以協助完成開發，這樣來看不就又是集市式的開發嗎，人無固定的定位和一成不變的分工，憑靠興趣和任務機動安排參與到或前端或後端的開發中，所以儘管在這個過程中學習成本高昂，但大家在這個過程中學到了很多。集市和教堂式的開發模式算是我新的理解和體會了。
需求分析階段：我們使用問卷星進行了幾乎是全球範圍內的調查。所以得到了非常真實的資料結果，而且通過平台自帶的統計功能使得資料可視而直觀，所以問卷星這個工具算是在需求分析階段掌握的「知識點」了。
設計階段：在m1設計階段我們通過組內一套基於apache的框架搭建了完整的資料抓取利用的架構，在m2階段我們利用solr工具以及json的資料傳輸組織形式開始了組間的合作開發。
實現階段：我們採用「結對程式設計」的兩兩監督開發的模式提高了生產力。
測試階段：作為開發人員一定要在開發的過程中將單元測試及時做好，並且同時留下測試的記錄文件。最後才想起來做這個顯然是費力不討好的，而且是沒有意義的。
發布階段：在發布階段要做好宣傳工作，針對目標群體結合需求分析階段定向宣傳。
維護階段：實時注重使用者數目的變化以及使用者反饋中可能出現的bug以及功能上的建議，這就要求在實現時注意融合入反饋機制，以及利用敏捷開發的手段進行逐步的迭代求精。
最後要說的是乙個團隊跌跌撞撞、一群少年哭哭笑笑，在軟體工程的歷程中漸漸成長。為老師為隊友為助教為所有關注這門課的人們獻上溫情與敬意，謝謝。
又到專案尾聲時
看到這個名字，好像顯得有些無奈，又好像有很多話要說又說不出來。國內的軟體公司也跟著潮流，逐漸地引入了專案管理制度，但是卻並沒達到理想的狀況。專案預算失控，週期失控，規模失控，風險失控，人員失控等等等等。似乎很多東西到了中國都會走樣，倒不是因為國人太笨，反而是因為大家都太聰明，聰明得以為自己可以控制一...
又到一年總結時
又到了一年總結的時候，今年工作和生活上再次出現了一些變化，對於個人或許可以套用乙個蘋果的廣告詞 年年煥新 十一月的時候，秘密地開始了求婚計畫，在不斷對她進行日期迷惑外加誤導後，十二月的時候，成功的避開了女孩子的小心思，給了她乙個完整的驚喜。我們的未來應該不會更遙遠了。在技術上補全了一些sre相關的能...
又到一年總結時
又到了一年總結的時候，今年工作和生活上再次出現了一些變化，對於個人或許可以套用乙個蘋果的廣告詞 年年煥新 十一月的時候，秘密地開始了求婚計畫，在不斷對她進行日期迷惑外加誤導後，十二月的時候，成功的避開了女孩子的小心思，給了她乙個完整的驚喜。我們的未來應該不會更遙遠了。在技術上補全了一些sre相關的能...