軟工實踐課程總結

盡量讓這篇總結照顧大局，但廢話太多也寫了八千多字。不像是總結啊喂！ _(:з」∠)_ 。
基本上按照老師給的結構來：【軟件工程實踐總結作業——個人作業】。

一、回望開學初對于軟件工程課程的想象，回望博客開篇時對于這門課和這學期的期望
- 對比現在的我和開學初博客開篇的課程目標和期待
- 實踐給我帶來的提升
二、寫下屬于自己的人月神話——項目實踐中的經驗總結+實例/例證結合的分析
- PM方面
- 編碼方面
三、建議或者想說的話
四、對未來的期許
五、我們的團隊（爆照啦~）

一、回望開學初對于軟件工程課程的想象，回望博客開篇時對于這門課和這學期的期望

對比現在的我和開學初博客開篇的課程目標和期待。

看了看我的第一篇博客《軟件工程的實踐項目的自我目標》，拿幾條出來說：

第一條：能夠較快地做出提升自己生活質量的APP。這一點不太好說，但是肯定比以前快了。這一學期做項目學到了不少面向對象的知識。

第二條：寫的代碼有良好的擴展性和健壯性。良好算不上，但有一定的擴展性。自從了解了反射和泛型，感覺能在減少代碼量的同時增加適用的廣度。我不會告訴你，其實我是因為懶得寫重復的代碼才去學的這些知識 _(:з」∠)_

第三條：熟悉與多人合作的流程，任務的分配和代碼的規范化。看到這點，不得不提GitHub的團隊合作使用，使我收益頗豐。除此之外，從原來的不知道如何細分任務，提升到把一項任務分割到較小的粒度（當然，有時候還會有意識地防止粒度過小）。作為團隊PM，這方面肯定要訓練得比較多。此外，我去了解了Google的JAVA編碼規范以及Android特有的編碼規范，在此基礎上做出一份我們團隊編碼規范，為代碼的規范化邁出第一步。

不過對于項目的愿景規劃，沒做好。其實我一開始只想默默當個程序員的角色，開開心心地敲代碼和鉆研技術。然而當了PM，愿景規劃就沒執行了。不過想想，做PM的好處就是，技術的成長對整體的提升不是線性的。在這種時候去提升其他方面對自身的成長更有幫助，這次擔任PM一職就為將來的提升打下了一定的基礎。
總結這門課程的實踐給我帶來的提升
- 學習和使用的新工具
  
  Git工具和GitHub！！以前就了解到GitHub是個很好的平臺，現在終于用上了！而且我感覺我已經離不開它了。
  關于git工具，我一開始使用 GitHub for Windows ，想著 “這個是GitHub自己做的工具，使用起來應該很方便” 。后來發現其實也沒什么，我本來就不太喜歡用這樣的圖形化工具。這個版本的圖形化用起來實在難受。不過它的命令行有一點不錯：可以切換命令行的工具。它默認使用PowerShell，但是我覺得不太好。后來覺得既然不使用它的GUI，還不如換成 msysgit （也就是 git for windows ）。
  其實還有個原因，就是 GitHub for Windows 依賴于 .net framework ，導致老師讓我在上機課上跟同學們分享Git和GitHub使用方式的時候，出現了尷尬的一幕：無法直接使用，要安裝.net framework，可是裝完電腦要重啟，重啟就被還原掉了。我在PPT里沒有準備生成SSH的內容，又忘了這些步驟，不好意思現場查教程。其實這樣做是對同學們不負責，沒必要為了面子不去查。
  
  博客和Markdown。其實一開始讓我用博客園，我是拒絕的，因為感覺CSDN更高大上。但不得不說，博客園真的不錯，于是就決定以后都在這上面發博客了。我對博客文章的排版算是比較重視，因為如果內容的排版不行，看起來很難受。使用工具欄手工排版總感覺麻煩。現在好了，自從用了Markdown，再也不用擔心博客排版的問題了~
  
  WAMPSERVER。以前我就想搭建自己的服務器，但是不知道怎么搭建。直到這次我為了測試api而使用WAMPSERVER，才發現如果 僅僅 是想在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知識不多，也沒什么可驕傲的……（= =好吧，我承認對此我還是有點得意）
