我的做業3——我的總結（Alpha階段）

1、問題

1.p172 功能的定位和優先級一節中說本身的產品要有一個差別化的焦點做爲殺手功能，而且舉了一個賣包子的例子：別人有肉包、菜包、小籠包，而咱們有蟹黃小籠包。我想問，可不能夠是把別人已有的功能作得更好更符合用戶需求來做爲殺手功能，就好比說咱們將肉包、菜包作得餡更足皮更薄？

2.p199 

若是一個PM不是由一個好的程序員轉型而來的話，那麼他可否很好的理解程序員所設計出的東西？

3.p120 衝刺階段一節說有任何需求的改變都要等待衝刺結束後再討論？這句話我比較困惑，在開發過程當中，若是客戶需求有大的改動，而咱們又按照原來的需求衝刺，那是否會形成時間和精力上的浪費？

4.P157第八章需求分析，若是咱們進行需求分析後，發現有不少用戶需求的功能，而咱們開發時間又不夠充裕，那麼咱們是應該每一個都作後期再來完善仍是應該盡力作好一兩個後期再來增長功能？

5.換人機制：誠然，在一個團隊中，人員的更迭是不可避免的，那麼，團隊中加入一個新成員時，咱們應該一塊兒協助他儘快上手他應該接手的部分，仍是應該繼續完成咱們的模塊讓他本身去熟悉？

 

2、自我評價表

[b]1.保持高標準，不要受制於破窗理論(broken windows theory)^[i]。
當你看到不靠譜的設計、糟糕的代碼、過期的文檔和測試用例的時候，不要想 「既然別人的代碼已經這樣了，個人代碼也能夠隨便一點啦。」

    a) 歷來沒據說過；   b) 我就是這樣隨便過來的；  c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

[b]2. 主動解決問題。當看到不靠譜的設計，糟糕的代碼的時候，不要想「可能別人會來管這個事情」 ，或者「我下個月發一個郵件讓你們討論一下」。要主動地把問題給解決了^[ii]。

   a) 不懂啥是靠譜的設計；   b) 隨便應付一下便可；  c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

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

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

 

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

   a) 歷來沒據說過；   b) 據說過，可是認爲意思不大；  c) 這要講場合。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

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

   a) 歷來沒據說過；   b) 出了問題再說吧；  c) 想作，可是不知道怎麼衡量效果。  d) 可以在多種語言和架構中作到     e) 不但主動作， 還會影響同事一塊兒作好

 

[b]6. 經過快速原型來學習，快速原型的目的是學習，它的價值不在於代碼，而在於你經過快速原型學到了什麼。

   a) 歷來沒據說過；   b) 把原型直接用於產品，否則就浪費了；  c) 不用原型，一直在產品中直接改。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

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

   a) 歷來沒據說過；   b) 按個人想法設計，用戶之後會適應的；  c) 大概贊成，可是怎麼接近用戶呢？  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

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

   a) 作完了，就知道花費了，不用事先估計；   b) 大概估一下，沒必要在乎時間   c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

[d]9. 圖形界面的工具備它的長處，可是不要忘了命令行工具也能夠發揮很高的效率，特別是能夠用腳本構建各類組合命令的時候。

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

 

[a]10. 有不少代碼編輯器，請把其中一個用得很是熟練。讓編輯器能夠實現本身的定製，能夠用腳本驅動，用起來駕輕就熟。

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

 

[b]11. 理解經常使用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麼，何時用，何時不用。

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

 

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

   a) 歷來沒據說過；   b) 用QQ，u盤便可；  c) 領導要求才用。  d) 常常用     e) 不但主動作， 還會影響同事一塊兒作好

 

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

   a) 歷來沒據說過；   b) 只會printf；  c) 加log 太麻煩，個人代碼不會有bug 的。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

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

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

 

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

   a) 歷來沒據說過；   b) 抓住全部異常  c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

[c]16. 有始有終。若是某個函數申請了空間或其餘資源，這個函數負責釋放這些資源。

   a) 歷來沒據說過；   b) 隨緣；  c) 有時這樣作。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

[c]17. 當你的軟件有多種技術結合在一塊兒的時候，要採用鬆耦合的配置模式，而不是要把全部代碼都混到一塊兒。

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

 

[b]18. 把經常使用模塊的功能打形成獨立的服務，經過良好的界面 (API) 來調用不一樣的服務。

   a) 歷來沒據說過；   b) 拷貝代碼過來用也能夠  c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

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

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

 

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

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

 

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

   a) 歷來沒據說過；   b) 個人數據量不大，無所謂；  c) 不會有效率問題的，如今CPU 都快了。  d) 主動測試程序效率，以驗證估算     e) 不但主動作， 還會影響同事一塊兒作好

 

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

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

 

[a]23. 常常重構代碼，同時注意要解決問題的根源。

   a) 歷來沒據說過；   b) 任何修改均可以叫重構；  c) 天天應該重構兩次。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

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

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

 

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

   a) 歷來沒據說過；   b) 歷來不看那些代碼；  c) 那些代碼沒有bug。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

[c]26. 和一個實際的用戶一塊兒使用軟件，得到第一手反饋。 

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

 

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

   a) 沒據說過；   b) 沒必要這麼麻煩；   c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

[d]28. 若是測試沒有作完，那麼開發也沒有作完。

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

 

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

   a) 歷來沒據說過；   b) 覆蓋20% 就行了；  c) 要覆蓋至少60%。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

[a]30. 若是團隊成員碰到了一個有廣泛意義的bug,  應該創建一個測試用例抓住之後將會出現的相似的bug。

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

 

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

   a) 歷來沒據說過；   b) 若是有問題，用戶會報告的，咱們不用測這些；  c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

[c]32. （帶領團隊）瞭解用戶的指望值，稍稍超出用戶的指望值，讓用戶有驚喜。

    a) 歷來沒據說過；   b) 咱們決定用戶的指望；  c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

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

   a) 歷來沒據說過；   b) 用戶不說的，咱們不作；  c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

[c]34. （帶領團隊）把全部的術語和項目相關的名詞、縮寫等都放在一個地方。

   a) 歷來沒據說過；   b) 都記在我腦子裏；  c) 你們看代碼就好  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

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

   a) 歷來沒據說過；   b) 咱們沒有休假的，不要緊；  c) 出了問題再說  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

 

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

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

 

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

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