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

時間 2019-12-09

原文原文鏈接

1、我的總結

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

2.請用自我評價表：http://www.cnblogs.com/xinz/p/3852177.html 有比較纔會有進步。

第一部分硬的問題html

類別	具體技能和麪試問題	如今的回答 (大三)
語言	最拿手的計算機語言之一,代碼呈多少? (偏web前端， PC/Mobile App)	js，代碼量（沒有概念，學習的時候和課設的時候編寫過）
語言	最拿手的計算機語言之二,代碼量多少? (偏後端，數據處理,網站後臺機器學習，等)	java，代碼量：大概一兩千，兩三千（爲何大家都明確本身的代碼量？）
軟件實現	(閱讀代碼的能力，實現，單元測試) 1.你有沒有在別人代碼的基礎上改進? 2.你是怎麼讀懂別人的代碼的? 3.你採起了什麼辦法來保證你的新功能不會影響原來的功能? 4.你在開發中碰到最複雜的bug是什麼? 5.你是如何解決的? 6.這個bug出現的緣由是什麼? 7.你在未來應該怎麼去避免bug再出現?	1.有在別人代碼的基礎上改進 2.先讀懂主要功能 3.多運行看本身的新功能是否對原來功能產生影響 4.編譯時的各類報錯 5.根據報錯的內容一步一步修改（有的時候真的很苦惱） 6.大部分緣由是本身不熟悉對於命令的使用 7.多學習多練習
軟件測試	(測試方法、測試工具測試實踐代碼覆蓋率) 1.你如何測試你本身寫的代碼? 2.你如何測試別人的代碼? 3.你掌握了多少種測試工具和方法? 4.你寫過測試工具麼? 5.你如何對一個網站進行壓力測試和效能測試? 6.你如何測試一個軟件的人機界面(Ux/UI) ?	1.編譯運行使用JUnit4 2.編譯運行使用JUnit4 3.JUnit4 4.沒有 5.利用壓力測試工具和效能測試工具 6.利用相應軟件並查看執行效果
效能分析	(效能分析，效能改進) 1.你寫過的最複雜的代碼是什麼? 2.你是如何測量和改進它的效能的，用了什麼工具，如何分析的?	1.象棋 2.根據運行狀況以及JUnit4測量，用的工具是Junit4，通常根據運行時間以及運行狀況（是否出錯）進行分析
需求分析	(需求分析，典型用戶，場景，創新) 1.你作過多少個有實際用戶的項目，用戶最多有多少? 2.你的項目有什麼創新的地方?	沒有作過有實際用戶的項目
行業洞察	1.你最感興趣的領域是什麼? 2.這個領域過去10年經歷了哪些創新? 3.你分析過這個領域前10名產品麼?請分析一下他們的優劣。 4.你要進入這個領域，應該如何創新?	1.設計領域 2.各類設計層出不窮 3.沒有 4.抓住用戶的痛點
項目管理	1.你參與過項目管理麼?請描述一下兩個當下流行的開發方法在你的項目中的具體應用狀況; 2.請問你如何決定項目中各類任務的優先次序，有什麼理論來支持你的作法 3.若是你忽然發現項目不能按時完成，你做爲項目領導，有什麼辦法?	1.參與過。敏捷開發：根據相應的迭代促進項目的進行；MVP：項目中儘可能先完成最核心的功能 2.首先是根據每一個項目中打基礎的任務最早完成，其次核心功能的相關任務優先完成，最後完成其餘功能的相應任務。 3.首先與團隊商量對策，若是加班加點也沒法完成就只能相應的刪減一些非必要的任務，好比界面設計等等，保證其核心功能的完整度
軟件設計	1.你作過架構設計，模塊化設計，接口設計麼? 2.請說明一下你爲什麼是這樣設計，你比較過什麼不一樣的設計方式，你的設計取得了什麼結果?	1.在設計項目時的架構設計/在程序編寫時的模塊化設計和接口設計（就只是作過皮毛） 2.架構設計瞭解總體構造，便於具體實施項目；模塊化設計能夠保證整個項目的完整度；接口設計能夠減小沒必要要的代碼，使程序更簡潔明瞭。應該沒有作過其餘的設計方式，可能作了也不知道叫什麼（好比這三種）。
質量意識	(代碼複審/代碼規範/代碼質量) 你是怎麼作代碼複審的，你加入咱們團隊後，能幫咱們提升代碼質量麼，請具體說怎麼提升?	代碼複審從需求和規格說明/代碼設計/效能/可維護性/可讀性等方面進行。要提升代碼質量，要明確每一行代碼存在的必要性，儘可能不寫冗餘的代碼；再從代碼規範着手，以便於往後修改和查看。
工具/社區	Software Tools (performance tool, version control, work item, TFS) 1.你在各類開發平臺(web, linux, PC， mobile, machine learning)都使用過什麼樣的工具， 2.本身寫過什麼工具來改進工做效率? 3.給社區貢獻過什麼工具和代碼? 4.Github有分享代碼麼? 5.你寫的技術博客堅持了多久，讀者最多的是哪一篇?	1.如題例舉的開發平臺上好像沒有用過什麼工具（用過也忘了） 2.本身沒有寫過改進工做效率的工具 3.工具-沒有/代碼-存在碼雲，應該可共享 4.Github沒有分享代碼 5.博客做業算是技術博客的話，應該是一年；讀者最多的是201521123094 《Java程序設計》第1周學習總結
團隊協做	Work with others (協同工做，提供反饋，說服別人) 1.請描述你在項目中如何說服同伴採用你提出的更好的解決方案，或者你如何聽取了別人的意見，改進了本身的方案? 2.你如何說服懶惰的同伴加緊工做，實現團隊的目標?	1.在項目中咱們都是一塊兒討論解決方案，從中選優；或挑選最優的點子組成解決方案 2.將屬於他的任務分配給他，並要求按時完成；在你們作任務的時候也會不斷催促他進行本身的任務。
理論素養	你上過什麼數學,計算機或其餘理論課，請舉出具體的例子，說明你學到的理論知識如何幫助你解決實際問題。	高數/機率論/線性代數/數字邏輯/離散數學…… 算法的思想在各類編程中都起到了較大的做用，解決問題時多方面應用學到的算法
自我管理	1.整年級你專業排名多少? 2.你從剛入學(大學一年級)到如今的排名有變化麼? 3.如何解釋你的排名的變化	1.從大三上學期的成績來看目前綜合排名13 2.有變化 3.剛入學心態還在放鬆狀態，以後經過本身的努力慢慢進步；其餘同窗有轉向其餘專業的意向（畢竟大三要開始謀出路）

