我的做業4——alpha階段我的總結

---

1、我的總結

類別	具體技能和麪試問題	如今的回答	畢業找工做時的回答
語言	最拿手的計算機語言之一,代碼呈多少? (偏web前端， PC/Mobile App)	C/C++ 未統計代碼量
語言	最拿手的計算機語言之二,代碼呈多少? (偏web前端， PC/Mobile App)	java 未統計代碼量
軟件實現	你有沒有在別人的代碼基礎上進行改進，你是怎麼讀懂別人的代碼，你採起什麼方法來保證你的新功能不會影響原來的功能，你在開發中遇到的最複雜的bug是什麼，怎麼解決，bug出現的緣由，你在未來應該怎麼去避免bug再出現	有，參照註釋反覆閱讀，在原來的功能下對新代碼進行改進，bug常常遇到，老是考慮不到一些比較特殊的狀況，未來寫代碼時，仍是要當心謹慎，考慮全面一些
軟件測試	你是怎麼測試本身的代碼，怎麼測試別人的代碼。你掌握了多少種測試工具和方法？你寫過測試工具嗎？你如何對一個網站進行壓力測試和效能測試？你如何測試一個軟件的人機界面？	利用某些軟件進行測試，沒有寫過測試工具。利用jmeter 軟件進行測試。
需求分析	你作過多少個有實際用戶的項目，用戶最多有多少？你的項目有什麼創新的地方？	具體作過的只有此次的問卷調查，用戶暫時尚未。
行業洞察力	你最感興趣的領域是什麼？這個領域過去10年經歷了哪些創新？你分析過這個領域前10名的產品嗎？請分析一下他們的優劣。你要進入這個領域，應該如何創新？	大數據和人工智能
項目管理	你參加過項目管理嗎，請描述一下兩個當下流行的開發方法在你的項目中的具體應用狀況。如何決定各個任務的優先順序，有什麼理論來支持你的作法？若是項目不能及時完成，你要怎麼辦？	沒有
軟件設計	你作過架構設計，模塊化設計，接口設計嗎？請說明一下你爲什麼是這樣設計的，你比較過不一樣的設計方式嗎？你的設計取得了什麼結果？	沒有
質量意識	你是怎麼作代碼複審的	大概就是添加註釋之類的東西吧
工具/社區	你再各類開發平臺上都是用過什麼樣的工具？本身寫過工具來改進工做效率？給社區貢獻過什麼工具和代碼？Github有分享代碼嗎？你寫的技術博客堅持了多久，讀者最多的是哪一篇？	通常都是把代碼上傳到碼雲上，進行分享和管理。沒寫過什麼技術博客
團隊協做	描述你在項目中如何說服同伴採起你更好的方案，或是聽取別人的意見改進本身的方案，如何說服懶惰的同伴加緊工做	遇到問題你們一塊兒討論就行了，只要團隊在一塊兒不斷溝通，多多發表本身的意見，把本身的想法說給別人聽，讓他們承認本身的想法就好了
理論素養	你上過什麼數學，計算機或是理論課，舉出具體的例子，如何幫你解決問題	高等數學、離散數學、計算機組成與原理、C程序設計、數據結構、Java等
自我管理	整年級你專業排名多少？你從剛入學（大學一年級）到如今的排名有變化嗎？如何解釋你的排名的變化？	有，成績中游左右，最近有所退步，排名的變化只能說明本身在學習方面的心態有所變化，可是我會找到之前的本身的！

---

1. 保持高標準，不要受制於破窗理論(broken windows theory)[i]。
   當你看到不靠譜的設計、糟糕的代碼、過期的文檔和測試用例的時候，不要想 「既然別人的代碼已經這樣了，個人代碼也能夠隨便一點啦。」 c) 若是有明確要求，我能夠作好。
2. 主動解決問題。當看到不靠譜的設計，糟糕的代碼的時候，不要想「可能別人會來管這個事情」 ，或者「我下個月發一個郵件讓你們討論一下」。要主動地把問題給解決了[ii]。 c) 若是有明確要求，我能夠作好。
3. 常常給本身充電，身體訓練是運動員生活的一部分，學習是軟件工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。經過按期分享（面對面的分享，寫技術博客等）來確保本身真正掌握了新技術。 c) 有時分享。
4. DRY （Don't Repeat Yourself）——別重複。在一個系統中，每個知識點都應該有一個無異議的、正規的表現形式。 c) 這要講場合。
   
5. 消除不相關模塊之間的影響，在設計模塊的時候，要讓它們目標明確並單一，能獨立存在，沒有不明確的外部依賴。

c) 想作，可是不知道怎麼衡量效果。

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

e) 不但主動作， 還會影響同事一塊兒作好

1. 設計要接近問題領域，在設計的時候，要接近你目標用戶的語言和環境。 b) 按個人想法設計，用戶之後會適應的；
2. 估計任務所花費的時間，避免意外。在開始工做的時候，要作出時間和潛在影響的估計，並通告相關人士，避免最後關頭意外發生。工做中要告知可能的時間變化，過後要總結。 d) 一直主動這樣作
   
