一、個人總結
在alpha 結束之后， 每位同學寫一篇個人博客， 總結自己的alpha 過程；
請用自我評價表：http://www.cnblogs.com/xinz/p/3852177.html 有比較才會有進步。
| 類型 | 具體技能和面試問題 | 現在的回答 | 畢業時找工作 |
|---|---|---|---|
| 語言 | 最拿手的計算機語言之一（偏前端），代碼量是多少 | js,代碼量大概2,3千左右 | |
| 語言 | 最拿手的計算機語言之二（偏后端），代碼量是多少 | java,代碼量大概1萬左右 | |
| 軟件實現 | 有沒有在別人的代碼基礎上進行改進，你是怎么讀懂別人的代碼的， 你采取什么方法來保證你的新功能不會影響原來的功能， 你在開發中碰到最復雜的bug是什么，你是如何解決的？ 這個bug出現的原因是什么，你在將來應該怎么去避免bug再出現 |
1.有，可以說滿經常； 2.讀懂別人的代碼分兩種情況，一種是寫代碼的本人在你旁邊（這是目前比較常見的情況），最簡單的辦法是直接問寫代碼本人代碼寫了什么。 另一種是寫代碼本人你問不到，這就首先要根據代碼的注釋，其次根據函數命名可以大概知道函數的功能，最后是運行一下，看運行結果也能知道代碼在寫什么； 3.大的框架不變，只修改要改進模塊的代碼，函數的返回值如果有修改，調用函數的地方都要相應修改 4.遇到的bug有的是原有代碼就存在的bug，有的是改進的代碼與原有的代碼函數結果不一致。解決的辦法可以直接寫幾句輸出代碼，看看問題出現在哪個范圍的代碼，如果是Java寫的，可以用Java的調試，就可以一步步看代碼的運行結果。 |
|
| 測試軟件 | 你如何測試自己的代碼？ 你如何測試別人的代碼？ 你掌握了多少種測試工具和方法？ 你寫過測試工具么？ 你如何對一個網站進行壓力測試和效能測試？ 你如何測試一個軟件的人機界面（UX/UI）？ |
1.測試自己代碼就可以先寫測試用例看看能不能得到自己想要的結果，或者使用測試工具，比如java自帶的測試工具，JUnit單元測試和代碼覆蓋率，效能分析可以用JProfier（但是其實這個軟件的測試結果，我分析起來還是蠻費勁的） 2.測試別人的代碼，主要要先懂得別人的代碼，其他的測試跟測試自己代碼是一樣的 3.目前掌握的測試工具有Java自帶的測試工具，測試方法有測試用例，代碼覆蓋率，可以在需要測試的代碼，寫一些輸出代碼，可以看代碼運行到哪 3.沒有寫過測試工具，因為也是學了軟工才對測試有概念 4.我還沒有寫過可實際運行的網站，所以也沒有進行過壓力測試和效能測試 5.沒有進行過真正的人機界面測試 |
|
| 效能分析 | 你寫過的最復雜的代碼是什么？你是如何測試和改進它的效能的，用了什么工具，如何分析？ | 1.我寫過最復雜的代碼就是學生選課系統，因為整個系統都是自己做的，時間就只有一周，考慮的問題有很多，比如，有多名選課數據的刷新，重復選課等。2.那時候還不懂得使用測試工具，寫完后能運行出想要的結果就結束了。現在的話，會使用測試用例進行測試，用JProfier進行效能分析。 | |
| 需求分析 | 你做過多少個有實際用戶的項目，用戶人數多少，你的項目有什么創新的地方？ | 目前有實際用戶的項目就是我們現在團隊開發的i詞匯，現在目前的用戶數量為43人。項目的創新在於把游戲與學習相結合，既能玩游戲又能學習，還能起到復習單詞的作用 | |
| 行業洞察力 | 你最感興趣的領域是什么？這個領域過去十年有哪些創新？ 你分析過這個領域前10的產品么？請分析一下他們的優劣，你要進入這個領域，應該如何創新 |
我最感興趣的領域是微信小程序。微信小程序是比較新的東西，也是近幾年才發展起來，與一開始的開發工具相比，現在的開放工具已經友好很多了。要是它的開發工具的有代碼調試或者報錯了可以指向錯誤的代碼就好了 | |
| 項目管理 | 你參加過項目管理嗎？請描述一下兩個當下流行的開發方法在你的項目中的具體應用情況 如何決定項目中各個任務的優先次序，有什么理論來支持你的做法？ 如果你突然發現項目不能按時完成，你作為項目領導，有什么辦法？ |
1.參加過項目管理。開發項目具體使用過的有主治醫師模式和敏捷開發。主治醫師模式在項目開發過程中一旦主要開發人員沒有進展，整個項目基本跨了，而敏捷開發，是大家一起開發，各有各的任務，周期也比較短，大家的積極性也比較高。 2.項目的任務的主次是根據團隊定義的MVP,屬於MVP版本的就是主要任務，不屬於MVP的任務屬於次要任務。因為敏捷開發就是先做出各可交付的版本。 3.如果突然發現項目不能按時完成，第一先尋求別人的幫助，如果還是很緊急，你那就調整項目的時間安排，通過增加工作時間來保證完成任務。如果覺得還是不能按時完成，就讓開發不是MVP版本功能的開發人員重新分配還未完成的任務。 |
|
| 軟件設計 | 你做過架構設計，模塊化設計，接口設什么？請說明一下你為何是這樣設計，你比較過什么不同的設計方式，你的設計取得什么結果？ | 我做過接口設計，這樣設計首先讓代碼看得很清楚，其次減少代碼的冗余。我還未使用過其他設計方法，所以無法進行比較 | |
| 質量意識 | 你是怎么做到代碼復審的，你加入團隊后，能幫助我們提高代碼質量么，請具體說怎么提高？ | 從代碼是否符合需求和規格說明，設計是否考慮周全，代碼可讀性高么，代碼容易維護么，代碼的是否有錯誤處理、邊界處理、資源利用等，代碼的效能如何等方面進行代碼復審。提高代碼質量首先要有代碼規范，其次要減少代碼冗余，對代碼進行模塊化設計和接口設計，做到一個功能寫一個函數，一個函數不要含有很多功能。 | |
| 工具/社區 | 你在各種開發平台都使用過什么工具，自己寫過什么工具來改進工作效率？給社區貢獻過什么工具和代碼？Github有分享代碼么？你寫的技術博客堅持了多久，讀者最多的是那一篇？ | 還未在開發平台使用過工具。主要是用碼雲來分享代碼。寫技術博客兩年了，讀者最多的篇章是201521123005 《Java程序設計》 第九周學習總結 | |
| 團隊協作 | 請描述你在項目中如何說服同伴采取你更好的方案，或是聽取別人的意見改進自己的方案？你如何說服懶惰的同伴加緊工作，實現團隊的目標？ | 我先講一下我的方案是什么，然后講我的方案有什么優點，為什么我要采取這種方案，與同伴互相交流彼此的想法。別人的意見，首先要聽懂並理解，根據自己方案的特點與需求，看是否要采納別人的意見，多與別人多交流，如果沒有采納別人的意見也要說出原因 | |
| 理論素養 | 你上過什么數學，計算機或是理論課， 請舉出具體的例子，說明你學到的理論知識如何幫助你解決實際問題。 |
1.大學學了高等數學、概率論、數學邏輯、離散數學等 2.哪最簡單的例子，數學邏輯學的，邏輯與或在寫MD5算法的時候就很好的運用，用最簡單的式子來表示算法過程，需要用與或表達式來化簡。 |
|
| 自我管理 | 全年級你專業排名多少？ 你從剛入學（大一年級）到現在的排名有變化么？ 如何解釋你的排名的變化？ |
1.我的專業排名波動比較大，目前專業排名第7。 2.有變化。 3.大一大二學的更多的是基礎課，專業課比較少。大一大二參加的社團也比較多。大三專業課比較多，花在學習上的時間也比較多。 |
二、回答問題
我們在課程開始之初，曾經要求大家針對軟件工程提出問題：個人閱讀作業2，那么在經過alpha階段，大家是否對軟件工程有了一定的了解？請結合自己提出的問題進行回答
個人閱讀作業2
Q1、通過好的單元測試就能說明程序是好的嗎？
經過alpha階段，實際測試后發現，通過好的測試單元雖然不能說明這個程序都沒有問題，但是它可以找出程序很多bug。項目本身就是一個不斷的找bug，修復bug的過程。可以這樣說沒有完全沒有bug的項目。現在我們也知道有些bug不是bug，而是項目本身就是如此設計的。所以好的測試單元還是很重要的，不要太糾結於它是否可以判定一個程序的好壞。程序的好壞應該進行效能分析，才更有信服。
Q2、有關敏捷流程的問題--如果在第一步沒有計划好，是否導致整個項目的失敗？
敏捷沖刺的好處就是它快，在Alpha階段開發出MVP版本就可以，然后在進行不斷的迭代。所以第一步沒有計划好會影響Alpha階段的具體事項，但是Alpha階段結束后它有一個總結，可以總結在第一階段沒有計划好，或者可以改進的地方，然后再進入Beta沖刺極段，這樣其實對整個項目的影響不會嚴重到失敗，可能會影響項目的進度。
Q3、對於軟件測試方法的理解--對於現實生活中的項目，這十三種測試都需要一個個測試嗎？
關於測試真的要應項目而異，因為不同的項目有不同測試要求。拿我們團隊Alpha階段的MVP版本來說，因為這個項目在Alpha階段還未連上數據庫，那還要進行服務器、數據庫的測試嗎？顯然就沒必要了，即使你測試了得出的結果也是無用的。比如測試數據庫的性能，你都沒有進行數據庫操作，如何測試？測試方法的存在提供了測試的方向，可以讓剛學習測試的學員，知道可以測試什么，用什么測試，測試的結果如何分析。
三、再提問題
同時，大家一定會在實踐過程中產生更多問題， 結合你的讀書（教材，博客，參考書）， 實踐， 再提出關於軟件工程的 5 個問題。
在每個問題后面，請說明哪一章節的什么內容引起了你的提問，提供一些上下文。
列出一些事例或資料，支持你的提問 。
說說你提問題的原因，你說因為自己的假設和書中的不同而提問，還是不懂書中的術語，還是對推理過程有疑問，還是書中的描述和你的經驗（直接經驗或間接經驗）矛盾？
一個模板可以是這樣：
我看了這一段文字 （引用文字），有這個問題 （提出問題）。 我查了資料，有這些說法（引用說法），根據我的實踐，我得到這些經驗（描述自己的經驗）。 但是我還是不太懂，我的困惑是（說明困惑）。【或者】我反對作者的觀點（提出作者的觀點，自己的觀點，以及理由）。
Q1、針對大學生的項目開發PM的角色是否適用？###
本書第194頁，作者提到
PM做開發和測試之外的所有事情
但是經過Alpha階段，我發現PM在團隊項目開發的過程中還是需要做開發的事情。因為團隊成員沒辦法做到每個人都有能力完成開發的事情，沖刺階段時間也趕，沒辦法空出一個人去只做PM的事情。團隊成員較少的情況下，只能一人承擔多個角色。就拿這次沖刺階段，我們團隊沒辦法安排出一個專門做測試的人員，隊員大家前期都是做開發的事情（包括PM),后期才轉去做測試的。所以導致了PM要做的事情很多。如果有的團隊的成員不給力，會不會最終項目都是PM一個人完成。這樣不就會出現主治醫師模式的弊病嗎？
作者在書196頁回答了問題：
如果PM也來開發，是不是項目進展更快？
作者的回答是
在軟件行業發展初期，軟件都是為了維持機器本身的運行服務，或是做科學計算，這時候也許看不出PM的作用。隨着產業的發展，軟件應用的深度和廣度、軟件的復雜度、軟件團隊的復雜度都有極大地提高了，這時候我們需要一些人，起到溝通、交換、影響、潤滑、討價還價的作用--就像商業社會的金錢一樣--PM就是這樣的角色。
我認為作者沒有回答到點上，這個問題問的是PM還可承擔開發的事情，來加快項目的進展，而不是問PM的重要性。我覺得在大學生開發項目，PM相當於一個小組長兼開發人員。因為PM需要對技術熟悉，你也沒辦法讓一個不會寫代碼來承擔PM的角色。
Q2、如何提高估計能力？
本書第181頁，作者提到
這時候，我們可以考慮參考前人的經驗，打聽一下當地人跨越大峽谷要幾天。
我第一次看到這章內容的時候覺得說得挺有道理的，就像我們做課設的時候，問一下上一屆的學長學姐，也可以大概對項目有一定的把握。但是我們團隊這次做的是微信小程序，因為這個技術比較新，有關這方面可以參考的資料，或者人比較少。
作者還說到
即使和你具體情況有種種區別，還是可以作為參考，例如你想徒步走遍全國，貌似前無古人，但是不妨看看一個騎自行車走遍全國的例子。
這種情況就好比我們數據庫的搭建。我們首先網上找了有關數據庫連接的資料，可以說很少有人親切的寫具體如何連接，相當於前人參考經驗幾乎為0。那就參考類似的比如用java連接數據庫，這個我們做過，覺得還挺簡單的，數據庫選的是MYSQL也接觸過。根據這些經驗，我們團隊計划連接數據庫最多兩天就可以了吧。結果與計划大不相同。造成這樣的結果，是我們高估自己的能力。所以光是參考前人的經驗是不夠的。
作者又說到
另一個辦法是快速原型法--用一兩個先鋒去探路。
首先對大學生很不友好，大學生做項目的時候選擇課題時候，並沒有那么長的時間讓你去試哪個項目的成功率更高。大家選的時候一般是先考慮項目內容而不是技術。然后選了課題后，真正要開發的時候才發現，哎呀這個技術好難啊，做不下去了。對於這種對技術了解不到位，沒有很好的前人參考經驗，如何去估計任務時間呢？
Q3、及時發布一個能夠解決用戶問題（應該說部分問題）的軟件，用戶願意使用嗎？
本書第180頁，作者提到
所有軟件公司都希望在修正所有缺陷之后才發布軟件。但是，第一，什么叫“缺陷”?如果只是一些無關大局的問題，用戶可以繞過去的，我們非要馬上解決么？第二，什么叫“改正”？如果修正方案又有“缺陷"怎么辦？做商用軟件的人都是為此苦惱，只有優秀的軟件公司能夠找到一個平衡點，及時發布解決用戶問題的軟件，並且能及時修改軟件中的問題--注意，這兩個"及時"並不一定是同一時間。
如果為了及時發布，發布了一個滿足部分用戶的軟件（比如書中提到的沒有復制粘貼功能的iPhone），用戶用了以后還會滿意嗎？我想起曹老師跟我們說的一個例子。他說他有個朋友開公司的，他說開發軟件就是要先開發出開胃菜，先穩住客戶，然后再端出滿漢全席。可是，用戶用了你的開胃菜，還會期待你的滿漢全席嗎？用戶用了以后，還會想再用你的軟件嗎？
Q4、工程師有可能高效地開發一個顧客不喜歡的軟件，那么這位工程師還是優秀的工程師嗎？
本書第36頁，作者提到
PSP的目的是記錄工程師如何實現需求的效率，而不是記錄顧客對產品的滿意度。工程師有可能很高效地開發一個顧客不喜歡的軟件（例如用戶界面很差，功能未能解決用戶實際問題，等等），那么這位工程師還是優秀的工程師嗎？
我不知道這是作者對讀者的問題，還是他覺得工程師有可能高效地開發一個顧客不喜歡的軟件，那么這位工程師不是優秀的工程師。但是，從角色分工來說，一個軟件開發不單單只有開發人員還有需求調研人員，測試人員，PM等，而開發人員就是專心寫代碼的人，他是不負責除開發以外的事情。工程師開發出一個用戶不喜歡的軟件，也不能說是工程師的錯，不應該把需求分析錯誤的問題扔給沒有進行需求調研，只是根據需求規格說明書安靜的寫代碼的工程師。從企業來說，能高效的開發軟件的工程就是他們所需要的，就是優秀的工程師那么一個工程師高效率的開發一個軟件，不就說明他是一個有優秀的工程師嗎？
Q5、關於IT行業的創新之創新就是冒險家？
在書的第16章，作者說了有關創新的八大迷思，在書347頁，作者提到
誰不喜歡創新呢？然而細細想來，創新就是做和以前不一樣的事情，那並不是所有人都喜歡”不一樣“
歸根結低，都是要看創新出來的”不一樣“是否符合自身利益。這不意味着你的創新有可遇到失敗。就像移動公司走的TD-ScDMA的技術,理論上這個技術是很優秀的，但是移動公司推行開始技術就不成熟，又有很多新的技術出現，如4G、WLAN。這不就意味着，創新是有風險的。
但是在書347頁，作者提到
其實根據研究，創新人士的關鍵點不是喜歡冒險，也不是躲避風險，而是從錯誤中恢復繼續努力，就像文言文說的”屢戰屢敗“。
如果對於一個可能性幾乎為0的創新，還要繼續堅持下去嗎？我們現在知道創新成功的例子都是創新成功后，大家才知道的，但是還有很多創新后就失敗的真實案例。大家都一味的追求創新，是否是正確的？既然創新大家都想要，那么為什么教育又是應試教育？這是否意味着，創新是冒險？
【附加題】
請將問題提交至豆瓣：https://book.douban.com/subject/27069503/，
並在博客中給出鏈接在豆瓣頁面的最下方 “讀書筆記” 那里發言， 《構建之法》的作者會親自答復問題