第二部分：軟的問題（這份問卷感受有的沒有合適本身的選項）前端

保持高標準，不要受制於破窗理論(broken windows theory)。
當你看到不靠譜的設計、糟糕的代碼、過期的文檔和測試用例的時候，不要想「既然別人的代碼已經這樣了，個人代碼也能夠隨便一點啦。」java
a) 歷來沒據說過； b) 我就是這樣隨便過來的； c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
主動解決問題。當看到不靠譜的設計，糟糕的代碼的時候，不要想「可能別人會來管這個事情」，或者「我下個月發一個郵件讓你們討論一下」。要主動地把問題給解決了。linux
a) 不懂啥是靠譜的設計； b) 隨便應付一下便可； c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
常常給本身充電，身體訓練是運動員生活的一部分，學習是軟件工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。經過按期分享（面對面的分享，寫技術博客等）來確保本身真正掌握了新技術。web
a) 歷來不看書； b) 看了就忘； c) 有時分享。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: c
DRY （Don't Repeat Yourself）——別重複。在一個系統中，每個知識點都應該有一個無異議的、正規的表現形式。面試
a) 歷來沒據說過； b) 據說過，可是認爲意思不大； c) 這要講場合。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
消除不相關模塊之間的影響，在設計模塊的時候，要讓它們目標明確並單一，能獨立存在，沒有不明確的外部依賴。算法
a) 歷來沒據說過； b) 出了問題再說吧； c) 想作，可是不知道怎麼衡量效果。 d) 可以在多種語言和架構中作到 e) 不但主動作，還會影響同事一塊兒作好
Selection: c
經過快速原型來學習，快速原型的目的是學習，它的價值不在於代碼，而在於你經過快速原型學到了什麼。編程
a) 歷來沒據說過； b) 把原型直接用於產品，否則就浪費了； c) 不用原型，一直在產品中直接改。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
設計要接近問題領域，在設計的時候，要接近你目標用戶的語言和環境。小程序
a) 歷來沒據說過； b) 按個人想法設計，用戶之後會適應的； c) 大概贊成，可是怎麼接近用戶呢？ d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
估計任務所花費的時間，避免意外。在開始工做的時候，要作出時間和潛在影響的估計，並通告相關人士，避免最後關頭意外發生。工做中要告知可能的時間變化，過後要總結。windows
a) 作完了，就知道花費了，不用事先估計； b) 大概估一下，沒必要在乎時間 c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: c
圖形界面的工具備它的長處，可是不要忘了命令行工具也能夠發揮很高的效率，特別是能夠用腳本構建各類組合命令的時候。
a) 一直用鼠標和GUI； b) 到時候問牛人； c) 正在學習命令行工具。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: c
有不少代碼編輯器，請把其中一個用得很是熟練。讓編輯器能夠實現本身的定製，能夠用腳本驅動，用起來駕輕就熟。
a) 只用老師教的一個； b) 隨意； c) 沒有任何定製。 d) 會定製，而且分享給其餘人 e) 還會學習和使用各類編輯器的擴展。
Selection: c
理解經常使用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麼，何時用，何時不用。
a) 歷來沒據說過； b) 模式沒用； c) 每寫100行程序，我就儘可能用一個模式。 d)有實際使用的經驗 e) 能用具體代碼說明模式的利弊
Selection: b
代碼版本管理工具是你代碼的保障，重要的代碼必定要有代碼版本管理。
a) 歷來沒據說過； b) 用QQ，u盤便可； c) 領導要求才用。 d) 常常用 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
在debug的時候，不要驚慌，想一想致使問題的緣由可能在哪裏。一步一步地找到緣由。要在實踐中運用工具，善於分析日誌（log），從中找到bug。同時，在本身的代碼裏面加 log。
a) 歷來沒據說過； b) 只會printf； c) 加log 太麻煩，個人代碼不會有bug 的。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
重要的接口要用形式化的「合同」來規定。用文檔和斷言、自動化測試等工具來保證代碼的確按照合同來作事，很少也很多。使用斷言 (assertion) 或者其餘技術來驗證代碼中的假設，你認爲不可能發生的事情在現實世界中每每會發生。
a) 歷來沒據說過； b) 太麻煩，不用； c) 想用，但沒有時間。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: a
只在異常的狀況下才使用異常 (Exception), 不加判斷地過多使用異常，會下降代碼的效率和可維護性。記住不要用異常來傳遞正常的信息。
a) 歷來沒據說過； b) 抓住全部異常 c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: c
有始有終。若是某個函數申請了空間或其餘資源，這個函數負責釋放這些資源。
a) 歷來沒據說過； b) 隨緣； c) 有時這樣作。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
當你的軟件有多種技術結合在一塊兒的時候，要採用鬆耦合的配置模式，而不是要把全部代碼都混到一塊兒。
a) 歷來沒據說過； b) 沒有實踐的機會； c) 代碼都在一塊兒比較好管理。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
把經常使用模塊的功能打形成獨立的服務，經過良好的界面 (API) 來調用不一樣的服務。
a) 歷來沒據說過； b) 拷貝代碼過來用也能夠 c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: c
在設計中考慮對並行的支持，這樣你的API 設計會比較容易擴展。
a) 歷來沒據說過； b) 並行不會出錯的； c) 任何代碼都應支持並行。 d) 考慮在適當的層次支持並行 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
在設計中把展示模塊 (View) 和實體模塊 (Model) 分開，這樣你的設計會更有靈活性。
a) 代碼都在一塊兒比較好改； b) 隨緣啦； c) 沒搞清楚啥是V，啥是M。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: c
重視算法的效率，在開始寫以前就要估計好算法的效率是哪個數量級上的（big-O）。
a) 歷來沒據說過； b) 個人數據量不大，無所謂； c) 不會有效率問題的，如今CPU 都快了。 d) 主動測試程序效率，以驗證估算 e) 不但主動作，還會影響同事一塊兒作好
Selection: b (偶爾測試)
在實際的運行場景中測試你的算法，不要停留在數學分析層面。有時候一個小小的實際因素 (是否支持大小寫敏感的排序，數據是否支持多語言)會致使算法效率的巨大變化。
a) 歷來沒據說過； b) 想用，但不知道工具 c) 主要靠肉眼觀察算法效率。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: b/c
常常重構代碼，同時注意要解決問題的根源。
a) 歷來沒據說過； b) 任何修改均可以叫重構； c) 天天應該重構兩次。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: b (好像不是)
在開始設計的時候就要考慮如何測試，若是代碼出了問題，有log 來輔助debug 麼? 儘早測試，常常測試，爭取實現自動化測試，爭取每個構建的版本都能有某些自動測試。
a) 歷來沒據說過； b) 個人代碼不會出問題的； c) 項目沒有安排時間，我也沒有提這事。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
代碼生成工具能夠生成一堆一堆的代碼，在正式使用它們以前，要確保你能理解它們，而且必要的時候能debug 這些代碼。
a) 歷來沒據說過； b) 歷來不看那些代碼； c) 那些代碼沒有bug。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d(通常沒有進行debug)
和一個實際的用戶一塊兒使用軟件，得到第一手反饋。
a) 歷來沒據說過； b) 用戶太蠢，不值得聽反饋； c) 想作可是沒有機會。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: e
在自動測試的時候，要有意引地入bug，來保證自動測試的確能捕獲這些錯誤。
a) 沒據說過； b) 沒必要這麼麻煩； c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
若是測試沒有作完，那麼開發也沒有作完。
a) 歷來沒據說過； b) 簽入代碼，就是作完了； c) 。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: c (c大概是部分作完吧）
適當地追求代碼覆蓋率：每一行的代碼都覆蓋了，可是程序未必正確。要確保程序覆蓋了不一樣的程序狀態和各類組合條件。
a) 歷來沒據說過； b) 覆蓋20% 就行了； c) 要覆蓋至少60%。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
若是團隊成員碰到了一個有廣泛意義的bug, 應該創建一個測試用例抓住之後將會出現的相似的bug。
a) 歷來沒據說過； b) 每一個bug都是特殊的； c) 測試用例不值得加 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: b
測試：多走一步，多考慮一層。若是程序運行了一星期不退出，若是用戶的屏幕分辨率再提升一個檔次，這個程序會出什麼可能的錯誤?
a) 歷來沒據說過； b) 若是有問題，用戶會報告的，咱們不用測這些； c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: c
（帶領團隊）瞭解用戶的指望值，稍稍超出用戶的指望值，讓用戶有驚喜。
a) 歷來沒據說過； b) 咱們決定用戶的指望； c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
（帶領團隊）不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過期的假設、對用戶的誤解或其餘因素所遮擋。
a) 歷來沒據說過； b) 用戶不說的，咱們不作； c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
（帶領團隊）把全部的術語和項目相關的名詞、縮寫等都放在一個地方。
a) 歷來沒據說過； b) 都記在我腦子裏； c) 你們看代碼就好 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: c
（帶領團隊）不要依賴於某我的的手動操做，而是要把這些操做都作成有相關權限的人士都能運行的腳本。這樣就不會出現由於某人休假而項目被卡住的狀況。
a) 歷來沒據說過； b) 咱們沒有休假的，不要緊； c) 出了問題再說 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
（帶領團隊）要讓重用變得更容易。一個軟件團隊要創造一種環境，讓你們有輕鬆的心態來嘗試各類想法（例如，模塊的重用，效能的提高，等）。
a) 都聽領導的； b) 團隊嚴肅緊張最好； c) 沒必要嘗試，失敗的可能性太大。 d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
（帶領團隊）在每一次迭代以後，都要總結經驗，讓下一次迭代的進度安排更可靠，質量更高。
a) 沒有時間總結，直接作下一版； b) 總結用處不大； c) 若是上級有要求，就作一下； d) 一直主動這樣作 e) 不但主動作，還會影響同事一塊兒作好
Selection: d
（帶領團隊）團隊中每每會有矛盾產生，做爲領頭人，怎麼辦？

