4.1 **規範
包括**風格規範和**設計規範
4.2 **風格規範
**風格原則：簡明、易讀、無二異性
縮排：4個空格，而不是tab
行寬：限定為100字元
括號斷行與空白的{}行
分行命名：匈牙利命名法
下劃線：分隔變數名字中的作用域標註和變數語義
大小寫（pascal形式和camel形式）
注釋4.3 **設計規範
函式：只做一件事，並且要做好
goto：有助於程式邏輯的清晰體現
錯誤處理：引數處理、斷言
類的處理
4.4 **複審
①形式：自我複審、同伴複審、團隊複審
②目的：找出**錯誤、發現邏輯錯誤、發現演算法錯誤、發現潛在的錯誤和回歸性錯誤、發現可能需要改進的地方、傳授經驗
（1）更正明顯的錯誤
（2）記錄無法很快更正的錯誤
（3）把所有的錯誤記在自己的乙個「我常犯的錯誤」表中，作為以後自我複審的第一步
4.5 結對程式設計
①角色：
駕駛員：控制鍵盤輸入
②好處：（1）在開發層次，可以提供更好的設計質量和**質量，兩人合作解決問題的能力更強。
（2）對開發人員，帶來更多的信心，高質量的產出帶來更高的滿足感。
（3）企業管理層次上，有效地交流，相互學習和傳遞經驗，分享知識，取得更高的投入產出比。
5.2 軟體團隊的模式
主治醫師模式、明星模式、社群模式、業餘劇團模式、秘密團隊、**團隊、交響樂團模式、爵士樂模式、功能團隊模式、官僚模式
5.3 開發流程
①寫了再改模式
②瀑布模型（wate***ll model） 是乙個專案開發架構，開發過程是通過設計一系列階段順序展開的，從系統需求分析開始直到產品發布和維護，每個階段都會產生迴圈反饋，因此，如果有資訊未被覆蓋或者發現了問題，那麼最好 「返回」上乙個階段並進行適當的修改，專案開發程序從乙個階段「流動」到下乙個階段，這也是瀑布模型名稱的由來。
瀑布模型的適用範圍：產品的定義非常穩定但正確性非常重要、產品模組之間的介面能很好地定性定義和驗證、使用的技術很成熟、子團隊不能做到頻繁的交流。
③瀑布模型的變形：生魚片模型（各個相鄰模組像生魚片那樣部分重疊）以及大瀑布帶著小瀑布（各個子系統統一到最後進行系統測試）
5.4 統一流程rup
統一流程rational unified process，團隊的各種成員在乙個複雜的軟體專案中的不同階段做不同的事。這些不同型別的工作在rup中叫做規程或者工作流。簡介：
業務建模、需求、分析和設計、實現、測試、部署、配置和變更管理、專案管理。
分為四個階段：初始階段（達到生命週期目標里程碑）、細化階段（達到生命週期結構里程碑）、構造階段（達到初始功能里程碑）、交付階段（達到產品發布里程碑）
構建之法讀書筆記二
在學習這麼多之後，軟體工程給我的印象是 使用者需求的框架 樸實 的填充。那麼在寫軟體的時候一定要用傻瓜式的 了麼？顯然不是，高階演算法能極大地減少時間複雜度與空間複雜度，只是放在大型工程裡，需要注意資料與其他模組的關聯性。現在我們先討論什麼是 好軟體 一般情況下我們認為沒有bug的軟體就是乙個好軟體...
構建之法 讀書筆記二
現在這本書已經讀了有三分之二了，看到這，我大概了解了關於個人技能提公升和團隊協作的知識。關於個人的成長，肯定是在不斷地實踐，不斷地出差錯，不斷地改進 解決問題 總結經驗中體現的，然後成為自己的知識，這就是提公升。而在軟體工程上也一樣，提公升不僅僅是在技術的提公升，更是在知識的積累，軟體設計思想的積累...
《構建之法》讀書筆記二
繼上次之後，讀了 本書的7到12章 下面主要寫一下書中覺得重要的東西。msf基本原則。1.推動資訊共享與溝通。2.為共同的遠景而工作。3.充分授權和信任。4.各司其職，對專案共同負責。5.交付增量的價值。6.保持敏捷，預期和適應變化。7.投資質量。8.學習所有的經驗。9.與顧客合作。對軟體的需求，也...