- 學習和掌握的新方法
  1. 跟別人溝通的時候，如果意見不符，就去了解對方的基本假設，也就是對方的相關知識儲備。我在下面人月神話這部分舉了實際的例子。
  2. 細化目標。這應該是我從這門課中收獲最多的一點。僅僅有一個模糊的目標是不夠的，要通過一步步分解，將其轉化為一個個可行的小目標。我之前使用“從目前的情況來計劃未來”的方法，結果目標的粒度很大，而且仍然模糊。后來從《構建之法》中學到了Work Breakdown Structure，即從未來的目標倒推每一個時期應該完成哪些任務。并且從項目中實踐這一方法作為練習。從結果來看，效果很好。
- 其他的提升
  
  心態上。
  由于一開始表現還算不錯，得到了老師的關注。不過同時也感受到了巨大的壓力（是真的巨大壓力！差點哭出來那種！）。感覺自己“裝逼”裝得太過了，讓老師對我有過高的期望，與此同時又沒有能夠匹配這份期望的實力。還記得那時整個人精神很差，受不了，就爬上床。躺在床上一步步剖析自己壓力的根本來源，讓自己重新找回了自信。這為我以后碰到類似壓力大的情況提供了解決方案。
  不得不提的是，那天晚上找棟哥聊天，他說 “老師，看見的是一個學生 3年之后、5年之后。而不是這個學生現在。” 我那些不必要的壓力就此消失，(づ￣ 3￣)づ感謝棟哥。
  總之，盡最大努力去做好應該做的事。如果因為老師的期待，反而被壓力所困住，那就離他們的期待更遠啦。相信老師的眼光，也相信自己。
  
  思想上。
  由于我總是追求完美，所以做一件事情的時候總是花很多時間準備。比如說，寫一篇博客的時候，如果覺得內容還不完善，我就不會把它發表出來。這顯然是不具備軟件工程思想的表現。
  在助教范老師（博客）不斷強調“迭代”后，我逐漸開始改變想法。“有點內容了就先發出來”，為此踏出的第一步是項目耗時估計的方法這篇博客。很遺憾，我至今仍未對其進行迭代，我總是選擇去做其他事情。But，這仍然有好處。為何？因為我會經常想起我還有一篇未寫完的博客，我不會讓他一直不完整下去。相較于為了等待完善最終不去完成，這種做法顯然好了很多。
  很感謝范老師，讓“迭代”這個詞深深地印在我的腦海里。

二、寫下屬于自己的人月神話——項目實踐中的經驗總結+實例/例證結合的分析

我在項目實踐中，主要擔任PM，因此經驗大多關于PM。

“一個優秀的PM，能把一個一般的團隊帶成優秀的團隊；一個糟糕的PM，能把一個優秀的團隊帶成糟糕的團隊。”
這不是我說的，但我能感受到。因為在Alpha版本的時候，身為PM的我，還算馬馬虎虎。我的編程經驗比其他三個都多（其實也就做了兩個小玩具：八數碼游戲和上面提到的成績查詢，在我的GitHub上可以找到）。并且我能意識到自己是個PM，要做好編程以外的事。隊友不懂得使用GitHub來進行團隊合作，我就寫篇教程供他們參考。開發過程比較順利，連快要考試的時候都照常開站立式會議。
而到了Beta版本的時候，我參與編碼的程度比Alpha版本多很多。漸漸地，站立式會議前的準備越來越少。有幾次是要開會了，我還在敲代碼，停不下來……沒有做好PM工作，對團隊有多大的負面影響呢？
1. 會議的時間變得更長了。沒有清晰的議題，浪費時間；
2. 項目的主要進度變慢。我居然同意讓一個隊員去做某個不是很重要的功能，而這個功能花了他將近兩天的時間；
3. 對項目的把握程度降低了。我甚至不知道接下去該讓隊友干嘛了！還要問隊友“你現在在做哪部分，接下去你要做什么”。隊友有時候也不知道自己該干嘛，這時沒有安排任務給他們，他們就放松下來了；
4. 由上一條而導致的，大家的積極性降低了。身為項目的領導者，不能給其他人指出一條明確的道路，簡直是糟糕。
如果這樣繼續下去，對于項目來說是很危險的。這個時候有個可行的做法，就是讓隊友盡可能指出當前項目還有哪些未完成的地方。然后帶著這些去把整個項目的代碼看一遍，可以重新把握住項目的進展。這點在 Beta團隊總結里也有提到。

