1、在《構建之法》p58頁3.1個人能力的衡量與發展中提到：把每個人的工作有序地組織起來，就是團隊的流程。
但是它舉例將體能、技術、意識、鬥志作為足球個**程是我不明白的地方。
2、在《構建之法》p102 5.2軟體團隊模式 關於團隊和非團隊的區別。
它的例子說臨時組成的就不算團隊，但是我們軟工團隊也是臨時組成的，而且還要進行換成員對於該成員來說又是一次臨時組成的，那麼這算團隊？
3、在《構建之法》p114 5.3.6漸進交付的流程中。
需要我們不僅僅是總結後各自進行修改，得一邊修改一邊相互驗證，但是對於日常課程諸多的我們來說，這是否會影響我們按照這個方式進行迴圈？
4、在《構建之法》p62 3.2軟體工程師的職業發展中
我們並看不到軟體工程對於網路工程發展的作用，我們相對於軟體工程系別的人來說，學習軟工是否捨本求末（出去從事本專業的學長並沒有用到軟工的知識）而想說靠著一門課程超過軟體工程專業的學生無疑是不可能的。
5、在《構建之法》p258 12.3評價標準中
我想知道對於不同軟體又或者是不同程式設計，我們該以什麼方式判斷該程式的優劣，是美觀？或者是演算法的簡易程度？又或者是實行功能的多少？
1.保持高標準，不要受制於破窗理論(broken windows theory)[i]。
當你看到不靠譜的設計、糟糕的**、過時的文件和測試用例的時候，不要想 「既然別人的**已經這樣了，我的**也可以隨便一點啦。
如果有明確要求，我可以做好；
主動解決問題。當看到不靠譜的設計，糟糕的**的時候，不要想「可能別人會來管這個事情」 ，或者「我下個月發乙個郵件讓大家討論一下」。要主動地把問題給解決了[ii]。
一直主動這樣做 ；
經常給自己充電，身體訓練是運動員生活的一部分，學習是軟體工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。通過定期分享（面對面的分享，寫技術部落格等）來確保自己真正掌握了新技術。
看了就忘； 有時分享；
dry （don't repeat yourself）——別重複。在乙個系統中，每乙個知識點都應該有乙個無異議的、正規的表現形式。
從來沒聽說過；
消除不相關模組之間的影響，在設計模組的時候，要讓它們目標明確並單一，能獨立存在，沒有不明確的外部依賴。
想做，但是不知道怎麼衡量效果；
通過快速原型來學習，快速原型的目的是學習，它的價值不在於**，而在於你通過快速原型學到了什麼。
不用原型，一直在產品中直接改；
設計要接近問題領域，在設計的時候，要接近你目標使用者的語言和環境。
一直主動這樣做；
估計任務所花費的時間，避免意外。在開始工作的時候，要做出時間和潛在影響的估計，並通告相關人士，避免最後關頭意外發生。工作中要告知可能的時間變化，事後要總結。
如果有明確要求，我可以做好；
圖形介面的工具有它的長處，但是不要忘了命令列工具也可以發揮很高的效率，特別是可以用指令碼構建各種組合命令的時候。
一直用滑鼠和gui；
有很多**編輯器，請把其中乙個用得非常熟練。讓編輯器可以實現自己的定製，可以用指令碼驅動，用起來得心應手。
只用老師教的乙個；
理解常用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麼，什麼時候用，什麼時候不用。
模式沒用；
**版本管理工具是你**的保障，重要的**一定要有**版本管理。
b) 用qq，u盤即可；
在debug的時候，不要驚慌，想想導致問題的原因可能在**。一步一步地找到原因。要在實踐中運用工具，善於分析日誌（log），從中找到bug。同時，在自己的**裡面加 log。
只會printf；
重要的介面要用形式化的「合同」來規定。用文件和斷言、自動化測試等工具來保證**的確按照合同來做事，不多也不少。使用斷言 (assertion) 或者其他技術來驗證**中的假設，你認為不可能發生的事情在現實世界中往往會發生。
太麻煩，不用；
只在異常的情況下才使用異常 (exception), 不加判斷地過多使用異常，會降低**的效率和可維護性。記住不要用異常來傳遞正常的資訊。
從來沒聽說過；
善始善終。如果某個函式申請了空間或其他資源，這個函式負責釋放這些資源。
一直主動這樣做；
當你的軟體有多種技術結合在一起的時候，要採用松耦合的配置模式，而不是要把所有**都混到一起。
**都在一起比較好管理；
把常用模組的功能打造成獨立的服務，通過良好的介面 (api) 來呼叫不同的服務。
如果有明確要求，我可以做好；
在設計中考慮對並行的支援，這樣你的api 設計會比較容易擴充套件。
任何**都應支援並行；
在設計中把展現模組 (view) 和實體模組 (model) 分開，這樣你的設計會更有靈活性。
一直主動這樣做；
重視演算法的效率，在開始寫之前就要估計好演算法的效率是哪乙個數量級上的（big-o）。
不會有效率問題的，現在cpu 都快了；
在實際的執行場景中測試你的演算法，不要停留在數學分析層面。有時候乙個小小的實際因素 (是否支援大小寫敏感的排序，資料是否支援多語言)會導致演算法效率的巨大變化。
主要靠肉眼觀察演算法效率；
經常重構**，同時注意要解決問題的根源。
任何修改都可以叫重構；
在開始設計的時候就要考慮如何測試 ，如果**出了問題，有log 來輔助debug 麼? 盡早測試，經常測試，爭取實現自動化測試，爭取每乙個構建的版本都能有某些自動測試。
專案沒有安排時間，我也沒有提這事；
**生成工具可以生成一堆一堆的**，在正式使用它們之前，要確保你能理解它們，並且必要的時候能debug 這些**。
一直主動這樣做；
和乙個實際的使用者一起使用軟體，獲得第一手反饋。
不但主動做， 還會影響同事一起做好；
在自動測試的時候，要有意引地入bug，來保證自動測試的確能捕獲這些錯誤。
不必這麼麻煩；
如果測試沒有做完，那麼開發也沒有做完。
一直主動這樣做；
適當地追求**覆蓋率：每一行的**都覆蓋了，但是程式未必正確。要確保程式覆蓋了不同的程式狀態和各種組合條件。
要覆蓋至少60%；
如果團隊成員碰到了乙個有普遍意義的bug, 應該建立乙個測試用例抓住以後將會出現的類似的bug。
測試用例不值得加 ；
測試：多走一步，多考慮一層。如果程式執行了一星期不退出，如果使用者的螢幕解析度再提高乙個檔次，這個程式會出什麼可能的錯誤?
如果有明確要求，我可以做好；
32.（帶領團隊）了解使用者的期望值，稍稍超出使用者的期望值，讓使用者有驚喜。
如果有明確要求，我可以做好；
33.（帶領團隊）不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過時的假設、對使用者的誤解或其他因素所遮擋。
如果有明確要求，我可以做好；
（帶領團隊）把所有的術語和專案相關的名詞、縮寫等都放在乙個地方。
大家看**就好 ；
35.（帶領團隊）不要依賴於某個人的手動操作，而是要把這些操作都做成有相關許可權的人士都能執行的指令碼。這樣就不會出現因為某人休假而專案被卡住的情況。
一直主動這樣做；
36.（帶領團隊）要讓重用變得更容易。乙個軟體團隊要創造一種環境，讓大家有輕鬆的心態來嘗試各種想法 （例如，模組的重用，效能的提公升，等）。
一直主動這樣做；
37.（帶領團隊）在每一次迭代之後，都要總結經驗，讓下一次迭代的進度安排更可靠，質量更高。
一直主動這樣做；
個人作業3 個人總結（Alpha階段）
2017 5 15 22 00pm，以部落格發表日期為準 我們在alpha 結束之後，每位寫乙個部落格，總結自己的alpha 過程，同時，大家一定會在過程中產生了很多問題，結合你的讀書 教材，部落格，參考書 實踐，提出關於軟體工程的 5 個問題。在每個問題後面，請說明哪一章節的什麼內容引起了你的提問...
個人作業3 個人總結（Alpha階段）
2017 5 15 22 00pm，以部落格發表日期為準 我們在alpha 結束之後，每位寫乙個部落格，總結自己的alpha 過程，同時，大家一定會在過程中產生了很多問題，結合你的讀書 教材，部落格，參考書 實踐，提出關於軟體工程的 5 個問題。在每個問題後面，請說明哪一章節的什麼內容引起了你的提問...
個人作業3 個人總結（Alpha階段）
我們在alpha 結束之後，每位寫乙個部落格，總結自己的alpha 過程，同時，大家一定會在過程中產生了很多問題，結合你的讀書 教材，部落格，參考書 實踐，提出關於軟體工程的 5 個問題。時刻明確團隊的最終目標 在設計軟體原型，編寫軟體 中，我們要做 實現需求規格說明書中所列的功能要求 這個最終目標...