軟工網絡15我的做業4——alpha階段我的總結

1、我的總結

在alpha 結束以後， 每位同窗寫一篇我的博客， 總結本身的alpha 過程；

請用自我評價表：

第一部分

類別	具體技能和麪試問題	如今回答
語言	最拿手的計算機語言、代碼量	java/C。主要代碼量仍是來源於學習時的做業、任務、課設等。
軟件實現	你有沒有在別人的代碼的基礎上改進，你是怎麼讀懂別人的代碼的，你採起了什麼辦法來保證你的新功能不會影響原來的功能？你在開發中碰到的最複雜的bug是什麼？你是如何解決的？這個bug出現的緣由是什麼，你在未來應該如何去避免bug再出現？	有，讀懂別人代碼，結合代碼文字‘、註釋、分塊運行配合理解。若要保證不影響原有功能，儘可能以單獨的模塊進行編寫，避免相互影響。bug遇到不少，因爲沒有開發過複雜的系統，因此常見的都是編程上的規範錯誤，例如非法的表達式開頭、類型不兼容、非法的方法聲明;須要返回類型、數組越界
行業洞察力	你最感興趣的領域是什麼，這個領域過去十年有什麼創新，你分析過這個領域前十的產品嗎，請分析一下他們的優劣，你要進入這個領域，如何創新	圖形引擎領域，這個領域本來是與軟件編程以及美工等兩方面緊密相關的，可是近年來隨着圖形引擎產品的壟斷形式造成，多數表明產品的開發工具更加可視化，相似近年來開放免費的unreal或unity，對編程能力要求愈來愈低，愈來愈看重開發者美術能力和創造力，與咱們傳統的計算機專業存在愈來愈大的出入。若是要進入這方面領域，必須還要額外進行美工UI等方面的學習。
項目管理	你參加過項目管理嗎，如何決定各個任務的優先順序，若是項目不能及時完成，你要怎麼辦	任務始終以核心功能爲第一目標，若是不能及時完成，爭取寬限時間是第一選擇、拋棄邊緣內容爲第二選擇。
團隊協做	描述你在項目中如何說服同伴採起你更好的方案，或是聽取別人的意見改進本身的方案，如何說服懶惰的同伴加緊工做	按期進行會議，交流相互之間的意見。用客觀工期的未能完成任務的後果來警示同伴加緊工做
理論素養	你上過什麼數學，計算機或是理論課，舉出具體的例子，如何幫你解決問題	高等數學、C、計算機組成原理、java等，尤爲是計算機組成原理，包含了一些基礎性的計算機常識，是咱們目前這種僅偏向編程學習的學生反而缺乏的必要知識。
需求分析	你作過多少個有實際用戶的項目，用戶人數多少，你的項目有什麼創新之處	目前沒有作過有實際用戶的項目
工具/社區	你在各類開發平臺都使用過什麼工具，本身寫過什麼工具來改進工做效率？給社區貢獻過什麼工具和代碼？Github有分享代碼麼？你寫的技術博客堅持了多久，讀者最多的是那一篇？	VC++、VS、eclipse等，沒有寫過非做業性質的技術博客
質量意識	你是怎麼作代碼複審的，你加入咱們團隊後，能幫助咱們提升代碼質量麼，請具體說怎麼提升？	以運行穩定、有效爲第一要求。再進行各個模塊的單獨測試，無BUG爲基礎目標，精簡無效代碼爲進一步的目標。
自我管理	整年級你專業排名多少？你從剛入學（大學一年級）到如今的排名有變化嗎？你如何解釋你的排名的變化？	110名左右，處於靠後位置。對本身的要求不夠嚴格，任務目的性過強，自主動力低。

第二部分

