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