個人總結
一、alpha 過程的總結
- 我們團隊做的項目是個人學習計劃提醒系統，在項目的Alpha階段，我們團隊完成了此項目的基本功能（主要有課程安排，導入提醒事項，登入注冊界面等），我主要負責前端設計功能子產品。以下是個人總結：
- 1.個人能力方面：在這個項目中第一次接觸到前端程式設計這一塊的内容，第一次使用html來進行對界面設計功能的實作。剛剛接觸的時候真的什麼都不懂，但是我們是一個團隊，當組長給到我們任務的時候，我們就必須要盡力想辦法來把任務完成。在這個不斷逼自己一把的過程中，讓自己快速地對前端程式設計有一定的掌握和了解。
- 2.團隊合作方面：溝通是第一要義。通過有效的溝通能夠極大地提高辦事效率。比如：在前端模型初次設計的時候，沒有與小組其他成員進行有效的溝通，當我們把自己認為很好的前端原型設計給大家看的時候，卻模型在實作以及功能上面有不足以及實作上有一定的困難。在第二次的正式原型設計的時候我們就加強了溝通，使得最後出來一個令大家都相對滿意的設計。
- 3.任務完成方面：上面是橫向地說明了與人溝通對提高效率的重要性，縱向與自己比較，深刻地體會到在團隊任務的一開始對自己的任務有一個提綱挈領式的規劃有多麼重要。在alpha沖刺的過程當中，不止一次地因為沒有做好規劃而做了許多的無用功。
- 總而言之，這次的團隊沖刺，讓我意識到了自己程式設計能力的不足，也讓我在這個過程中學習了知識，收獲了友情。
二、提出關于軟體工程的問題
Q1：《建構之法》書中2.3章節中提到：“PSP的目的是記錄工程師如何實作需求的效率，而不是記錄對産品的滿意度。”就我個人而言，之前的幾次個人作業中都做過PSP表，但是并沒有發現PSP表對效率的提高方面有任何的幫助。雖然預先對所要完成的任務有時間上的預估，但是在真正操作的時候就是做到哪算哪。
Q2：《建構之法》書中4.5.2章節中提到：“結對程式設計有兩個角色：1.駕駛員：控制鍵盤輸入。2.領航員：起到領航、提醒的作用。”我之前所了解的結對程式設計應該是:兩個人各自負責完成自己的部分然後結合在一起，用以提高效率。但是這裡給我們看到結對程式設計是一個人寫，一個人提意見，可能會造成資源浪費的問題（兩個人寫同一個代碼）。
Q3：在靈活沖刺階段，很多東西是不是過于形式化了，站立式的照片，每天代碼送出.....可能老師的想法是可以監督同學每天都做一點，但是其實更多時候我們在完成一個項目的時間一般會比較不固定，不一定會每天都做，每天做的量也不一樣。還有計量方式是如果是按量會更好，畢竟我們還有其他課程，課多的時候少做一點，課少就多做一點。
Q4：《建構之法》書 8.1軟體需求
怎樣更好地了解使用者的需求？有時候使用者想要的效果聽起來很簡單，但是對開發者來說實作就非常困難。遇到這樣的情況怎樣進行協商。
Q5：《建構之法》書 9.5PM的能力要求和任務
“你覺得你的長處不在于寫代碼和debug,而是協調、溝通，.......那麼我看好你的PM潛質”。成為一個合格PM，最重要的是溝通和管理能力還是專業能力呢？
三、自我評價
請用自我評價表：http://www.cnblogs.com/xinz/p/3852177.html 有比較才會有進步。
1、保持高标準，不要受制于破窗理論(broken windows theory)。當你看到不靠譜的設計、糟糕的代碼、過時的文檔和測試用例的時候，不要想 “既然别人的代碼已經這樣了，我的代碼也可以随便一點啦。” d) 一直主動這樣做
- 主動解決問題。當看到不靠譜的設計，糟糕的代碼的時候，不要想“可能别人會來管這個事情” ，或者“我下個月發一個郵件讓大家讨論一下”。要主動地把問題給解決。a) 不懂啥是靠譜的設計
- 經常給自己充電，身體訓練是運動員生活的一部分，學習是軟體工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。通過定期分享（面對面的分享，寫技術部落格等）來確定自己真正掌握了新技術。d) 一直主動這樣做
- DRY （Don't Repeat Yourself）——别重複。在一個系統中，每一個知識點都應該有一個無異議的、正規的表現形式。a) 從來沒聽說過；
- 消除不相關子產品之間的影響，在設計子產品的時候，要讓它們目标明确并單一，能獨立存在，沒有不明确的外部依賴。c) 想做，但是不知道怎麼衡量效果。
- 通過快速原型來學習，快速原型的目的是學習，它的價值不在于代碼，而在于你通過快速原型學到了什麼。 b) 把原型直接用于産品，不然就浪費了；
- 設計要接近問題領域，在設計的時候，要接近你目标使用者的語言和環境。a) 從來沒聽說過；
- 估計任務所花費的時間，避免意外。在開始工作的時候，要做出時間和潛在影響的估計，并通告相關人士，避免最後關頭意外發生。工作中要告知可能的時間變化，事後要總結。d) 一直主動這樣做
- 圖形界面的工具有它的長處，但是不要忘了指令行工具也可以發揮很高的效率，特别是可以用腳本建構各種組合指令的時候。 d) 一直主動這樣做
- 有很多代碼編輯器，請把其中一個用得非常熟練。讓編輯器可以實作自己的定制，可以用腳本驅動，用起來得心應手。e) 還會學習和使用各種編輯器的擴充。
- 了解常用的設計模式，并知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麼，什麼時候用，什麼時候不用。 d)有實際使用的經驗
- 代碼版本管理工具是你代碼的保障，重要的代碼一定要有代碼版本管理。b) 用QQ，u盤即可；
- 在debug的時候，不要驚慌，想想導緻問題的原因可能在哪裡。一步一步地找到原因。要在實踐中運用工具，善于分析日志（log），從中找到bug。同時，在自己的代碼裡面加 log.b) 隻會printf；
- 重要的接口要用形式化的“合同”來規定。用文檔和斷言、自動化測試等工具來保證代碼的确按照合同來做事，不多也不少。使用斷言 (assertion) 或者其他技術來驗證代碼中的假設，你認為不可能發生的事情在現實世界中往往會發生。 a) 從來沒聽說過；
- 隻在異常的情況下才使用異常 (Exception), 不加判斷地過多使用異常，會降低代碼的效率和可維護性。記住不要用異常來傳遞正常的資訊。 d) 一直主動這樣做
- 善始善終。如果某個函數申請了空間或其他資源，這個函數負責釋放這些資源。a) 從來沒聽說過；
- 當你的軟體有多種技術結合在一起的時候，要采用松耦合的配置模式，而不是要把所有代碼都混到一起。c) 代碼都在一起比較好管理。
- 把常用子產品的功能打造成獨立的服務，通過良好的界面 (API) 來調用不同的服務。c) 如果有明确要求，我可以做好
- 在設計中考慮對并行的支援，這樣你的API 設計會比較容易擴充。 b) 并行不會出錯的；
- 在設計中把展現子產品 (View) 和實體子產品 (Model) 分開，這樣你的設計會更有靈活性。 a) 代碼都在一起比較好改；
- 重視算法的效率，在開始寫之前就要估計好算法的效率是哪一個數量級上的（big-O）。d) 主動測試程式效率，以驗證估算
- 在實際的運作場景中測試你的算法，不要停留在數學分析層面。有時候一個小小的實際因素 (是否支援大小寫敏感的排序，資料是否支援多語言)會導緻算法效率的巨大變化。主要靠肉眼觀察算法效率。 d) 一直主動這樣做
- 經常重構代碼，同時注意要解決問題的根源。c) 每天應該重構兩次。
- 在開始設計的時候就要考慮如何測試 ，如果代碼出了問題，有log 來輔助debug 麼? 盡早測試，經常測試，争取實作自動化測試，争取每一個建構的版本都能有某些自動測試。c) 項目沒有安排時間，我也沒有提這事。
- 代碼生成工具可以生成一堆一堆的代碼，在正式使用它們之前，要確定你能了解它們，并且必要的時候能debug 這些代碼。c) 那些代碼沒有bug。
- 和一個實際的使用者一起使用軟體，獲得第一手回報。 a) 從來沒聽說過；
- 在自動測試的時候，要有意引地入bug，來保證自動測試的确能捕獲這些錯誤。e) 不但主動做， 還會影響同僚一起做好
- 如果測試沒有做完，那麼開發也沒有做完。 d) 一直主動這樣做
- 适當地追求代碼覆寫率：每一行的代碼都覆寫了，但是程式未必正确。要確定程式覆寫了不同的程式狀态和各種組合條件。 c) 要覆寫至少60%。
- 如果團隊成員碰到了一個有普遍意義的bug, 應該建立一個測試用例抓住以後将會出現的類似的bug。 d) 一直主動這樣做
- 測試：多走一步，多考慮一層。如果程式運作了一星期不退出，如果使用者的螢幕分辨率再提高一個檔次，這個程式會出什麼可能的錯誤? a) 從來沒聽說過；
- （帶領團隊）了解使用者的期望值，稍稍超出使用者的期望值，讓使用者有驚喜。 a) 從來沒聽說過；
- （帶領團隊） 不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過時的假設、對使用者的誤解或其他因素所遮擋。e) 不但主動做， 還會影響同僚一起做好
- （帶領團隊）把所有的術語和項目相關的名詞、縮寫等都放在一個地方。a) 從來沒聽說過；
- （帶領團隊）不要依賴于某個人的手動操作，而是要把這些操作都做成有相關權限的人士都能運作的腳本。這樣就不會出現因為某人休假而項目被卡住的情況。 c) 出了問題再說
- （帶領團隊）要讓重用變得更容易。一個軟體團隊要創造一種環境，讓大家有輕松的心态來嘗試各種想法 （例如，子產品的重用，效能的提升，等）a) 都聽上司的；
- （帶領團隊）在每一次疊代之後，都要總結經驗，讓下一次疊代的進度安排更可靠，品質更高。 d) 一直主動這樣做
個人評價：在這個過程中收獲了不少，也學會了一些前端的入門知識。同時也讓我看到了自己與他人水準的差距，自己還有很多的不足，還是需要不斷地怒力來提高自身的水準。盡管這門課程花費了許多的時間，但還是有非常多的收獲的。