一、個人總結

第 0 部分：基本數據結構和算法問題

大二的時候上過數據結構課，感覺自己沒有學的太深入，就如之前結對編程時候四則運算有用到的二叉樹來解決問題，對於二叉樹就有個模糊的概念，實際動手操作起來還是有點不知所措；對於“編程就是算法和數據結構,算法和數據結構是編程的靈魂”這句話還是表示很贊同的，從大一到現在，從不會編程到現在的稍微入門吧，鍛煉人的思維能力，一個好的算法和數據結構錘煉出好的代碼。

第一部分：硬的問題

第二部分：軟的問題，在成長路上學到了什麽？

1. 保持高標準，不要受制於破窗理論(broken windows theory)[i]。

當你看到不靠譜的設計、糟糕的代碼、過時的文檔和測試用例的時候，不要想 “既然別人的代碼已經這樣了，我的代碼也可以隨便一點啦。” c
a) 從來沒聽說過； b) 我就是這樣隨便過來的； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

2. 主動解決問題。當看到不靠譜的設計，糟糕的代碼的時候，不要想“可能別人會來管這個事情” ，或者“我下個月發一個郵件讓大家討論一下”。要主動地把問題給解決了。c

a) 不懂啥是靠譜的設計； b) 隨便應付一下即可； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

3. 經常給自己充電，身體訓練是運動員生活的一部分，學習是軟件工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。通過定期分享（面對面的分享，寫技術博客等）來確保自己真正掌握了新技術。c

a) 從來不看書； b) 看了就忘； c) 有時分享。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

4. DRY （Don‘t Repeat Yourself）——別重復。在一個系統中，每一個知識點都應該有一個無異議的、正規的表現形式。d

a) 從來沒聽說過； b) 聽說過，但是認為意思不大； c) 這要講場合。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

5. 消除不相關模塊之間的影響，在設計模塊的時候，要讓它們目標明確並單一，能獨立存在，沒有不明確的外部依賴。c

a) 從來沒聽說過； b) 出了問題再說吧； c) 想做，但是不知道怎麽衡量效果。 d) 能夠在多種語言和架構中做到 e) 不但主動做， 還會影響同事一起做好

6. 通過快速原型來學習，快速原型的目的是學習，它的價值不在於代碼，而在於你通過快速原型學到了什麽。d

a) 從來沒聽說過； b) 把原型直接用於產品，不然就浪費了； c) 不用原型，一直在產品中直接改。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

7. 設計要接近問題領域，在設計的時候，要接近你目標用戶的語言和環境。c

a) 從來沒聽說過； b) 按我的想法設計，用戶以後會適應的； c) 大概同意，但是怎麽接近用戶呢？ d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

8. 估計任務所花費的時間，避免意外。在開始工作的時候，要做出時間和潛在影響的估計，並通告相關人士，避免最後關頭意外發生。工作中要告知可能的時間變化，事後要總結。c

a) 做完了，就知道花費了，不用事先估計； b) 大概估一下，不必在意時間 c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

9. 圖形界面的工具有它的長處，但是不要忘了命令行工具也可以發揮很高的效率，特別是可以用腳本構建各種組合命令的時候。a

a) 一直用鼠標和GUI； b) 到時候問牛人； c) 正在學習命令行工具。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

10. 有很多代碼編輯器，請把其中一個用得非常熟練。讓編輯器可以實現自己的定制，可以用腳本驅動，用起來得心應手。a

a) 只用老師教的一個； b) 隨意； c) 沒有任何定制。 d) 會定制，並且分享給其他人 e) 還會學習和使用各種編輯器的擴展。

11. 理解常用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麽，什麽時候用，什麽時候不用。a

a) 從來沒聽說過； b) 模式沒用； c) 每寫100行程序，我就盡量用一個模式。 d)有實際使用的經驗 e) 能用具體代碼說明模式的利弊

12. 代碼版本管理工具是你代碼的保障，重要的代碼一定要有代碼版本管理。b

