4.4**複審
**複審即看**是否在「**規範」的框架內正確地解決了問題。形式有：自我複審、同伴複審、團隊複審。目的是：1、找出**錯誤 2、發現邏輯錯誤 3、發現演算法錯誤 4、發現潛在的錯誤和回歸性錯誤 5、發現可能需要改進的地方 6、教育（互相教育）開發人員，傳授經驗，讓更多的成員熟悉專案各部分的**，同時熟悉和應用領域相關的實際知識。步驟：1、首先**需要成功地編譯 2、程式設計師必須測試過** 3、程式設計師必須提供新的**，以及檔案差異分析工具。4、複審者可以選擇面對面的複審、獨立複審或其他方式。5、面對面複審中，開發者控制流程，講述修改的前因後果。6、複審者必須注意提供反饋意見。7、開發者必須讓所有的問題都得到滿意的解釋或解答，或者在tfs（tfs是team fundation server的簡稱，是微軟vsts的一部分，它是microsoft應用程式生命週期管理(alm)工具的核心協作平台，簡單的說它是管理和開發軟體專案的整個生命週期的平台工具。）中建立新的工作項以確保這些問題會得到處理。8、對於複審的結果，雙方必須達成一致的意見。複審後：需要將複審過程中的記錄整理出來；
結對程式設計：寫**過程包括駕駛員（控制鍵盤輸入）和導航員（起到領航、提醒的作用）。在結對程式設計中程式的質量取決於程式設計師中各方面水平的一方。好處：1、在開發層次，結對程式設計能提供更好的設計質量和**質量，兩人合作解決問題的能力更強。2、結對工作能帶來更多的信心，高質量的產出的能帶來更高的滿足感。3、在企業管理層次上，結對能更有效地交流，相互學習和傳遞經驗，分享知識，能更好地應對人員流動，如果運用得當，結對程式設計可以取得更高的投入產出比。複審過程有：設計複審、**複審、測試計畫複審和文件複審。結對程式設計的方法：1、駕駛員：寫設計文件，進行編碼和單元測試等xp開發流程。2、領航員：幫駕駛員解決技術問題，審閱其**等。3、駕駛員和導航員要輪換工作，並且應該適當休息。4、主動參與 5、只有在水平上的差距，沒有級別上的差距5、要有良好的程式設計環境。結對程式設計的階段：1、萌芽階段 2、磨合階段 3、規範階段 4、創造階段 5、解體階段 結對程式設計過程中影響其他人的方式:斷言、橋梁、說服、吸引 提意見的方式：先強調雙方的共同點，然後再提建設性意見，最後鼓勵對方把工作做好。
第5章 團隊和流程
軟體團隊具有一致的集體目標。並且要一起完成這個目標。
團隊模式有：一窩蜂模式、主治醫師模式、明星模式、社群模式、業餘劇團模式、秘密團隊、**團隊、交響樂團模式、爵士樂模式、功能團隊模式、官僚模式；個人認為功能團隊模式比較好因為這樣小組成員都是同級別的進行溝通，而且比較有組織性。
開發流程有：寫了再改模式、瀑布模型、瀑布模型的變形、統一流程、老闆驅動的流程、漸進交付的流程、mvp和mbp；個人認為mvp比較好，因為不會發生瀑布模型那樣各個階段沒有確切的時間分割點，並且使用者只有在最後才能看見具體的結果；老闆驅動可能會發生領導能力不夠，影響整個團隊的交流和運作；漸進交付如果使用者反饋較晚，有可能使團隊該階段的努力浪費。
個人感受：
1、我過去是怎麼做的：寫完**後不會整理自己有過哪些錯誤。
2、結合書中所講，說明為什麼這樣不好：很可能延續以前犯的錯誤，再寫**時不能有效的避免這些錯誤。
3、提出乙個解決辦法，避免再次掉入陷阱：每次寫完**後應該做乙個錯誤的記錄，下次寫**之前先翻一下自己的錯誤記錄，這樣就可以有效的減少犯同樣錯誤的情況。
《構建之法》讀書筆記03
4.4 複審 複審即看 是否在 規範 的框架內正確地解決了問題。形式有 自我複審 同伴複審 團隊複審。目的是 1 找出 錯誤 2 發現邏輯錯誤 3 發現演算法錯誤 4 發現潛在的錯誤和回歸性錯誤 5 發現可能需要改進的地方 6 教育 互相教育 開發人員，傳授經驗，讓更多的成員熟悉專案各部分的 同時熟...
構建之法讀書筆記03
構建之法 是一本全景式圖書，讓我更了解這個行業，是一本與現實接軌的教材。其次，這是一本最佳實踐式的書，涵蓋了科學 健康的軟體工程開展中的每個方面，介紹了種種方 但不是高高在上 綱領性的方 而是方 的最佳實踐，確實可用，拿來就用。這本書在介紹方 的同時，會介紹方 不適用的場景，介紹方 在現實中是怎樣跑...
構建之法讀書筆記
場景 故事 版權 版本 維護人 1.背景 a.典型使用者 姓名 性別 年齡 職業等 b.使用者需求 痛點 c.假設 2.場景 關於這個場景的文字描述角色 與軟體互動的角色，如使用者等其他實體，甚至時間 主要成功場景 一系列步驟 步驟 描述每一步的互動 擴充套件場景 描述一些意外情況 軟體功能說明書 ...