本章節講的是團隊程式設計
隨著現在軟體規模越來越大，團隊程式設計的作用也愈加凸顯。
團隊模式有以下模式：
一窩蜂模式：一堆人上來就幹，沒有協調性因為這樣的團隊存活時間不長，所以被觀察到的不多
主治醫師模式：首席程式猿工作，其餘人打輔助，不少學校的軟體工程的團隊作業淪為這種模式，只靠團隊中一兩個完成任務，其餘人打醬油。
明星模式： 主治醫生的極端版本
社群模式：unix和linux屬於這種，依靠嚴格的質量管理和志願者參與完成
業餘劇團模式：學生的實踐培訓專案大概屬於這種
秘密團隊模式：蘋果研發發macintosh以後的系統和不少創業公司團隊屬於這種
**團隊：由特殊技能的專業人士組成，比如早年解決千年蟲的團隊和負責網路安全的團隊
交響樂團團模式：大多數大型軟體公司開發團隊採用這種模式，比如office系列
爵士樂模式：比較散漫自由
功能團隊模式
官僚模式：即老闆驅動
開發流程模式：軟體開發過程中有很多種類的流程方法，目的是提高軟體開發、運營和維護的效率，以及提公升使用者滿意度、軟體的可靠性和可維護性。書中總結的開發流程模式如下：
寫了再改
不少軟體工程課程的作業屬於這種模式：
瀑布模型
統一流程模式（rup，rational unified process ）
把軟體開發的各個階段整合在乙個統一的框架裡，包括業務建模、需求、分析和設計、實現、測試、部署、配置和變更管理、專案管理、環境。並且每個階段設定乙個里程碑（milestone），分為初始、細化、構造、交付四個階段，並且每個階段可以迭代幾次
老闆驅動模式
由公司老闆或行政主管直接推動，在團隊尚不成熟或者領導水平較高方能顯出效果，但在領導是外行或者領導不在、不稱職的時候會很麻煩。
漸進交付和mvp
不斷重複「開發→發布→聽取反饋→根據反饋做改進」四個階段，直到使用者滿意或者錢用完。09年開始一些網際網路團隊採用mvp方法，即—minimal viable product，最小可行產品，具體做法是：把產品最核心的功能用最小的成本實現出來（或者描繪出來），然後快速徵求使用者意見。
在介紹完團隊模式和開發流程模式後，書中又介紹了優秀模式和流程的共同點(cmu軟體工程學院把這些共同點抽象總結為team soft-ware process（tsp）的原則)：
使用妥善定義的流程，流程中的每一步都是可以重複、可以衡量結果的。團結就是力量，但是團隊如何「團結」起來，同學們在完成團隊作業前也可以好好看看這一章2.團隊的各個成員對團隊的目標，角色，產品都有統一的理解。
3.盡量使用成熟的技術和做法。
4.盡量多地收集資料（也包括對團隊不利的資料），並用資料來幫助團隊做出理性的決定。
5.制定切合實際的計畫和承諾，團隊計畫要由負責具體執行的的角色來制定（而不是從上級而來）。
6.增加團隊的自我管理能力。
7.專注於提高質量，爭取在軟體生命週期的早期發現問題。
《構建之法》讀書筆記第3章
第三章講的是軟體工程師的發展。主要從軟體工程師的評價方法，團隊期望和技能的反面進行闡述，並對應的分為3個小節。在第一小節中講的是個人能力的衡量與發展。對於初級軟體工程師的成長，從以下5個方面開始 積累軟體開發相關的知識，提公升技術技能 積累問題領域的知識和經驗 例如 對醫療或金融行業的了解 對通用的...
《構建之法》讀書筆記第1 2章
之前因為助教工作閱讀過一遍 構建之法 現在回頭重新翻看這本書，越發覺得這本書值得深入閱讀。本週先將前兩周的讀書筆記記錄如下 第一章從淺入深，以航空業的發展歷程作為模型，模擬軟體工程的發展。玩具 紙飛機 業餘愛好 沙灘椅 氦氣球 探索 萊特兄弟 產業 容納百萬人就業的航空業。類似的，軟體也從簡單的 h...
構建之法第4 17章讀書筆記
第四章 兩人合作 問題1 4.2中注釋這一版塊，因為之前有學長跟我強調過 規範的問題，所以對這方面比較重視，後來當使用每個ide的時候，都會去注意 縮排的快捷鍵，比如idea的ctrl alt l等等 我對自己寫的 還算比較滿意，但是在注釋這一塊確毫無頭緒，不知道什麼是標準，以前看過標準的注釋，記得...