a) 從來沒聽說過； b) 用QQ，u盤即可； c) 領導要求才用。 d) 經常用 e) 不但主動做， 還會影響同事一起做好

13. 在debug的時候，不要驚慌，想想導致問題的原因可能在哪裏。一步一步地找到原因。要在實踐中運用工具，善於分析日誌（log），從中找到bug。同時，在自己的代碼裏面加 log.b

a) 從來沒聽說過； b) 只會printf； c) 加log 太麻煩，我的代碼不會有bug 的。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

14. 重要的接口要用形式化的“合同”來規定。用文檔和斷言、自動化測試等工具來保證代碼的確按照合同來做事，不多也不少。使用斷言 (assertion) 或者其他技術來驗證代碼中的假設，你認為不可能發生的事情在現實世界中往往會發生。e

a) 從來沒聽說過； b) 太麻煩，不用； c) 想用，但沒有時間。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

15. 只在異常的情況下才使用異常 (Exception), 不加判斷地過多使用異常，會降低代碼的效率和可維護性。記住不要用異常來傳遞正常的信息。c

a) 從來沒聽說過； b) 抓住所有異常 c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

16. 善始善終。如果某個函數申請了空間或其他資源，這個函數負責釋放這些資源。d

a) 從來沒聽說過； b) 隨緣； c) 有時這樣做。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

17. 當你的軟件有多種技術結合在一起的時候，要采用松耦合的配置模式，而不是要把所有代碼都混到一起。b

a) 從來沒聽說過； b) 沒有實踐的機會； c) 代碼都在一起比較好管理。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

18. 把常用模塊的功能打造成獨立的服務，通過良好的界面 (API) 來調用不同的服務。c

a) 從來沒聽說過； b) 拷貝代碼過來用也可以 c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

19. 在設計中考慮對並行的支持，這樣你的API 設計會比較容易擴展。d

a) 從來沒聽說過； b) 並行不會出錯的； c) 任何代碼都應支持並行。 d) 考慮在適當的層次支持並行 e) 不但主動做， 還會影響同事一起做好

20. 在設計中把展現模塊 (View) 和實體模塊 (Model) 分開，這樣你的設計會更有靈活性。 c

a) 代碼都在一起比較好改； b) 隨緣啦； c) 沒搞清楚啥是V，啥是M。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

21. 重視算法的效率，在開始寫之前就要估計好算法的效率是哪一個數量級上的（big-O）。a

a) 從來沒聽說過； b) 我的數據量不大，無所謂； c) 不會有效率問題的，現在CPU 都快了。 d) 主動測試程序效率，以驗證估算 e) 不但主動做， 還會影響同事一起做好

22. 在實際的運行場景中測試你的算法，不要停留在數學分析層面。有時候一個小小的實際因素 (是否支持大小寫敏感的排序，數據是否支持多語言)會導致算法效率的巨大變化。b

a) 從來沒聽說過； b) 想用，但不知道工具 c) 主要靠肉眼觀察算法效率。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

23. 經常重構代碼，同時註意要解決問題的根源。d

a) 從來沒聽說過； b) 任何修改都可以叫重構； c) 每天應該重構兩次。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

24. 在開始設計的時候就要考慮如何測試 ，如果代碼出了問題，有log 來輔助debug 麽? 盡早測試，經常測試，爭取實現自動化測試，爭取每一個構建的版本都能有某些自動測試。c

a) 從來沒聽說過； b) 我的代碼不會出問題的； c) 項目沒有安排時間，我也沒有提這事。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

25. 代碼生成工具可以生成一堆一堆的代碼，在正式使用它們之前，要確保你能理解它們，並且必要的時候能debug 這些代碼。d

a) 從來沒聽說過； b) 從來不看那些代碼； c) 那些代碼沒有bug。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

26. 和一個實際的用戶一起使用軟件，獲得第一手反饋。 c

a) 從來沒聽說過； b) 用戶太蠢，不值得聽反饋； c) 想做但是沒有機會。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