一定要時刻提醒自己是PM，PM的本職工作不是編碼，要把本職工作做好，而不是過多的參與編碼。

PM做開發和測試之外的所有事情 —— 《構建之法》

那么作為新手PM，具體要做好哪些事呢？
1. 一定要做好需求分析！一定要做好需求分析！一定要做好需求分析！
  
  重要的事情說三遍！
  
  如何開發一款吸引人的軟件？自己覺得這款軟件很牛逼就行了嗎？這顯然是不夠的。無法滿足用戶的需求，沒有市場，就難以生存。
  
  不要說人要有個性啊，也不要說一味滿足別人的需求是不正確的啊。你要想清楚你的目標是什么。做出一款大家都喜歡且有實際用途的軟件，還是一款用來自娛自樂的軟件，甚至做完就扔掉的軟件？
  
  我們的實際做法：
  首先了解別人需要什么，是最關鍵的。
  在了解的過程中要做好記錄。可以用筆記錄，但是推薦在初期盡量使用錄音設備。像我們團隊是做教師的報課系統，在教務處描述需求的時候，我們就錄音了。這對我們后來分析需求的時候很有幫助。因為當時做筆記也不是很清楚，還有客戶在描述的時候，前后會有矛盾。如果不仔細琢磨，很容易誤解。
  記錄下來之后就要去分析。
  用思維導圖也好，畫程序的主要流程圖也好，盡量把客戶的需求描述轉換成圖，并且讓客戶能夠看懂。最好做個原型，并且做完后演示一遍給客戶看。其實軟件工程里的做法是使用【用例圖】（即Use Case），不過當時沒有學到這個，就自己想了上面那兩種圖。
  關于這部分的心得，我另外寫在一篇博客上了：【軟件工程心得】與真實客戶交流
2. 給團隊一條清晰的路線，至少短期內要清晰。這點在上面有提到了。團隊成員對該項目的信心，很大程度上取決于PM給的路線是否清晰。具體來說要做哪一些呢？
  - 理清項目應該實現哪些功能，對這些功能分類。哪些功能是核心功能（那些能滿足用戶主要需求的功能）？哪些是看起來很重要，但不是核心的功能？哪些是可有可無的功能？要先把核心功能做完！要先把核心功能做完！要先把核心功能做完！Alpha版本的時候，我看我們班另外一組，在快到版本演示的時候，還在為一個不重要的搜索功能止步不前！與此同時，他們核心功能并沒完成多少。我跟他們強調了幾遍，要先做核心功能。后來他們在Beta版本的時候，終于意識到了這點，進度立馬快了很多。而我們團隊呢？一開始我就篩選好了，并讓隊友做的基本都是最主要的功能。很經常發生的一幕就是，隊友跟我說“xxx很難完成”、“這個功能不錯”，我一想，不是主要功能，直接跟他們說不做。最可怕的是Alpha版本，被我砍了無數的功能……
  - 理清功能是第一步。接下來就是細化它們。讓它們變成一個個小到讓人覺得可以完成的任務。什么叫“覺得可以完成的任務”呢？就是知道去哪里找相關知識，不用去查閱書籍教程多余的部分。或者以他當前的知識，花點時間就能完成。當然，要做到這點，可能需要對所用到的編程語言有一定的了解。不過一開始可以不用細化到特別接近代碼實現。去看看《構建之法》的Work Breakdown Structure吧！
  - 細化完任務，要到GitHub上發布Issue。如果不發Issue，隊友可能會忘記要做什么。在發布Issue的時候，要大致描述應該做哪些，盡管你可能在開會的時候就告訴他們了。但是在開會的時候，你告訴他們的是很詳細的信息。在實際開發中，他們還是需要參考你給的Issue。不要寫太簡單太籠統，也不必太詳細。