a) 我沒看見矛盾。 b) 和稀泥，過得去就行； c) 若是沒有捅到上級那裏，就打哈哈，但願他們本身搞定； d) 有明確和一致的處理矛盾的原則 e) 不但有明確和一致的處理原則，並且對於影響團隊士氣的任何事情追究到底
Selection: d

2、回答問題

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

1. 複雜性、易變性是什麼意思？怎麼樣的編程做業纔算加入了軟件特性？

Answer：複雜性主要仍是指超多的代碼量；易變性是指看上去容易修改可是實際並不容易修改。在我看來擁有軟件特性的編程做業應該有較多的代碼量，可擴展，不是徹底難以理解的程序。

2. RUP是什麼？

Answer：「RUP是一個通用的過程框架，適用於大型軟件的開發。它的突出特色是用例驅動，以架構爲中心，採用迭代和增量的開發策略。」簡單來講，就是一種開發方法。

3. 敏捷開發與RUP有什麼不一樣之處？

Answer：最主要的區別就是敏捷開發適用於小型項目，RUP適用於大型項目。

4.咱們在開發軟件的時候，要用到哪些測試方法？什麼階段用什麼方法？

Answer：單元測試[程序內部數據測試]，集成測試[單元測試以後]，效能測試[單元測試，整合測試以後]，迴歸測試[發生修改以後從新測試]，驗收測試[軟件測試過程的最後一步]等。