27. 在自動測試的時候，要有意引地入bug，來保證自動測試的確能捕獲這些錯誤。c

a) 沒聽說過； b) 不必這麽麻煩； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

28. 如果測試沒有做完，那麽開發也沒有做完。e

a) 從來沒聽說過； b) 簽入代碼，就是做完了； c) 。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

29. 適當地追求代碼覆蓋率：每一行的代碼都覆蓋了，但是程序未必正確。要確保程序覆蓋了不同的程序狀態和各種組合條件。d

a) 從來沒聽說過； b) 覆蓋20% 就好了； c) 要覆蓋至少60%。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

30. 如果團隊成員碰到了一個有普遍意義的bug, 應該建立一個測試用例抓住以後將會出現的類似的bug。d

a) 從來沒聽說過； b) 每個bug都是特殊的； c) 測試用例不值得加 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

31. 測試：多走一步，多考慮一層。如果程序運行了一星期不退出，如果用戶的屏幕分辨率再提高一個檔次，這個程序會出什麽可能的錯誤?c

a) 從來沒聽說過； b) 如果有問題，用戶會報告的，我們不用測這些； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

32. （帶領團隊）了解用戶的期望值，稍稍超出用戶的期望值，讓用戶有驚喜。d

a) 從來沒聽說過； b) 我們決定用戶的期望； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

33. （帶領團隊） 不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過時的假設、對用戶的誤解或其他因素所遮擋。c

a) 從來沒聽說過； b) 用戶不說的，我們不做； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

34. （帶領團隊）把所有的術語和項目相關的名詞、縮寫等都放在一個地方。d

a) 從來沒聽說過； b) 都記在我腦子裏； c) 大家看代碼就好 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

35. （帶領團隊）不要依賴於某個人的手動操作，而是要把這些操作都做成有相關權限的人士都能運行的腳本。這樣就不會出現因為某人休假而項目被卡住的情況。d

a) 從來沒聽說過； b) 我們沒有休假的，沒關系； c) 出了問題再說 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

36. （帶領團隊）要讓重用變得更容易。一個軟件團隊要創造一種環境，讓大家有輕松的心態來嘗試各種想法 （例如，模塊的重用，效能的提升，等）。d

a) 都聽領導的； b) 團隊嚴肅緊張最好； c) 不必嘗試，失敗的可能性太大。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

37. （帶領團隊）在每一次叠代之後，都要總結經驗，讓下一次叠代的進度安排更可靠，質量更高。d

a) 沒有時間總結，直接做下一版； b) 總結用處不大； c) 如果上級有要求，就做一下； d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好

38. （帶領團隊）團隊中往往會有矛盾產生，作為領頭人，怎麽辦？d

a) 我沒看見矛盾。 b) 和稀泥，過得去就行 ； c) 如果沒有捅到上級那裏，就打哈哈，希望他們自己搞定； d) 有明確和一致的處理矛盾的原則 e) 不但有明確和一致的處理原則，而且對於影響團隊士氣的任何事情追究到底

二、回答問題

問題1.若是兩個編程能力水平還不夠的同學組一對需要怎麽學習預備知識，或者說如何做到有效的邊實踐邊學？

通過結對編程，我認為知識的事先儲備真的很重要，而在有限的時間內，能力還不夠的情況下，除了自己一邊摸索查資料，還得虛心請教一些大佬，才能實現在實踐中學習並完成任務。在編程能力水平還不夠的情況下做軟工的團隊以及結對編程還是非常吃力的。

問題2.其實每個人原本都有自己的代碼規範和一些習慣，每一換一次團隊就需要換一次代碼規範嗎，這樣是否會磨滅掉個人的一些原有的亮點特色個人風格？

從團隊編程和結對編程的經歷看來，代碼規範對於團隊代碼管理十分重要，雖然每個人的編程習慣不同，但是在一些細節上若是大家都能統一規範事情會簡單許多，而對於特色個人風格，在團隊合作應服從大眾，或者自己本身比較好的地方想寫入代碼規範中也可以和團員探討。

