期末個人總結部落格—-（謝永青）

　　在寫這篇部落格之前，還是要感歎一下時光飛逝。不知不覺這一個學期已經結束了。

　　以前對軟體工程的概念完全是模糊的，平常自己寫了幾百行的代碼就已經思維混亂，一個工程怎麼進行？對測試的理解僅限於從main函數開始，F10到函數結尾。在技術層面，以前的代碼概念完全存在於迴圈,遞迴，怎麼把一個數變成另外一個數而已。開發是一個遙遠的名詞。經過了這一學期，不能說自己懂得了太多，在結項答辯的問卷上，對各個能力的自我評價填上能夠達到面試水平，還是誠惶誠恐。但是，起碼我感覺自己也有了一些改變。

　　首先，就是對於整個課程的看法。到現在，我還是堅持一個觀點，那就是同學們的技術水平離完成一個優秀的程式，差的有點遠。鄒欣老師強調“習而學”。對於大部分投入其中的同學來說，很多都是在跌跌撞撞，翻翻查查中進行的。對於沒興趣的同學，大多數也就是大個醬油吧。當然，如果把這個課放在大四，照樣會有很多同學仍然技術不行。所以，這個觀點只是我的一個感覺，並不是一個批評。我很感謝接觸到這麼多的大牛，接觸到自己沒接觸過的技術點。雖然只是淺嘗輒止，但是仍然拓展了眼界。課程的設計最棒的一點就是一定要讓同學們做出來東西，並且發布出去。程式員估計是世上最苦逼，又最懶的生物了。你不去逼它，它會處於睡眠狀態。讓我們做出一個能發布的東西，很好。這門課，最讓我頭疼的一點就是pairWork了。雖然我不知道以後這種隨機抽一個人一起編程的機率有多大。但是我可以說，起碼我這學期的pairWork沒有成功的，要麼是partner是個大牛，抱一下大腿，或者自己寫寫。很少有兩個人在一起編程的。究其原因，於我個人來說，是有推脫責任和偷懶的成分在裡面。大家想的都是讓對方寫最好了。一個有趣的事情是，在shine或者codingCook團隊裡，大家基本上都是在pairWork，效率比一個人要高的多。為什嗎？因為每天都有一個daily Scrum在趕著我們寫。每個人的責任都是明確的。你推脫不了的。我想，以後再pairWork的時候，能給我們一個責任分工或者說兩個人中選一個負責人，效果會好得多。

　　然後，對我的團隊合作經曆談談感想吧。我前期是在CodingCook團隊，後期轉隊到Shine團隊。首先，兩個隊的工作風格完全不同。在分隊的時候，大家就是靠著彼此的熟絡程度和性情來組隊的。因此，團隊成員的個人風格也比較相似，起碼，核心人物是這樣的。CodingCook的核心人物是PM郭立軒，說他是這個隊裡的唯一牛人應該沒人吐槽的。Shine團隊的大牛好幾個，但是因為各自有事，PM黃楊在推動著整個團隊的運作。從團隊的流程來看，Shine團隊的design做得很不錯了。CodingCook的design我個人在實現的時候，腦中總是一團迷霧，只有幾個介面，實現的功能只是簡單的架構。寫完之後，沒有一個明確的要求來檢測我的結果時候能夠“交貨”。當然，Shine團隊做的是一個遊戲，個人的任務分的比較明確。CodingCook做的只是一個大項目的組成部分，條件差太多。但是，差距仍然是存在的。第二就是PM的個人風格。我一直不認為PM應該是一個好脾氣的人。雖然郭立軒恰恰是這樣的人。他可以把所有人的代碼全部改一遍，然後自己幹85%的活，但是這失去了團隊的意義。雖然我認為是Shine團隊的工作量太大導致黃楊沒能包攬85%的活，但是PM要學會去push這個團隊。第三點，整個團隊的工作氛圍。總的來說，CodingCook得到工作量比較小，工作氛圍也比較輕鬆。所以我個人也偷了很多懶。Shine團隊工作量很大，我個人能力一般。所以整個開發期間，我個人感覺氣氛是比較緊張的。尤其到後期整個項目面臨“跳票”的處境，讓我感到有點沮喪。但是總體來講都還不錯。兩個團隊的成員工作我不做太多的評價，但是有一點讓我很困惑就是測試人員去哪兒了？兩個團隊都有測試人員的責任分配，但是我很少在代碼中見到他們留下的痕迹。兩位大牛PM在每天深夜默默調bug。

總之，我認為一個團隊能做到“各司其職”，這個團隊就很成功了。

　　其次，對軟體開發的感悟。首先，這門課讓我瞭解到，軟體開發是一個工程的含義。建築，需要圖紙，預案，資源準備，動工，檢收等等。軟體開發也一樣。由於課程的價值取向，我們採用敏捷開發。敏捷開發的一個結果就是文檔寫的太少。文檔絕對是個非常非常重要的東西。我現在努力培養我寫注釋的習慣。如果前期的設計文檔寫的更好，團隊的結果應該也更好。再者就是對於測試。我一直再做自己代碼的單元測試。在把自己的代碼“交貨”之前做好充分的測試應該是做dev的基本準則吧。做好單元測試會帶來很多方便。M1階段我在CodingCook團隊，寫出來的代碼應該是一個標準的a big ball of mud。後來我轉隊了。但是一直在聽PM說“我要改介面”。他們重新設計了介面和要求之後，應該開發的順暢的多了。在Shine團隊，M1的成果應該算是一個不錯的初級demo，不能說是大泥球。在M2階段，PM對團隊的任務也重新進行了分配，任務和要求明確之後，工作效率也好了很多。但是，由於對工作量的估計不足，最後導致發布延遲。應該是一個教訓。

　　總之，每個團隊在M2開始後，都會有一個任務重新分配的過程。個人感覺這個過程就是在彌補敏捷開發造成的design階段工作缺少帶來的後果。以前我總是認為大泥球的造成是因為大家技術不行，但是，結束這門課之後，我感覺不是這樣的。對於我們的項目，穀姐和度娘給出的資料足夠滿足我們的需求了。有效對項目進行劃分，進行各組成的銜接才是避免大泥球的關鍵。

　　一學期結束了，整理一下自己。代碼寫了1000行左右，看了很多部落格。閱讀了鄒老師布置的所有個人閱讀作業。沒有錯過daily Scrum。壓力有點大，但收穫也不小。另外，感謝兩位PM吧。很辛苦。