5. 爲何領域外更有創新者？

Answer：正所謂當局者迷旁觀者清。

（其實上述問題我在以前的博客也有給出相應的解答，這裏改進/增長了一些新的見解）

3、再提問題

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

1.在每一個問題後面，請說明哪一章節的什麼內容引發了你的提問，提供一些上下文。

2.列出一些事例或資料，支持你的提問。

3.說說你提問題的緣由，你說由於本身的假設和書中的不一樣而提問，仍是不懂書中的術語，仍是對推理過程有疑問，仍是書中的描述和你的經驗（直接經驗或間接經驗）矛盾？

一個模板能夠是這樣：
　　我看了這一段文字（引用文字），有這個問題（提出問題）。我查了資料，有這些說法（引用說法），根據個人實踐，我獲得這些經驗（描述本身的經驗）。可是我仍是不太懂，個人困惑是（說明困惑）。【或者】我反對做者的觀點（提出做者的觀點，本身的觀點，以及理由）。

4.【附加題】：請將問題提交至豆瓣：https://book.douban.com/subject/27069503/，並在博客中給出連接

在豆瓣頁面的最下方「讀書筆記」那裏發言，《構建之法》的做者會親自答覆問題

Question1：PM的工做究竟是什麼樣的？

教材上比較詳細的提到了PM是作開發和測試以外的全部事情：

