盡量讓這篇總結照顧大局，但廢話太多也寫了八千多字。不像是總結啊喂！ _(:з」∠)_ 。
基本上按照老師給的結構來：【軟體工程實踐總結作業——個人作業】。
一、回望開學初對于軟體工程課程的想象，回望部落格開篇時對于這門課和這學期的期望
對比現在的我和開學初部落格開篇的課程目标和期待
實踐給我帶來的提升
學習和使用的新工具
學習和掌握的新語言、新平台
學習和掌握的新方法
其他的提升
二、寫下屬于自己的人月神話——項目實踐中的經驗總結+執行個體/例證結合的分析
PM方面
編碼方面
三、建議或者想說的話
對下一屆實踐的建議
對于開學初的自己
對于大一的自己
對于開學初的老師
四、對未來的期許
五、我們的團隊（爆照啦~）
對比現在的我和開學初部落格開篇的課程目标和期待。
看了看我的第一篇部落格 《軟體工程的實踐項目的自我目标》 ，拿幾條出來說：
第一條：能夠較快地做出提升自己生活品質的APP。這一點不太好說，但是肯定比以前快了。這一學期做項目學到了不少面向對象的知識。
第二條：寫的代碼有良好的擴充性和健壯性。良好算不上，但有一定的擴充性。自從了解了反射和泛型，感覺能在減少代碼量的同時增加适用的廣度。我不會告訴你，其實我是因為懶得寫重複的代碼才去學的這些知識 _(:з」∠)_
第三條：熟悉與多人合作的流程，任務的配置設定和代碼的規範化。看到這點，不得不提GitHub的團隊合作使用，使我收益頗豐。除此之外，從原來的不知道如何細分任務，提升到把一項任務分割到較小的粒度（當然，有時候還會有意識地防止粒度過小）。作為團隊PM，這方面肯定要訓練得比較多。此外，我去了解了Google的JAVA編碼規範以及Android特有的編碼規範，在此基礎上做出一份我們團隊編碼規範，為代碼的規範化邁出第一步。
不過對于項目的願景規劃，沒做好。其實我一開始隻想默默當個程式員的角色，開開心心地敲代碼和鑽研技術。然而當了PM，願景規劃就沒執行了。不過想想，做PM的好處就是，技術的成長對整體的提升不是線性的。在這種時候去提升其他方面對自身的成長更有幫助，這次擔任PM一職就為将來的提升打下了一定的基礎。
總結這門課程的實踐給我帶來的提升
Git工具和GitHub！！以前就了解到GitHub是個很好的平台，現在終于用上了！而且我感覺我已經離不開它了。
關于git工具，我一開始使用 <code>GitHub for Windows</code> ，想着 “這個是GitHub自己做的工具，使用起來應該很友善” 。後來發現其實也沒什麼，我本來就不太喜歡用這樣的圖形化工具。這個版本的圖形化用起來實在難受。不過它的指令行有一點不錯：可以切換指令行的工具。它預設使用PowerShell，但是我覺得不太好。後來覺得既然不使用它的GUI，還不如換成 <code>msysgit</code> （也就是 git for windows ）。
其實還有個原因，就是 <code>GitHub for Windows</code> 依賴于 <code>.net framework</code> ，導緻老師讓我在上機課上跟同學們分享Git和GitHub使用方式的時候，出現了尴尬的一幕：無法直接使用，要安裝.net framework，可是裝完電腦要重新開機，重新開機就被還原掉了。我在PPT裡沒有準備生成SSH的内容，又忘了這些步驟，不好意思現場查教程。其實這樣做是對同學們不負責，沒必要為了面子不去查。
部落格和Markdown。其實一開始讓我用部落格園，我是拒絕的，因為感覺CSDN更高大上。但不得不說，部落格園真的不錯，于是就決定以後都在這上面發部落格了。我對部落格文章的排版算是比較重視，因為如果内容的排版不行，看起來很難受。使用工具欄手工排版總感覺麻煩。現在好了，自從用了Markdown，再也不用擔心部落格排版的問題了~
WAMPSERVER。以前我就想搭建自己的伺服器，但是不知道怎麼搭建。直到這次我為了測試api而使用WAMPSERVER，才發現如果 <code>僅僅</code> 是想在Windows上建一個伺服器，竟然如此的簡單。這個收獲還是蠻大的，然而我在知道了這點之後，反而把我的阿裡雲伺服器改成Linux系統 _(:з」∠)_
花生殼。伺服器搭建完畢，如果再來個域名就更棒了。隻需8塊錢就能有自己的域名，簡直棒。每月有1G的流量可以用。雖然有時候會斷掉，但總比沒有強，畢竟隻花了8塊錢。
Google、賽風、Hosts。之是以這三者合在一起講，是因為它們都跟翻♂牆有關。我經常需要去Google搜尋技術相關的資訊，用百度查不到什麼特别有用的資訊，現在我基本抛棄百度搜尋了，主要搜尋引擎改為 必應搜尋 。不過讓我找到賽風和Hosts還是因為我要看Android的官方文檔，發現它們花了我不少功夫。期間試過使用VPN，也買了個便宜的。不舍得花太多錢買VPN，但便宜沒好貨，經常連不上，連上了也容易斷。後來就沒再用VPN了。
原型制作工具、流程圖制作工具。這兩種工具都是在需求分析的時候用的。
原型制作使用了線上的工具 墨刀 。功能一般，比較不錯的地方是能将每個頁面儲存為圖檔下載下傳下來，也可以生成原型的APK。
還有一款軟體：axure，但是由于我們組負責制作原型的同學用的是墨刀，我就隻用過一次這軟體。
流程圖制作使用了 Process On ，還可以。
在Android上開發用到的JAVA語言，在我之前做的 福大成績查詢 小玩具就稍微熟悉了一小部分，主要還是面向過程的做法（我現在都無法直視那些代碼，想着什麼時候去重構一下 _(:з」∠)_ ）。這次是學習了各種面向對象的知識。
除此之外，還接觸了新語言（PHP）。主要是看隊友學PHP時花了太多時間看視訊，還做練習，學了好幾天寫不出一個API。我特地花了兩個多小時時間大緻學了一遍PHP，寫個API給他參考。當然，由于用到的PHP知識不多，也沒什麼可驕傲的……（= =好吧，我承認對此我還是有點得意）
跟别人溝通的時候，如果意見不符，就去了解對方的基本假設，也就是對方的相關知識儲備。我在下面 人月神話 這部分舉了實際的例子。
細化目标。這應該是我從這門課中收獲最多的一點。僅僅有一個模糊的目标是不夠的，要通過一步步分解，将其轉化為一個個可行的小目标。我之前使用“從目前的情況來計劃未來”的方法，結果目标的粒度很大，而且仍然模糊。後來從《建構之法》中學到了Work Breakdown Structure，即從未來的目标倒推每一個時期應該完成哪些任務。并且從項目中實踐這一方法作為練習。從結果來看，效果很好。
心态上。
由于一開始表現還算不錯，得到了老師的關注。不過同時也感受到了巨大的壓力（是真的巨大壓力！差點哭出來那種！）。感覺自己“裝逼”裝得太過了，讓老師對我有過高的期望，與此同時又沒有能夠比對這份期望的實力。還記得那時整個人精神很差，受不了，就爬上床。躺在床上一步步剖析自己壓力的根本來源，讓自己重新找回了自信。這為我以後碰到類似壓力大的情況提供了解決方案。
不得不提的是，那天晚上找棟哥聊天，他說 “老師，看見的是 一個學生 3年之後、5年之後。而不是這個學生現在。” 我那些不必要的壓力就此消失，(づ￣ 3￣)づ感謝棟哥。
總之，盡最大努力去做好應該做的事。如果因為老師的期待，反而被壓力所困住，那就離他們的期待更遠啦。相信老師的眼光，也相信自己。
思想上。
由于我總是追求完美，是以做一件事情的時候總是花很多時間準備。比如說，寫一篇部落格的時候，如果覺得内容還不完善，我就不會把它發表出來。這顯然是不具備軟體工程思想的表現。
在助教範老師（部落格）不斷強調“疊代”後，我逐漸開始改變想法。“有點内容了就先發出來”，為此踏出的第一步是 項目耗時估計的方法 這篇部落格。很遺憾，我至今仍未對其進行疊代，我總是選擇去做其他事情。But，這仍然有好處。為何？因為我會經常想起我還有一篇未寫完的部落格，我不會讓他一直不完整下去。相較于為了等待完善最終不去完成，這種做法顯然好了很多。
很感謝範老師，讓“疊代”這個詞深深地印在我的腦海裡。
我在項目實踐中，主要擔任PM，是以經驗大多關于PM。
“一個優秀的PM，能把一個一般的團隊帶成優秀的團隊；一個糟糕的PM，能把一個優秀的團隊帶成糟糕的團隊。”
這不是我說的，但我能感受到。因為在Alpha版本的時候，身為PM的我，還算馬馬虎虎。我的程式設計經驗比其他三個都多（其實也就做了兩個小玩具：八數位遊戲和上面提到的成績查詢，在我的GitHub上可以找到）。并且我能意識到自己是個PM，要做好程式設計以外的事。隊友不懂得使用GitHub來進行團隊合作，我就寫篇 教程 供他們參考。開發過程比較順利，連快要考試的時候都照常開站立式會議。
而到了Beta版本的時候，我參與編碼的程度比Alpha版本多很多。漸漸地，站立式會議前的準備越來越少。有幾次是要開會了，我還在敲代碼，停不下來……沒有做好PM工作，對團隊有多大的負面影響呢？
會議的時間變得更長了。沒有清晰的議題，浪費時間；
項目的主要進度變慢。我居然同意讓一個隊員去做某個不是很重要的功能，而這個功能花了他将近兩天的時間；
對項目的把握程度降低了。我甚至不知道接下去該讓隊友幹嘛了！還要問隊友“你現在在做哪部分，接下去你要做什麼”。隊友有時候也不知道自己該幹嘛，這時沒有安排任務給他們，他們就放松下來了；
由上一條而導緻的，大家的積極性降低了。身為項目的上司者，不能給其他人指出一條明确的道路，簡直是糟糕。
如果這樣繼續下去，對于項目來說是很危險的。這個時候有個可行的做法，就是讓隊友盡可能指出目前項目還有哪些未完成的地方。然後帶着這些去把整個項目的代碼看一遍，可以重新把握住項目的進展。這點在 Beta團隊總結 裡也有提到。
一定要時刻提醒自己是PM，PM的本職工作不是編碼，要把本職工作做好，而不是過多的參與編碼。
PM做開發和測試之外的所有事情 —— 《建構之法》
那麼作為新手PM，具體要做好哪些事呢？
一定要做好需求分析！一定要做好需求分析！一定要做好需求分析！
重要的事情說三遍！
如何開發一款吸引人的軟體？自己覺得這款軟體很牛逼就行了嗎？這顯然是不夠的。無法滿足使用者的需求，沒有市場，就難以生存。
不要說人要有個性啊，也不要說一味滿足别人的需求是不正确的啊。你要想清楚你的目标是什麼。做出一款大家都喜歡且有實際用途的軟體，還是一款用來自娛自樂的軟體，甚至做完就扔掉的軟體？
我們的實際做法：
首先了解别人需要什麼，是最關鍵的。
在了解的過程中要做好記錄。可以用筆記錄，但是推薦在初期盡量使用錄音裝置。像我們團隊是做教師的報課系統，在教務處描述需求的時候，我們就錄音了。這對我們後來分析需求的時候很有幫助。因為當時做筆記也不是很清楚，還有客戶在描述的時候，前後會有沖突。如果不仔細琢磨，很容易誤解。
記錄下來之後就要去分析。
用思維導圖也好，畫程式的主要流程圖也好，盡量把客戶的需求描述轉換成圖，并且讓客戶能夠看懂。最好做個原型，并且做完後示範一遍給客戶看。其實軟體工程裡的做法是使用【用例圖】（即Use Case），不過當時沒有學到這個，就自己想了上面那兩種圖。
關于這部分的心得，我另外寫在一篇部落格上了：【軟體工程心得】與真實客戶交流
給團隊一條清晰的路線，至少短期内要清晰。這點在上面有提到了。團隊成員對該項目的信心，很大程度上取決于PM給的路線是否清晰。具體來說要做哪一些呢？
理清項目應該實作哪些功能，對這些功能分類。哪些功能是核心功能（那些能滿足使用者主要需求的功能）？哪些是看起來很重要，但不是核心的功能？哪些是可有可無的功能？要先把核心功能做完！要先把核心功能做完！要先把核心功能做完！Alpha版本的時候，我看我們班另外一組，在快到版本示範的時候，還在為一個不重要的搜尋功能止步不前！與此同時，他們核心功能并沒完成多少。我跟他們強調了幾遍，要先做核心功能。後來他們在Beta版本的時候，終于意識到了這點，進度立馬快了很多。而我們團隊呢？一開始我就篩選好了，并讓隊友做的基本都是最主要的功能。很經常發生的一幕就是，隊友跟我說“xxx很難完成”、“這個功能不錯”，我一想，不是主要功能，直接跟他們說不做。最可怕的是Alpha版本，被我砍了無數的功能……
理清功能是第一步。接下來就是細化它們。讓它們變成一個個小到讓人覺得可以完成的任務。什麼叫“覺得可以完成的任務”呢？就是知道去哪裡找相關知識，不用去查閱書籍教程多餘的部分。或者以他目前的知識，花點時間就能完成。當然，要做到這點，可能需要對所用到的程式設計語言有一定的了解。不過一開始可以不用細化到特别接近代碼實作。去看看《建構之法》的Work Breakdown Structure吧！
細化完任務，要到GitHub上釋出Issue。如果不發Issue，隊友可能會忘記要做什麼。在釋出Issue的時候，要大緻描述應該做哪些，盡管你可能在開會的時候就告訴他們了。但是在開會的時候，你告訴他們的是很詳細的資訊。在實際開發中，他們還是需要參考你給的Issue。不要寫太簡單太籠統，也不必太詳細。
對團隊合作有幫助的工具要多學。學好GitHub的團隊合作流程，能為團隊省掉不少時間。
既然是團隊合作，那麼交流的時候難免發生意見沖突的情況，這時PM要hold住全場。關于這方面，可以看《建構之法》第二版的4.6.1節。書上這些做法是很不錯的，但依我目前的極度缺乏的人生經驗，沒有體會到它們的精髓，這是實話。
我通過觀察發現：人與人之間在交流的時候出現沖突的一種原因，很可能是基本假設不同。這裡說的基本假設，指的是知識儲備，以及建立在知識儲備上的認識。
對此，我在跟隊友交流的時候，特意注意了這一點。舉個例子：有個登陸的操作，根據傳入的賬号和密碼，來判斷是否讓他登陸成功。你會怎麼做？
法一：先把這張表裡的所有使用者查詢出來。然後在查詢結果裡，使用for循環依次周遊所有行，在循環時取出某一行的資料跟傳入的賬号密碼相比較。如果都相等，則傳回登陸成功；如果周遊完之後還沒有相等，則傳回登陸失敗。
法二：在查詢資料庫的時候，使用where參數，把賬号密碼傳進去讓資料庫查詢，并傳回結果。如果結果行數大于0，則表示查詢到了，登陸成功。如果結果的行數不大于0，則表示沒有查詢到，登陸失敗。
對方選擇法一，認為法一更合适。理由是他看一個有開發經驗的同學這麼做，而我則是沒有相關的開發經驗。
而我選擇法二，因為我認為讓資料庫去查詢會比查詢全部然後周遊來得有效率。
通過上面兩段，可以看出，這兩者隻是在表面闡述了各自的想法。争論的時候情緒已經上來了。
後來我想着，在淺層知識相争是不行的。于是靜下心來問他：你是不是認為在資料庫查詢的時候，也是這樣一行一行周遊地查詢？他說是。這樣就找到問題的根源了，隻需要了解資料庫的查詢過程就能解決問題。
至于誰的方案更好，查找相關資料或者用實際驗證來說話就行了。這樣算是解決了争論上的問題了吧。
談談編碼方面。
當隊友會對某一檔案進行修改的時候，不要去重構這個檔案的代碼。我在編碼的時候經常手賤，看到隊友代碼寫得不夠好，就想去重構它。有時候是全局修改變量名。這樣也造成了許多沖突。還好我們團隊都使用Git來管理代碼，可以用合并工具來解決這些沖突。然而解決代碼沖突還是浪費了很多時間，是以最好還是不要随意做這樣的事情。如果想重構，隻在某一個方法裡重構。讓其對外的行為不變即可，盡量不要改變整個檔案的布局，特别是删除某個方法。
對下一屆實踐安排的建議：
要在項目開始前，讓PM去閱讀《建構之法》。
不要讓PM一開始就參與編碼，讓他好好學學項目管理。參與編碼很容易陷入細節而忘了大局。PM要以項目大局為重。
告訴所有同學，程式設計差沒關系，照樣能拿高分。
這是【軟體工程】實踐課！這是【軟體工程】實踐課！這是【軟體工程】實踐課！
不是【進階程式語言】實踐課！也不是【軟體開發】實踐課！
我發現很多同學都陷入程式設計中無法自拔，實際上學到的軟體工程知識不多。
對開學初的自己：
《建構之法》是本好書，它對你将要開始的項目很有指導意義。趁着還不忙，趕緊看兩遍壓壓驚。不要像我現在，還沒有好好地把它看一遍。
對大一的自己：
照着高中定好的大學規劃走就對了。雖然程式設計會差點，但是以目前的情況來看，總體還算不錯。
對棟哥：
我竟然到大三才成為你的學生！！！不過能遇到，總算是幸運。
對範老師：
存在感極強的助教233
你給的很多資料都很棒！請務必繼續帶我們了解計算機這個行業。雖然有時候會冷場，但是同學們其實都有認真看的。 😃
我希望未來的我，對計算機的研究要足夠深。
不能止步于了解如何使用，要了解其原理。
要做更多的創造，好好使用程式設計技能提高自己的生活效率。
寫一些高品質的部落格。
最上面那個就是我啦
（逃
本文采用知識共享署名 2.5 中國大陸許可協定進行許可。歡迎轉載，演繹或用于商業目的，但是必須保留本文的署名 schaepher（包含連結）。如您有任何疑問或者授權方面的協商，請給我留言。