3. 圖形界面的工具備它的長處，可是不要忘了命令行工具也能夠發揮很高的效率，特別是能夠用腳本構建各類組合命令的時候。

c) 正在學習命令行工具。

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

d) 會定製，而且分享給其餘人

1. 理解經常使用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麼，何時用，何時不用。
   d)有實際使用的經驗
   
2. 代碼版本管理工具是你代碼的保障，重要的代碼必定要有代碼版本管理。

e) 不但主動作， 還會影響同事一塊兒作好

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

d) 一直主動這樣作

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

c) 想用，但沒有時間。

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

c) 若是有明確要求，我能夠作好。

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

c) 有時這樣作。

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

b) 沒有實踐的機會；

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

c) 若是有明確要求，我能夠作好。

1. 在設計中考慮對並行的支持，這樣你的API 設計會比較容易擴展。 c) 任何代碼都應支持並行。
2. 在設計中把展示模塊 (View) 和實體模塊 (Model) 分開，這樣你的設計會更有靈活性。

d) 一直主動這樣作

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

d) 主動測試程序效率，以驗證估算 =

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

c) 主要靠肉眼觀察算法效率。

1. 常常重構代碼，同時注意要解決問題的根源。 d) 一直主動這樣作
   
2. 在開始設計的時候就要考慮如何測試 ，若是代碼出了問題，有log 來輔助debug 麼? 儘早測試，常常測試，爭取實現自動化測試，爭取每個構建的版本都能有某些自動測試。

c) 項目沒有安排時間，我也沒有提這事。

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

d) 一直主動這樣作

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

c) 想作可是沒有機會。

1. 在自動測試的時候，要有意引地入bug，來保證自動測試的確能捕獲這些錯誤。 b) 沒必要這麼麻煩；
   
2. 若是測試沒有作完，那麼開發也沒有作完。

e) 不但主動作， 還會影響同事一塊兒作好

1. 適當地追求代碼覆蓋率：每一行的代碼都覆蓋了，可是程序未必正確。要確保程序覆蓋了不一樣的程序狀態和各類組合條件。 c) 要覆蓋至少60%。
2. 若是團隊成員碰到了一個有廣泛意義的bug, 應該創建一個測試用例抓住之後將會出現的相似的bug。

c) 測試用例不值得加

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

c) 若是有明確要求，我能夠作好。

1. （帶領團隊）瞭解用戶的指望值，稍稍超出用戶的指望值，讓用戶有驚喜。 c) 若是有明確要求，我能夠作好。
2. （帶領團隊） 不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過期的假設、對用戶的誤解或其餘因素所遮擋。 c) 若是有明確要求，我能夠作好。
3. （帶領團隊）把全部的術語和項目相關的名詞、縮寫等都放在一個地方。

e) 不但主動作， 還會影響同事一塊兒作好

1. （帶領團隊）不要依賴於某我的的手動操做，而是要把這些操做都作成有相關權限的人士都能運行的腳本。這樣就不會出現由於某人休假而項目被卡住的狀況。 d) 一直主動這樣作
   
2. （帶領團隊）要讓重用變得更容易。一個軟件團隊要創造一種環境，讓你們有輕鬆的心態來嘗試各類想法 （例如，模塊的重用，效能的提高，等）。 b) 團隊嚴肅緊張最好；
3. （帶領團隊）在每一次迭代以後，都要總結經驗，讓下一次迭代的進度安排更可靠，質量更高。 d) 一直主動這樣作
   
4. （帶領團隊）團隊中每每會有矛盾產生，做爲領頭人，怎麼辦？ d) 有明確和一致的處理矛盾的原則

---

2、回答問題

問題一：在書中也提出了要把產品訂單上的任務進行進一步的細化，而後團隊成員根據本身的狀況來認領訂單上的任務，這樣作能夠發揮其能動性。但使用敏捷的開發流程，沒有計劃，沒有文檔，立刻寫代碼，這樣作，是否對一些團隊有必定的影響，換句話說，敏捷開發是否對開發團隊的要求太高？一些能力較差的團隊並不適合敏捷開發？

alpha階段事後，我發現對於敏捷開發，關鍵在於團隊的成員，無論團隊成員編程能力是否太高仍是太低，只要凝聚團隊成員，就能夠把敏捷開發作好，小組成員團結一心，遇到問題一塊兒討論，一塊兒解決，仍是能夠作好的

問題二：在用戶需求分析的階段，由於對於同一件產品來講，不一樣的利益相關者有着對這種產品不一樣的需求，如何權衡這些利益?

咱們作這個問卷調查的項目時，對用戶需求有更多的考慮，團隊項目的功能要基於大多數用戶的需求，也就是說在大多數用戶的需求上進行功能的設計

---

3、再提問題

問題1：

軟件工程的目的是什麼，爲何要分爲alpha階段和Beta階段，團隊在此工程中的做用是什麼？

問題2：

每日立會真的頗有必要嗎，爲何非要「立」啊？

問題3：

關於項目經理PM的選擇，要選編程能力相對較差的人嗎

問題4：

團隊工做的效率如何提升？

問題5：

強行寫滿五個問題。