典型的軟件團隊裏除了能寫代碼、測試代碼和畫圖作設計的成員，還有一類角色，不作上面這些事情但也很重要，咱們叫他們項目經理——PM。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《構建之法》第9章_9.1
可是我在Alpha階段彷佛誤解PM的工做，看到許多團隊的PM都在引領着每一個團隊，在開發上、流程上、心態上都須要付出很是多的精力。
那PM這麼作到底對不對呢？PM的工做究竟是什麼樣的？

Question2：怎麼樣的功能纔是MVP功能？

MVP——Minimum Viable Product，最小可行產品，又稱爲Minimal Feature Set，最小功能集。具體的作法是：把產品最核心的功能用最小的成本實現出來，而後快速徵求用戶意見。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《構建之法》第5章_5.3.6
咱們在項目的時候，雖然明確最重要的功能，可是用戶要使用的應該是咱們這個項目——整個項目，那咱們是否是應該將這個項目的所有功能簡單的實現？這樣子的話，MVP功能究竟是怎麼樣的功能？

Question3：做爲測試人員前期如何投入到項目中？

教材7.2.4中提到的MSF的基本原則之一：各司其職，對項目共同負責中說到：

團隊中的每一個角色都有本身的職責……
表7-1 MSF 團隊模型和關鍵質量目標

