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

1、我的總結

自我評價表

類別	具體技能和麪試問題	如今的回答	畢業找工做
語言	最拿手的計算機語言之一，代碼量有多少	java，三千左右
語言	最拿手的計算機語言之二，代碼量有多少	C，一千五左右
軟件實現	（閱讀代碼的能力，實現，單元測試）有沒有在別人的代碼基礎上進行改進，你是怎麼讀懂別人的代碼，你採起什麼方法不影響原來的功能？你在開發中遇到的最複雜bug是什麼，怎麼解決的？這個bug出現的緣由是什麼，你在將來應該怎麼避免bug的再出現？	有；就是看完直接去理解，百度，詢問大佬；先和別人作好溝通，在儘可能作到不修改其已經完成的功能，不佔用其功能；目前還未遇到特別複雜的bug。
軟件測試	（測試方法、測試工具、測試實踐、代碼覆蓋率）你是怎麼測試本身的代碼？怎麼測試別人的代碼？你掌握了多少種測試工具和方法？你寫過測試工具麼？你如何對一個網站進行壓力測試和效能測試？你如何測試一個軟件的人機界面（UX/UI）？	添加測試用例；添加測試用例；會在eclipse上作簡單的測試，還會使用一些小測試工具。
效能分析	（效能分析，效能改進）你寫過的最複雜的代碼是什麼？你是如何測量和改進它的效能的，用了什麼工具，如何分析的？	最複雜的應該就是大二下的Java課設了，那下作的是博客園學生成績分析，我主要負責echart圖表的代碼，那次確實是寫的比較困難的一次。
需求分析	（需求分析、典型用戶、場景、創新）你作過多少個有實際用戶的項目，用戶最多有多少？你的項目有什麼創新的地方？	以前未作過有關項目。此次軟工的24點小遊戲算是第一次除課設外的項目，仍是有不少學到的地方。
行業洞察力	你最感興趣的領域是什麼？這個領域過去十年有什麼創新？你分析過這個領域前十的產品嗎？請分析一下他們的優劣，你要進入這個領域，如何創新？	最感興趣的應該是人工智能還有數據挖掘這一方面的內容吧，近年來，人工智能和數據挖掘正在不斷地發展成爲社會最火熱的領域，有很是光明的前途。但我尚未具體去了解過這些領域的產品。我之後。。應該進不了這個領域，技術不行，靜不下心來。
項目管理	你參加過項目管理嗎？如何決定各個任務的優先順序？若是項目不能及時完成，你要怎麼辦？	未參與過；若是是個人話，我會先和項目組開個會，肯定全部任務的輕重緩急，作好任務時間安排表，以重要程度爲主要指標；先完成最重要的功能，其他以後補救。
軟件設計	你作過架構設計，模塊化設計，接口設計麼？請說明一下你爲什麼是這樣設計，你比較過什麼不一樣的設計方式，你的設計取得了什麼結果?	作過，在課設期間有作過模塊化設計和接口設計；由於這樣設計可讓代碼變得易懂，功能也變得易懂，修改代碼時會減少不少的工做。
質量意識	（代碼複審/代碼規範/代碼質量）你是怎麼作代碼複審的，你加入咱們團隊後，能幫咱們提升代碼質量麼，請具體說明怎麼提升？	作代碼複審的前提就是不能把原有的功能怕破壞，而後將冗餘的代碼刪除，同時用建立接口的方式來提升代碼質量。
工具/社區	Software Tools(performance too l,version control,work item,TFS)你在各類開發平臺（web,linux,PC,mobile,macheine learning）都使用過什麼樣的工具，本身寫過什麼工具來改進工做效率？給社區貢獻過什麼工具和代碼？GitHub有分享代碼麼?你寫的技術博客堅持了多久，讀者最多的是哪一篇？	eclipse、codeblocks、devc++、vs2010等；未貢獻；沒分享過；堅持了一年多；應該是java做業的第一篇。
團隊協做	Work with others（協同合做，提供反饋，說服別人）請描述你在項目中如何說服同伴採起你更好的方案，或是聽取別人的意見改進本身的方案？如何說服懶惰的同伴加緊工做	經過開會來進行具體商討；通常不須要說服，由於博客園的deadline真的很可怕。
理論素養	你上過什麼數學，計算機或是理論課，舉出具體的例子，如何幫你解決問題	高等數學、離散數學、線性代數、機率論、計算機組成原理、操做系統、數據結構等；例如不少算法好比二叉樹、冒泡等等，解決了不少問題。
自我管理	整年級你專業排名多少？你從剛入學（大學一年級）到如今排名有變化麼？如何解釋你的排名的變化？	光算加權的話四十多吧，算上綜測能夠排到前十五。剛入學大一到大二一直是逐步上升，從30多到前十，但大三上就掉到了四十多。因爲學習的壓力和學生工做的壓力愈來愈大，有點忙乎不過來了，而且也肯定了本身之後的方向應該不會往it發展了。