編號	問題	個人回答
1	保持高標準，不要受制於破窗理論(broken windows theory)。當你看到不靠譜的設計、糟糕的代碼、過期的文檔和測試用例的時候，不要想 「既然別人的代碼已經這樣了，個人代碼也能夠隨便一點啦。」	若是有明確要求，我能夠作好。
2	主動解決問題。當看到不靠譜的設計，糟糕的代碼的時候，不要想「可能別人會來管這個事情」 ，或者「我下個月發一個郵件讓你們討論一下」。要主動地把問題給解決了。	若是有明確要求，我能夠作好。
3	常常給本身充電，身體訓練是運動員生活的一部分，學習是軟件工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。經過按期分享（面對面的分享，寫技術博客等）來確保本身真正掌握了新技術。	有時分享。
4	DRY （Don't Repeat Yourself）——別重複。在一個系統中，每個知識點都應該有一個無異議的、正規的表現形式。	不但主動作， 還會影響同事一塊兒作好
5	消除不相關模塊之間的影響，在設計模塊的時候，要讓它們目標明確並單一，能獨立存在，沒有不明確的外部依賴。	不但主動作， 還會影響同事一塊兒作好
6	經過快速原型來學習，快速原型的目的是學習，它的價值不在於代碼，而在於你經過快速原型學到了什麼。	一直主動這樣作
7	設計要接近問題領域，在設計的時候，要接近你目標用戶的語言和環境。 一直主動這樣作
8	估計任務所花費的時間，避免意外。在開始工做的時候，要作出時間和潛在影響的估計，並通告相關人士，避免最後關頭意外發生。工做中要告知可能的時間變化，過後要總結。	若是有明確要求，我能夠作好。
9	圖形界面的工具備它的長處，可是不要忘了命令行工具也能夠發揮很高的效率，特別是能夠用腳本構建各類組合命令的時候。	正在學習命令行工具
10	有不少代碼編輯器，請把其中一個用得很是熟練。讓編輯器能夠實現本身的定製，能夠用腳本驅動，用起來駕輕就熟。	隨意
11	理解經常使用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麼，何時用，何時不用。	歷來沒據說過
12	代碼版本管理工具是你代碼的保障，重要的代碼必定要有代碼版本管理。	領導要求才用
13	在debug的時候，不要驚慌，想一想致使問題的緣由可能在哪裏。一步一步地找到緣由。要在實踐中運用工具，善於分析日誌（log），從中找到bug。同時，在本身的代碼裏面加 log.	歷來沒據說過
14	重要的接口要用形式化的「合同」來規定。用文檔和斷言、自動化測試等工具來保證代碼的確按照合同來作事，很少也很多。使用斷言 (assertion) 或者其餘技術來驗證代碼中的假設，你認爲不可能發生的事情在現實世界中每每會發生。	歷來沒據說過
15	只在異常的狀況下才使用異常 (Exception), 不加判斷地過多使用異常，會下降代碼的效率和可維護性。記住不要用異常來傳遞正常的信息。	若是有明確要求，我能夠作好
16	有始有終。若是某個函數申請了空間或其餘資源，這個函數負責釋放這些資源。	有時這樣作
17	當你的軟件有多種技術結合在一塊兒的時候，要採用鬆耦合的配置模式，而不是要把全部代碼都混到一塊兒。	歷來沒據說過
18	把經常使用模塊的功能打形成獨立的服務，經過良好的界面 (API) 來調用不一樣的服務。	若是有明確要求，我能夠作好
19	在設計中考慮對並行的支持，這樣你的API 設計會比較容易擴展。	考慮在適當的層次支持並行
20	在設計中把展示模塊 (View) 和實體模塊 (Model) 分開，這樣你的設計會更有靈活性。	隨緣啦
21	重視算法的效率，在開始寫以前就要估計好算法的效率是哪個數量級上的（big-O）。	主動測試程序效率，以驗證估算
22	在實際的運行場景中測試你的算法，不要停留在數學分析層面。有時候一個小小的實際因素 (是否支持大小寫敏感的排序，數據是否支持多語言)會致使算法效率的巨大變化。	想用，但不知道工具
23	常常重構代碼，同時注意要解決問題的根源。	歷來沒據說過
24	在開始設計的時候就要考慮如何測試 ，若是代碼出了問題，有log 來輔助debug 麼? 儘早測試，常常測試，爭取實現自動化測試，爭取每個構建的版本都能有某些自動測試。	一直主動這樣作
25	代碼生成工具能夠生成一堆一堆的代碼，在正式使用它們以前，要確保你能理解它們，而且必要的時候能debug 這些代碼。	一直主動這樣作
26	和一個實際的用戶一塊兒使用軟件，得到第一手反饋。	一直主動這樣作
27	在自動測試的時候，要有意引地入bug，來保證自動測試的確能捕獲這些錯誤。	若是有明確要求，我能夠作好
28	若是測試沒有作完，那麼開發也沒有作完。	一直主動這樣作
29	適當地追求代碼覆蓋率：每一行的代碼都覆蓋了，可是程序未必正確。要確保程序覆蓋了不一樣的程序狀態和各類組合條件。	一直主動這樣作
30	若是團隊成員碰到了一個有廣泛意義的bug, 應該創建一個測試用例抓住之後將會出現的相似的bug。	一直主動這樣作
31	測試：多走一步，多考慮一層。若是程序運行了一星期不退出，若是用戶的屏幕分辨率再提升一個檔次，這個程序會出什麼可能的錯誤?	一直主動這樣作
32	（帶領團隊）瞭解用戶的指望值，稍稍超出用戶的指望值，讓用戶有驚喜。	不但主動作， 還會影響同事一塊兒作好
33	（帶領團隊） 不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過期的假設、對用戶的誤解或其餘因素所遮擋。	不但主動作， 還會影響同事一塊兒作好
34	（帶領團隊）把全部的術語和項目相關的名詞、縮寫等都放在一個地方。	不但主動作， 還會影響同事一塊兒作好
35	（帶領團隊）不要依賴於某我的的手動操做，而是要把這些操做都作成有相關權限的人士都能運行的腳本。這樣就不會出現由於某人休假而項目被卡住的狀況。	不但主動作， 還會影響同事一塊兒作好
36	（帶領團隊）要讓重用變得更容易。一個軟件團隊要創造一種環境，讓你們有輕鬆的心態來嘗試各類想法 （例如，模塊的重用，效能的提高，等）。	不但主動作， 還會影響同事一塊兒作好
37	（帶領團隊）在每一次迭代以後，都要總結經驗，讓下一次迭代的進度安排更可靠，質量更高。	不但主動作， 還會影響同事一塊兒作好
38	（帶領團隊）團隊中每每會有矛盾產生，做爲領頭人，怎麼辦？	不但有明確和一致的處理原則，並且對於影響團隊士氣的任何事情追究到底