關鍵質量目標	MSF小組角色	出口條件
按約束條件交付產品	項目經理	項目經理們的項目是在時間/資源的條件內交付的麼
按產品規格說明交付產品	開發	咱們是否按照功能說明完成了各項功能
保證全部問題都獲得處理	測試	咱們發現了全部的問題，並且都有處理方案嗎
產品部署和後續管理	發佈管理	客戶是否能快速方便地部署產品和進行後續管理
讓產品更好用	用戶體驗	產品是否適應用戶的使用習慣?易學易用
讓客戶滿意	產品管理	客戶是否(在整體上)滿意咱們的項目

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《構建之法》第7章_7.2.4
這裏提到測試人員的職能，可是沒有詳細的介紹測試人員的具體工做，通過Alpha階段，我有一些疑問：測試人員前期要作什麼工做？測試人員若是前期沒有加入到開發工做，後期如何瞭解整個項目並進行相關測試？測試人員具體要測試什麼？即，做爲測試人員前期如何投入到項目中？
雖然教材14章也有提出相關的問題以及解答：

測試的角色（Test）要獨立出來麼？

獨立出來的測試角色怎麼才能發揮做用？

有些成功人士或公司認爲獨立的測試角色不該該存在，你怎麼看？

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《構建之法》第14章_14.2
在後面的總結提到了一個團隊如何培養和安排各個角色，可是仍是不太清楚。

Question4：代碼複審到底怎麼作？

閱讀到第四章的代碼複審，這裏提到：

代碼複審的正肯定義：看代碼是否在代碼規範的框架內正確地解決了問題。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《構建之法》第4章_4.4
其中代碼複審的形式包括自我複審、同伴複審以及團隊複審。
還閱讀了「代碼複審的核查表」，大概瞭解代碼複審的內容，可是對於代碼複審應該怎麼作，還不是特別清楚；特別是在微信小程序中，好像沒有特別須要作的代碼複審？！多是本身不太瞭解對於代碼複審的定義。

Question5：什麼是有限狀態自動機？

一直想提出的問題是在教材11章中提到的

咱們在計算機理論基礎課上都學過有限狀態自動機（Finite State Machine，FSM）……

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《構建之法》第11章_11.2.3
剛看到這個的時候，個人想法是，「有嗎？何時學過？」。這樣一律而論（或許真的有吧，我又沒聽課了？）的寫在這裏，好歹能夠給一個介紹或者連接吶，畢竟總會有人不懂，難道這本書只是出給專業人士看的？對軟件工程感興趣的人會去查相關資料，可是若是能給出相關參考給人的感受會好不少（可能做者有所遺漏吧）。
而後我默默的百度了

有限狀態自動機（FSM "finite state machine" 或者FSA "finite state automaton" ）是爲研究有限內存的計算過程和某些語言類而抽象出的一種計算模型。有限狀態自動機擁有有限數量的狀態，每一個狀態能夠遷移到零個或多個狀態，輸入字串決定執行哪一個狀態的遷移。有限狀態自動機能夠表示爲一個有向圖。有限狀態自動機是自動機理論的研究對象。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——百度百科

雖然沒有特別理解，說不定何時用到了，本身也不知道。（術語吶……）