1.(d) 保持高標準，不要受制於破窗理論(broken windows theory)[i]。當你看到不靠譜的設計、糟糕的代碼、過期的文檔和測試用例的時候，不要想 「既然別人的代碼已經這樣了，個人代碼也能夠隨便一點啦。
a)歷來沒據說過；
b)我就是這樣隨便過來的；
c)若是有明確要求，我能夠作好。
d)一直主動這樣作
e)不但主動作， 還會影響同事一塊兒作好

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

a) 不懂啥是靠譜的設計；

b) 隨便應付一下便可；

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

d) 一直主動這樣作

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

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

a) 歷來不看書；

b) 看了就忘；

c) 有時分享。

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 據說過，可是認爲意思不大；

c) 這要講場合。

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 出了問題再說吧；

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

d) 可以在多種語言和架構中作到

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

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

a) 歷來沒據說過；

b) 把原型直接用於產品，否則就浪費了；

c) 不用原型，一直在產品中直接改。

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 按個人想法設計，用戶之後會適應的；

c) 大概贊成，可是怎麼接近用戶呢？

d) 一直主動這樣作

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

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

a) 作完了，就知道花費了，不用事先估計；

b) 大概估一下，沒必要在乎時間

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

d) 一直主動這樣作

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

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

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

a) 歷來沒據說過；

b) 只會printf；

c) 加log 太麻煩，個人代碼不會有bug 的。

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 太麻煩，不用；

c) 想用，但沒有時間。

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 抓住全部異常

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

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 隨緣；

c) 有時這樣作。

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 沒有實踐的機會；

c) 代碼都在一塊兒比較好管理。

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 拷貝代碼過來用也能夠

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

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 並行不會出錯的；

c) 任何代碼都應支持並行。

d) 考慮在適當的層次支持並行

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

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

a) 代碼都在一塊兒比較好改；

b) 隨緣啦；

c) 沒搞清楚啥是V，啥是M。

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 個人數據量不大，無所謂；

c) 不會有效率問題的，如今CPU 都快了。

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

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

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

a) 歷來沒據說過；

b) 想用，但不知道工具

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

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 任何修改均可以叫重構；

c) 天天應該重構兩次。

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 個人代碼不會出問題的；

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

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 歷來不看那些代碼；

c) 那些代碼沒有bug。

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 用戶太蠢，不值得聽反饋；

c) 想作可是沒有機會。

d) 一直主動這樣作

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

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

a) 沒據說過；

b) 沒必要這麼麻煩；

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

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 簽入代碼，就是作完了；

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

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 覆蓋20% 就行了；

c) 要覆蓋至少60%。

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 每一個bug都是特殊的；

c) 測試用例不值得加

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 若是有問題，用戶會報告的，咱們不用測這些；

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

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 咱們決定用戶的指望；

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

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 用戶不說的，咱們不作；

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

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 都記在我腦子裏；

c) 你們看代碼就好

d) 一直主動這樣作

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

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

a) 歷來沒據說過；

b) 咱們沒有休假的，不要緊；

c) 出了問題再說

d) 一直主動這樣作

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

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

a) 都聽領導的；

b) 團隊嚴肅緊張最好；

c) 沒必要嘗試，失敗的可能性太大。

d) 一直主動這樣作

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

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

a) 沒有時間總結，直接作下一版；

b) 總結用處不大；

c) 若是上級有要求，就作一下；

d) 一直主動這樣作

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

38.(e)（帶領團隊）團隊中每每會有矛盾產生，做爲領頭人，怎麼辦？

a) 我沒看見矛盾。

b) 和稀泥，過得去就行 ；

c) 若是沒有捅到上級那裏，就打哈哈，但願他們本身搞定；

d) 有明確和一致的處理矛盾的原則

e) 不但有明確和一致的處理原則，並且對於影響團隊士氣的任何事情追究到底

2、回答問題

Q1: 1.2 軟件工程是什麼（第一章「概論」）P22
「軟件工程是把系統的、有序的、可量化的方法應用到軟件的開發、運營和維護的上的過程。軟件工程包括下列領域：軟件需求分析、軟件設計、軟件構建、軟件測試和軟件維護。軟件工程和下列的學科相關：計算機科學、計算機工程、管理學、數學、項目管理學、質量管理、軟件人體工學、系統工程、工程設計和用戶界面設計。」