2、回答問題

咱們在課程開始之初，曾經要求你們針對軟件工程提出問題：我的閱讀做業2，那麼在通過alpha階段，你們是否對軟件工程有了必定的瞭解？請結合本身提出的問題進行回答

1.在領導過程當中，如果出現團隊成員在開發中期與PM出現技術上的意見分歧，該如何處理？理論來講，PM更瞭解項目的大局和流程，且處於領導地位，而程序員可能不能顧全大局，但更瞭解當下開發中的實際問題。那麼該如何採起解決措施消除矛盾？若因最終出現失誤，該如何處理？

從咱們敏捷團隊開發的經驗來看，按期乃至每日的團隊會議很好的解決了這一問題，實現了團隊高效率的同步、交流和改進

2.代碼問題是工做中最直接的、最常發生的錯誤，爲什麼代碼問題不屬於風險？從結果考慮，這與第二句不是相互矛盾

的存在嗎？爲什麼做者反而將完美主義者定義爲「項目的風險」？

從團隊開發的經驗來看，咱們給代碼編寫、複審、測試、改進都留有合理充分的時間空間，所以代碼問題是能夠規避‘、改進的問題，不會給項目成敗最終帶來影響。追求完美反而會大大拖慢項目進程，下降效率。

3.在現現在編程軟件愈發豐富的時代，編程軟件自身或者許多第三方插件的設計者提供了不少能夠直接使用的

自動排版、模塊化等功能的插件，能夠直接實現自動化的規範處理，依賴這些工具，能夠大幅減小程序員，尤爲是
新程序員在這方面的時間消耗，既然如此，爲何不主動推廣此類功能的普遍應用，取代人工的操做呢？

咱們在開發過程當中，也使用到了不少輔助規範類工具，就好比博客的markdown編輯器，能夠用直觀方式對比效果。可是考慮到市場的碎片化發展，各類工具的利用可能反而會存在不可調和的誤差，而缺乏了審查規範的能力，反而會下降效率

3、再提問題

同時，你們必定會在實踐過程當中產生更多問題， 結合你的讀書（教材，博客，參考書）， 實踐， 再提出關於軟件工程的 5 個問題。

1.依然是關於創新，做者給出了常見的「創新的迷思」（p346），以及隨後小節的闡述，皆是圍繞什麼是創新、創新的思路方法，可是結合現有的生活實際，現實中不乏不少「僞創新」「賣概念」的套路存在，那將如何區分「真創新」與「賣概念」？

2.當軟件開發團隊在項目配合上出現差錯，而未被前期檢查發現，在實際運用階段暴露問題，該如何解決。

3.「有人說一我的就能夠快速成長爲一名全棧工程師，這讓我想起街頭賣藝的單人樂隊(One-man-band), 他們什麼都會一些，能夠很快地演奏一些曲子。 (Page 57)"很明顯我的能力全面發展是不可能實現的，全能選手雖然都會，但不可能作到精通，那麼爲何咱們如今的計算機學習也是在各個方面都有學習呢，大量的，各個方向的淺嘗輒止的學習又會大量影響發展自身重點方向的時間分配，這樣安排的用意是什麼呢？咱們進行專業地、重點的培養不是能夠更有效的提高本身的能力嗎

4.結對成員必定要區分出強弱進行結對麼？每一個人負責的任務各有不一樣，有的人任務可能難度較高，好比設計、某模塊編寫，但內容量少，有的人可能負責一些調試處理、任務統籌、博客撰寫、數據收集，看似難度較低，可是複雜繁瑣，任務量也龐大，那麼在區分貢獻度時候，如何才能保證公平合理使人信服？

5.需求分析中提到「從用戶等軟件產品的利益相關着分析需求」（p159）、「用戶調研獲取用戶需求」。通常的用戶需求，好比軟件系統的某項功能，若是這項功能不是大衆功能，可是隻有少數用戶在用戶需求中提出，那麼是否還要去花費成本進行開發呢？在我看來，如果開發，則會額外付出一部分紅本，可是使用率很低，若忽視該少數需求，那麼這類用戶的需求得不到知足，此類用戶倒是對產品反饋最活躍、潛在影響力最高的用戶。