問題3.沖刺階段如果遇到人員說需要作改動該怎麽辦，是應該作修改還是堅持沖刺？如果堅持沖刺，即使這個版本已經完成，但是並沒有符合需求，不是還是得重新修改嗎？

在團隊編程的第一個階段，我們大方向是事先就確定了，基本先確定了哪些功能需要實現，沖刺過程中大方向不變，小的細節會根據實際情況而定，並不會悶著腦袋做到底。

三、再提問題

問題1

看到十五章有個問題：

有一個模塊看來不能實現預期的設計需求，時間快到了，怎麽辦？ 書上的回答設計到了一個名詞叫“沈沒成本”，對這個詞的意思不太明白

通過查詢資料得到以下信息：

經濟學裏有個有意思的詞匯，叫沈沒成本（英文：Sunk Cost）
人們在決定是否去做一件事情的時候，不僅是看這件事對自己有沒有好處，而且也看過去是不是已經在這件事情上有過投入。
我們把這些已經發生不可收回的支出，如時間、金錢、精力等稱為“沈沒成本”

但是我還是有困惑,大多數人應該都沒有那麽偉大的說無私的投入時間和金錢精力而不求回報,因此在面對沈沒成本的時候其實是難以放棄的,更具體的說人應該是難以放棄投入帶來的機會,這個時候我們應該要如何做?

問題2

對十一章的內容有點疑問:

每周的進度報告------還有多少事沒做完,首要推薦TFS的"Remaning Work",可以看敏捷流程的燃盡圖

對於燃盡圖,我的困惑是在alpha階段的沖刺中,我們事先列好燃盡圖,但是期間的過程由於每天的時間都不夠導致很多任務一天根本來不及完成,導致曲線只能是一條橫著的直線,燃盡圖給我們帶來的作用並不是非常大,並且燃盡圖雖然表示了開發的速度，但在實際過程中燃盡圖並不一定表示剩余的工作數量，在敏捷開發中工作量的評估是以"故事"為單位的，一個叠代"故事"的數量會影響到y軸,如果"故事"的數量過少，繪制出來的燃盡圖就會呈現明顯的折線形狀，也會對速度和風險的判斷帶來影響,對於這個問題該如何解決

問題3

對十四章的內容有困惑:

書上有個問題:在測試上,開發人員應該負責哪些測試?(單元測試、模塊測試、集成測試、Beta測試、在正式產品中測試） 書上沒有明確回答這個問題

通過查詢資料：

開發者測試：在軟件行業中，一個程序從開始開發到交付使用，中間涉及了包括單元測試、集成測試、接口測試、性能測試等許多測試環節。其中由開發者完成的代碼級測試部分稱為開發者測試。開發者測試包括：單元測試 、DevOps和測試前移、覆蓋率

既然開發者和專門的測試人員的測試方面不同， 當開發人員堅持項目中的一個順序流程沒有出錯，而測試人員對代碼不夠了解持以不同看法的時候，該如何調和？

問題4

對第十章中的有些內容有點困惑：

書上10.3.2 功能說明書的模板--------很多同學都有這樣的希望，一旦搞到某文檔的模板、某課程的PPT，事情就成功了一大半，盲目地的套用最全面的模板，對項目有極大的副作用

書上只寫到了有極大的副作用而沒有說明清楚副作用是什麽，在團隊合作時不也是先參照模板格式來修改的嗎？

問題5.

對第五章的單元測試這個點有點困惑：

書上寫道軟件是由多人合作完成的，不同人員的工作相互有依賴關系，例如一個人寫的模塊被其他人寫的模塊調用。

因此單元測試以一個個模塊分開測試，如果每個模塊測試的時候是通過的，而最後的整體測試的時候卻發現了比較大的bug，這個時候該怎麽辦，是否需要全部重新測試？全部重新測試是否浪費了時間精力？或者這種情況該如何解決？

alpha階段個人總結（201521123034陳凱欣）