以上是書中原文對軟件工程的解釋。
講實話，若是沒學這本書，我不會想到軟件工程有包含這麼多知識點。我最早開始，認爲這門課可能就是教一教咱們如何去開發一個軟件，而後就是無窮無盡的打代碼。但上完兩堂課後，我發現我錯了，這門課並非要讓你真正的去無盡的編程，而是想讓看這本書的人去學會軟件開發流程的思想。"軟件 = 程序 + 軟件工程"，這本書，從基本概念到職業規劃，從瀑布模型到敏捷開發，從軟件測試到質量保證，從代碼規範到用戶體驗，只要是軟件開發會涉及的方面，這本書都涉及到了。可是我一直都有一個疑問，那就是軟件工程爲何須要掌握這麼多思想？這對之後的實際軟件開發會帶來多少的好處？

answer:通過了alpha階段和結對編程的洗禮，我算是慢慢理解軟件工程這門課爲何要咱們學習這麼多思想了，由於之後若是咱們走軟件開發行業，這種模式是必定要學會的，而如今先經過這門課讓你提早感覺，提早熟悉，對從此實際工做會帶來很大的好處，你的過渡期會短很是多。

Q2: 2.1.2 好的單元測試的標準（第二章「我的技術和流程」）P41
"單元測試應該覆蓋全部代碼路徑
單元測試應覆蓋所測單元的全部代碼路徑，包括錯誤處理路徑。爲了保證代碼覆蓋率，單元測試必須測試公開的和私有的函數和方法。…………100%的代碼覆蓋率並不等同於100%的正確性！"

對於我這種代碼白癡，我想提的第一個問題：什麼是代碼覆蓋率？（。。。）
第二個問題：100%的代碼覆蓋率並不等同100%的正確性，那麼要怎麼樣才能保證100%的正確性？

answer:在軟件開發的過程當中，我發現代碼根本沒辦法達到100%的正確性，咱們軟件開發的第一個指標，就是用戶需求，而用戶需求又有不少不一樣的意見，因此代碼不可能達到100%的正確性。

Q4: 4.5.2 爲何要結對編程？（第四章「兩人合做」）P89

其實，書中的原文已經將結對編程的好處說得十分清楚了，我也明白做者的意思。但我以爲，做者的想法一切都是理想化的。若是將結對編程放在咱們現實的學習中，結對編程真的會對咱們形成很大的益處嗎？

• 若是兩個編程經驗都很少的同窗結了對子，是否是就等於這一對垮了呢？
• 若是是「一神帶一坑」，這個編程能力較高的同窗，會不會以爲這種方式拖累了他的軟件開發過程？
• 若是二者出現分歧，而且誰都只認同本身的見解時，結對編程是否是就沒什麼優勢可言了？

answer:我以爲關於這個問題，能夠說結對編程對於咱們在開發的過程當中起到了很是大的做用，兩個編程經驗都很少的同窗，能夠經過互相督促，而後一塊兒提高。「一神帶一坑」能夠經過神將坑帶回正規，你們一塊兒共同提升。而二者出現了分歧，也能夠經過協商調解，而找到各自相互配合的最佳狀態！

3、再提問題

（1）關於PM的問題
PM實際上是項目開發過程當中很是重要的角色，對於項目的推動有很是重要的做用。那我想問，如何才能作好一名優秀的PM？

（2）關於團隊編程總體運做的問題
就像我上次在結對編程裏的問題同樣，團隊編程真的能讓每一個人受益嗎？如今我敢給出確定的答案，這是確定的，團隊編程讓團隊裏的每個人都體驗了實際軟件開發的過程，正如前面所說，這確實是會減小以後的過渡期。可是我想問，如何才能將團隊裏每一個成員的做用最大化？

（3）關於軟件工程對於同窗們從此走上社會的影響。
我一直一直相信着，軟件工程這門課是一門很是優秀，對同窗們從此的軟件開發過程當中有很是大做用。可是，若是是對於從此不往軟件開發這一方面走的同窗們呢？有的須要準備考研、考公、六級，有的還要準備出國，若是他們之後走的都不是本專業，軟件工程這門課還會對他們從此形成很大的影響嗎？我想問這究竟會形成什麼影響？

（4）關於博客撰寫佔用過多時間的問題。
講真話，博客園真的是我大學以來接觸過最厲害的做業了。從大一的一週一篇，到如今的一週三四篇，對於有的同窗多是一週一篇，就感受一週的時間所有被博客園佔據，若是說只有博客園做業那就還好，可是咱們linux有實驗報告、windows有實驗報告、網安有實驗報告、系統集成有實驗報告、這兩門課還有很是困難的做業要完成，真的開始有一些力不從心。但我以爲，既然我選擇了這門課，我就應該堅持下去，我應該用心去體驗這一次的過程！

（5）關於我對軟件工程這麼課的見解。
對於個人話，我仍是認爲軟件工程這門課是一門很是好的課程，這一切的一切，仍是要感謝張敏老師和鄒欣老師的提點。很是感謝大家讓我在大學生涯度過了一段很是不同、難忘的時光！！

附加題

請將問題提交至豆瓣：https://book.douban.com/annotation/56778873/