3. 對團隊合作有幫助的工具要多學。學好GitHub的團隊合作流程，能為團隊省掉不少時間。
4. 既然是團隊合作，那么交流的時候難免發生意見沖突的情況，這時PM要hold住全場。關于這方面，可以看《構建之法》第二版的4.6.1節。書上這些做法是很不錯的，但依我目前的極度缺乏的人生經驗，沒有體會到它們的精髓，這是實話。
  
  我通過觀察發現：人與人之間在交流的時候出現沖突的一種原因，很可能是基本假設不同。這里說的基本假設，指的是知識儲備，以及建立在知識儲備上的認識。
  對此，我在跟隊友交流的時候，特意注意了這一點。舉個例子：有個登陸的操作，根據傳入的賬號和密碼，來判斷是否讓他登陸成功。你會怎么做？
  
  法一：先把這張表里的所有用戶查詢出來。然后在查詢結果里，使用for循環依次遍歷所有行，在循環時取出某一行的數據跟傳入的賬號密碼相比較。如果都相等，則返回登陸成功；如果遍歷完之后還沒有相等，則返回登陸失敗。
  
  法二：在查詢數據庫的時候，使用where參數，把賬號密碼傳進去讓數據庫查詢，并返回結果。如果結果行數大于0，則表示查詢到了，登陸成功。如果結果的行數不大于0，則表示沒有查詢到，登陸失敗。
  
  對方選擇法一，認為法一更合適。理由是他看一個有開發經驗的同學這么做，而我則是沒有相關的開發經驗。
  
  而我選擇法二，因為我認為讓數據庫去查詢會比查詢全部然后遍歷來得有效率。
  
  通過上面兩段，可以看出，這兩者只是在表面闡述了各自的想法。爭論的時候情緒已經上來了。
  
  后來我想著，在淺層知識相爭是不行的。于是靜下心來問他：你是不是認為在數據庫查詢的時候，也是這樣一行一行遍歷地查詢？他說是。這樣就找到問題的根源了，只需要了解數據庫的查詢過程就能解決問題。
  
  至于誰的方案更好，查找相關資料或者用實際驗證來說話就行了。這樣算是解決了爭論上的問題了吧。

談談編碼方面。
1. 當隊友會對某一文件進行修改的時候，不要去重構這個文件的代碼。我在編碼的時候經常手賤，看到隊友代碼寫得不夠好，就想去重構它。有時候是全局修改變量名。這樣也造成了許多沖突。還好我們團隊都使用Git來管理代碼，可以用合并工具來解決這些沖突。然而解決代碼沖突還是浪費了很多時間，所以最好還是不要隨意做這樣的事情。如果想重構，只在某一個方法里重構。讓其對外的行為不變即可，盡量不要改變整個文件的布局，特別是刪除某個方法。

三、建議或者想說的話

對下一屆實踐安排的建議：
要在項目開始前，讓PM去閱讀《構建之法》。
不要讓PM一開始就參與編碼，讓他好好學學項目管理。參與編碼很容易陷入細節而忘了大局。PM要以項目大局為重。
告訴所有同學，編程差沒關系，照樣能拿高分。
這是【軟件工程】實踐課！這是【軟件工程】實踐課！這是【軟件工程】實踐課！
不是【高級程序語言】實踐課！也不是【軟件開發】實踐課！
我發現很多同學都陷入編程中無法自拔，實際上學到的軟件工程知識不多。