**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 中叫做規程或者工作流。簡介：
業務建模、需求、分析和設計、實現、測試、部署、配置和變更管理、專案管理。
分為四個階段：初始階段（達到生命週期目標里程碑）、細化階段（達到生命週期結構里程碑）、構造階段（達到初始功能里程碑）、交付階段（達到產品發布里程碑）
構建之法閱讀筆記之一
第一章 概論 這一章主要是講解了軟體工程的基礎知識 軟體 程式 軟體工程，並進一步的出擴充套件結論 軟體企業 軟體 商業模式。第二章 個人技術和流程 該章講解了個人開發，psp是每個軟工人都必須要掌握的個人開發流程，要學會對自己的 進行單元測試，學會效能分析 抽樣和 注入，掌握合適的效能分析工具。第...
構建之法閱讀筆記之一
在以前的我眼裡，所謂軟體，也不過只是複雜一點的程式罷了。直到今天，我才明白，軟體並不只是乙個複雜而又龐大的程式，軟體 程式 軟體工程。程式，僅僅只是一些 而軟體工程，包括許多。乙個複雜的軟體不但要有合理的軟體架構 軟體設計與實現，還要有各種檔案和資料來描述各個程式檔案之間的依賴關係 編譯引數 鏈結引...
構建之法閱讀筆記03
通過這幾天的閱讀，基本對本書又有了新的認識，讀完這本書是一回事，要想深入的理解又是另一回事。本書第一版出自2014年，當時軟體工程正在中國蓬勃發展，在此書出來之前大學裡的教材有些還是外國書籍的翻譯版本。豆瓣上對此書的介紹是 軟體工程牽涉的範圍很廣,同時也是一般院校的同學反映比較空洞乏味的課程。但是軟...