一、個人總結
- 在alpha 結束之后， 每位同學寫一篇個人博客， 總結自己的alpha 過程；
- 請用自我評價表：http://www.cnblogs.com/xinz/p/3852177.html 有比較才會有進步。
（1）
| 類別 | 具體技能和面試問題 | 現在的回答 (大三) |
|---|---|---|
| 語言 | 最拿手的計算機語言之一,代碼量多少? (偏前端) | 最近才了解了微信小程序的前端設計語言js，但不能說拿手 |
| 語言 | 最拿手的計算機語言,代碼量多少? (偏后端) | java一點點，代碼量沒具體統計過 |
| 軟件實現 | (閱讀代碼的能力， 實現，單元測試)你有沒有在別人代碼的基礎上改進，你是怎么讀懂別人的代碼的，你采取了什么辦法來保證你的新功能不會影響原來的功能?你在開發中碰到最復雜的bug是什么,你是如何解決的?這個bug出現的原因是什么，你在將來應該怎么去避免bug再出現? | 1.有，比如這次結對編程就是對學長的代碼進行改進；2.剛開始還是要自己通過注釋什么的看吧，但是因為每個人的代碼規范不一樣，后面就直接問寫代碼的學長了；3.大的框架不變，只修改了需要改進的代碼，在新增功能的時候要進行多次測試，看之前的代碼可不可以執行；4.遇到的bug就是本身代碼就是有問題的吧，還有就是頁面跳轉，刷新什么的。 |
| 軟件測試 | (測試方法、測試工具測試實踐代碼覆蓋率) 你如何測試你自己寫的代碼?你如何測試別人的代碼? 你掌握了多少種測試工具和方法?你寫過測試工具么? 你如何對一個網站進行壓力測試和效能測試?你如何測試一一個軟件的人機界面(Ux/UI) | 就是在結對的時候用java的測試工具進行了第一次測試，至於掌握了多少種測試工具就沒有吧，也沒有自己寫過測試代碼。 |
| 效能分析 | 效能分析，效能改進 你寫過的最復雜的代碼是什么?你是如何測量和改進它的效能的，用了什么工具，如何分析的? | 最復雜就是課設的時候，之前基本沒做過效能測試吧，就單單看執行結果而已。 |
| 需求分析 | (需求分析， 典型用戶，場景，創新) 你做過多少個有實際用戶的項目，用戶最多有多少?你的項目有什么創新的地方? | 沒做過 |
| 行業洞察 | 你最感興趣的領域是什么?這個領域過去10年經歷了哪些創新?力 你分析過這個領域前10名產品么?請分析一下他們的優劣， 你要進入這個領域，應該如何創新? | 之前沒有特別感興趣的，最近對網絡安全還挺有興趣的，網安越來越重要了吧，畢竟現在網絡很發達，用戶和集團的隱私保護極為重要，要創新說不上，就只想跟着時代的發展就好了。 |
| 項目管理 | 你參與過項目管理么?請描述一下兩個當下流行的開發方法在你的項目中的具體應用情況; 請問你如何決定項目中各種任務的優先次序，有什么理論來支持你的做法 如果你突然發現項目不能按時完成，你作為項目領導，有什么辦法? | 沒有當過 |
| 軟件設計 | 你做過架構設計，模塊化設計，接口設計么?請說明一下你為何是這樣設計，你比較過什么不同的設計方式，你的設計取得了什么結果? | 我做過這次團隊的架構設計，我是根據我們小程序的功能，分模塊進行的。結果還可以吧。 |
| 質量意識 | (代碼復審/代碼規范/代碼質量) 你是怎么做代碼復審的，你加入我們團隊后，能幫我們提高代碼質量么，請具體說怎么提高? | 我們代碼復審就是小組進行的，可能不能吧，但會努力。 |
| 工具/社區 | Software Tools (performance tool, version control, work item, TFS) 你在各種開發平台(web, linux, PC， mobile, machine learning)都使用過什么樣的工具，自己寫過什么工具來改進工作效率?給社區貢獻過什么工具和代碼? Github有分享代碼么?你寫的技術博客堅持了多久，讀者最多的是哪一篇? | 還未在開發平台使用過工具。用碼雲來分享管理代碼。寫博客是從java這門開始的，讀者最多的篇章沒看過哪個最多。 |
| 團隊協作 | Work with others (協同工作，提供反饋，說服別人) 請描述你在項目中如何說服同伴采用你提出的更好的解決方案，或者你如何聽取了別人的意見，改進了自己的方案?你如何說服懶惰的同伴加緊工作，實現團隊的目標? | 就是每個人說出自己的想法，別人的意見，首先要聽懂並理解，然后改進自己的，我覺得團隊還是很和諧，沒有說了不聽的情況。 |
| 理論素養 | 你上過什么數學,計算機或其他理論課，請舉出具體的例子，說明你學到的理論知識如何幫助你解決實際問題。 | 高等數學、線代、概率論、離散數學；C語言、數據結構、java等等；我覺得這些都是為以后的專業知識打基礎的。 |
| 自我管理 | 全年級你專業排名多少? 你從剛入學(大學一年級)到現在的排名有變化么?如何解釋你的排名的變化 | 基本沒有變化。 |
（2）
| 編號 | 問題 | 選項 | 回答 |
| 1 | 保持高標准，不要受制於破窗理論(broken windows theory)[i]。當你看到不靠譜的設計、糟糕的代碼、過時的文檔和測試用例的時候，不要想 “既然別人的代碼已經這樣了，我的代碼也可以隨便一點啦 | a) 從來沒聽說過； b) 我就是這樣隨便過來的； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | c |
| 2 | 主動解決問題。當看到不靠譜的設計，糟糕的代碼的時候，不要想“可能別人會來管這個事情” ，或者“我下個月發一個郵件讓大家討論一下”。要主動地把問題給解決了 | 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) 不但主動做， 還會影響同事一起做好 | e |
| 6 | 通過快速原型來學習，快速原型的目的是學習，它的價值不在於代碼，而在於你通過快速原型學到了什么 | a) 從來沒聽說過； b) 把原型直接用於產品，不然就浪費了； c) 不用原型，一直在產品中直接改。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | e |
| 7 | 設計要接近問題領域，在設計的時候，要接近你目標用戶的語言和環境 | a) 從來沒聽說過； b) 按我的想法設計，用戶以后會適應的； c) 大概同意，但是怎么接近用戶呢？ d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | c |
| 8 | 估計任務所花費的時間，避免意外。在開始工作的時候，要做出時間和潛在影響的估計，並通告相關人士，避免最后關頭意外發生。工作中要告知可能的時間變化，事后要總結 | a) 做完了，就知道花費了，不用事先估計； b) 大概估一下，不必在意時間 c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | d |
| 9 | 圖形界面的工具有它的長處，但是不要忘了命令行工具也可以發揮很高的效率，特別是可以用腳本構建各種組合命令的時候 | a) 一直用鼠標和GUI； b) 到時候問牛人； c) 正在學習命令行工具。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | c |
| 10 | 有很多代碼編輯器，請把其中一個用得非常熟練。讓編輯器可以實現自己的定制，可以用腳本驅動，用起來得心應手 | a) 只用老師教的一個； b) 隨意； c) 沒有任何定制。 d) 會定制，並且分享給其他人 e) 還會學習和使用各種編輯器的擴展 | e |
| 11 | 理解常用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什么，什么時候用，什么時候不用 | a) 從來沒聽說過； b) 模式沒用； c) 每寫100行程序，我就盡量用一個模式。 d)有實際使用的經驗 e) 能用具體代碼說明模式的利弊 | a |
| 12 | 代碼版本管理工具是你代碼的保障，重要的代碼一定要有代碼版本管理 | a) 從來沒聽說過； b) 用QQ，u盤即可； c) 領導要求才用。 d) 經常用 e) 不但主動做， 還會影響同事一起做好 | d |
| 13 | 在debug的時候，不要驚慌，想想導致問題的原因可能在哪里。一步一步地找到原因。要在實踐中運用工具，善於分析日志（log），從中找到bug。同時，在自己的代碼里面加 log. | a) 從來沒聽說過； b) 只會printf； c) 加log 太麻煩，我的代碼不會有bug 的。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | b |
| 14 | 重要的接口要用形式化的“合同”來規定。用文檔和斷言、自動化測試等工具來保證代碼的確按照合同來做事，不多也不少。使用斷言 (assertion) 或者其他技術來驗證代碼中的假設，你認為不可能發生的事情在現實世界中往往會發生 | a) 從來沒聽說過； b) 太麻煩，不用； c) 想用，但沒有時間。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | c |
| 15 | 只在異常的情況下才使用異常 (Exception), 不加判斷地過多使用異常，會降低代碼的效率和可維護性。記住不要用異常來傳遞正常的信息 | a) 從來沒聽說過； b) 抓住所有異常 c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | c |
| 16 | 善始善終。如果某個函數申請了空間或其他資源，這個函數負責釋放這些資源 | a) 從來沒聽說過； b) 隨緣； c) 有時這樣做。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | d |
| 17 | 當你的軟件有多種技術結合在一起的時候，要采用松耦合的配置模式，而不是要把所有代碼都混到一起 | a) 從來沒聽說過； b) 沒有實踐的機會； c) 代碼都在一起比較好管理。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | b |
| 18 | 把常用模塊的功能打造成獨立的服務，通過良好的界面 (API) 來調用不同的服務 | a) 從來沒聽說過； b) 拷貝代碼過來用也可以 c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | b |
| 19 | 在設計中考慮對並行的支持，這樣你的API 設計會比較容易擴展 | a) 從來沒聽說過； b) 並行不會出錯的； c) 任何代碼都應支持並行。 d) 考慮在適當的層次支持並行 e) 不但主動做， 還會影響同事一起做好 | d |
| 20 | 在設計中把展現模塊 (View) 和實體模塊 (Model) 分開，這樣你的設計會更有靈活性 | a) 代碼都在一起比較好改； b) 隨緣啦； c) 沒搞清楚啥是V，啥是M。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | d |
| 21 | 重視算法的效率，在開始寫之前就要估計好算法的效率是哪一個數量級上的（big-O） | a) 從來沒聽說過； b) 我的數據量不大，無所謂； c) 不會有效率問題的，現在CPU 都快了。 d) 主動測試程序效率，以驗證估算 e) 不但主動做， 還會影響同事一起做好 | a |
| 22 | 在實際的運行場景中測試你的算法，不要停留在數學分析層面。有時候一個小小的實際因素 (是否支持大小寫敏感的排序，數據是否支持多語言)會導致算法效率的巨大變化 | a) 從來沒聽說過； b) 想用，但不知道工具 c) 主要靠肉眼觀察算法效率。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | b |
| 23 | 經常重構代碼，同時注意要解決問題的根源 | a) 從來沒聽說過； b) 任何修改都可以叫重構； c) 每天應該重構兩次。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | d |
| 24 | 在開始設計的時候就要考慮如何測試 ，如果代碼出了問題，有log 來輔助debug 么? 盡早測試，經常測試，爭取實現自動化測試，爭取每一個構建的版本都能有某些自動測試 | a) 從來沒聽說過； b) 我的代碼不會出問題的； c) 項目沒有安排時間，我也沒有提這事。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | c |
| 25 | 代碼生成工具可以生成一堆一堆的代碼，在正式使用它們之前，要確保你能理解它們，並且必要的時候能debug 這些代碼 | a) 從來沒聽說過； b) 從來不看那些代碼； c) 那些代碼沒有bug。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | d |
| 26 | 和一個實際的用戶一起使用軟件，獲得第一手反饋 | a) 從來沒聽說過； b) 用戶太蠢，不值得聽反饋； c) 想做但是沒有機會。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | c |
| 27 | 在自動測試的時候，要有意引地入bug，來保證自動測試的確能捕獲這些錯誤 | a) 沒聽說過； b) 不必這么麻煩； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | c |
| 28 | 如果測試沒有做完，那么開發也沒有做完 | a) 從來沒聽說過； b) 簽入代碼，就是做完了； c) 。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | d |
| 29 | 適當地追求代碼覆蓋率：每一行的代碼都覆蓋了，但是程序未必正確。要確保程序覆蓋了不同的程序狀態和各種組合條件 | a) 從來沒聽說過； b) 覆蓋20% 就好了； c) 要覆蓋至少60%。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | d |
| 30 | 如果團隊成員碰到了一個有普遍意義的bug, 應該建立一個測試用例抓住以后將會出現的類似的bug | a) 從來沒聽說過； b) 每個bug都是特殊的； c) 測試用例不值得加 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | d |
| 31 | 測試：多走一步，多考慮一層。如果程序運行了一星期不退出，如果用戶的屏幕分辨率再提高一個檔次，這個程序會出什么可能的錯誤? | a) 從來沒聽說過； b) 如果有問題，用戶會報告的，我們不用測這些； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | d |
| 32 | （帶領團隊）了解用戶的期望值，稍稍超出用戶的期望值，讓用戶有驚喜 | a) 從來沒聽說過； b) 我們決定用戶的期望； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | c |
| 33 | （帶領團隊） 不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過時的假設、對用戶的誤解或其他因素所遮擋 | a) 從來沒聽說過； b) 用戶不說的，我們不做； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | c |
| 34 | （帶領團隊）把所有的術語和項目相關的名詞、縮寫等都放在一個地方 | a) 從來沒聽說過； b) 都記在我腦子里； c) 大家看代碼就好 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | c |
| 35 | （帶領團隊）不要依賴於某個人的手動操作，而是要把這些操作都做成有相關權限的人士都能運行的腳本。這樣就不會出現因為某人休假而項目被卡住的情況 | a) 從來沒聽說過； b) 我們沒有休假的，沒關系； c) 出了問題再說 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | d |
| 36 | （帶領團隊）要讓重用變得更容易。一個軟件團隊要創造一種環境，讓大家有輕松的心態來嘗試各種想法 （例如，模塊的重用，效能的提升，等） | a) 都聽領導的； b) 團隊嚴肅緊張最好； c) 不必嘗試，失敗的可能性太大。 d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | d |
| 37 | （帶領團隊）在每一次迭代之后，都要總結經驗，讓下一次迭代的進度安排更可靠，質量更高 | a) 沒有時間總結，直接做下一版； b) 總結用處不大； c) 如果上級有要求，就做一下； d) 一直主動這樣做 e) 不但主動做， 還會影響同事一起做好 | d |
| 38 | （帶領團隊）團隊中往往會有矛盾產生，作為領頭人，怎么辦？ | a) 我沒看見矛盾。 b) 和稀泥，過得去就行 ； c) 如果沒有捅到上級那里，就打哈哈，希望他們自己搞定； d) 有明確和一致的處理矛盾的原則 e) 不但有明確和一致的處理原則，而且對於影響團隊士氣的任何事情追究到底 | d |
二、回答問題
- 我們在課程開始之初，曾經要求大家針對軟件工程提出問題：個人閱讀作業2，那么在經過alpha階段，大家是否對軟件工程有了一定的了解？請結合自己提出的問題進行回答
我這個問題其實當時有給出解答，至於我后面提的怎么修改軟件的問題，在我經過半學期的學習，我覺得修改軟件並不是單純的修改代碼，還有軟件的美工，界面設計等都屬於軟件的一部分，還有在軟件完成后我們還要針對bug進行修改，還是很復雜的，而擴展需求是根據之前的需求分析加團隊特有的想法來決定的，也有可能也是本身自己項目的特色或殺手功能。
這個問題我還是這么想的。雖然我們這次的需求分析也沒用焦點小組的方法，還是用普通的問卷調查進行的，只調查了考研的人，並不是不同類型的。以后可能會用到這樣的方法吧。
這個問題我還沒有搞清楚。可能對於軟件也不是那么重要吧。只要按照自己的代碼規范編寫，做好測試，修復bug的話，軟件的衛生屬性應該挺好的吧。
問題四因為我們的人手不夠，所以有開發的人員也做測試。但這兩項工作沒有同時進行，也是先開發在進行測試的，課本說不能替代我覺得沒必要這么要求。雖說各司其職很重要，但如果團隊配合的好，也是可以互相幫助，這樣反而可以提高工作效率的。
三、再提問題
-
同時，大家一定會在實踐過程中產生更多問題， 結合你的讀書（教材，博客，參考書）， 實踐， 再提出關於軟件工程的 5 個問題。
- 在每個問題后面，請說明哪一章節的什么內容引起了你的提問，提供一些上下文。
- 列出一些事例或資料，支持你的提問 。
- 說說你提問題的原因，你說因為自己的假設和書中的不同而提問，還是不懂書中的術語，還是對推理過程有疑問，還是書中的描述和你的經驗（直接經驗或間接經驗）矛盾？
-
Q1：學習的教材《構建之法》到底學的是什么？
通讀教材在加學習到今天，我覺得我們的這本書是在叫我們如何開發一個軟件，也就是軟件開發的流程，我之前還以為書里會教如何實現功能就是編寫代碼，但是看來並不是。軟件開發的工程還是挺多的，很累，在體驗過敏捷沖刺后，感覺整個人都不好了。
- Q2：書102頁有一個統一流程的四個階段里並沒有提到alpha階段，把初始功能的設計說是Beta階段，但是我們團隊做項目的時候都是把基礎功能放到了alpha階段，這好像與實際情況不符。
- Q3：P165 如果計划的功能實現起來很困難，而剛好是該項目的特色功能，這個時候是要放棄該功能嗎？所以殺手功能一定是必須的嗎？如果缺少殺手功能的軟件還是好的軟件嗎？
- Q4：如何判斷是代碼本身的bug，還是因為數據或后台或服務器的bug？
- Q5：敏捷沖刺結束了，敏捷流程具體是什么意思？