協同開發概要
“協同構建”包括結對編程、正式檢查、非正式技術複查、文檔閱讀，以及其他讓開發人員共同承擔創建代碼及其他工作產品責任的技術。在設計過程中開發人員平均每個小時會引入1~3個缺陷，在編碼階段則會平均每小時引入5~8個，因此攻擊這些盲點就成了有效構建的關鍵。
協同構建是其他質量保證技術的補充
減少軟件中的缺陷數量的同時，開發週期也能得到縮短。
協同構建有利於傳授公司文化以及編程知識
軟件標準可以寫下來併發布出去，但是如果無人去討論它們，也不鼓勵使用這些標準，那麼就不會有人去按照這些標準做事。複查是一個很重要的機制，它可以讓程序員得到關於它們自己代碼的反饋、標準以及讓代碼符合標準的理由等，都是複查討論中的好主題。而且複查讓資深程序員和新程序員之間搭起了交流的橋樑，可以提高新人的代碼質量。
集體所有權適用於所有形式的協同構建
好處：
1、衆多眼鏡的檢查，以及衆多程序員的協力編寫，可以使代碼的質量變得更好。
2、某個人的離開對項目的影響更小。
3、總體上缺陷修正週期變短了，因爲幾個程序員中的任何一個有空，就能隨時指派上去修正。
在構建前後都應保持協作
結對編程
在進行結對編程的時候，移位程序員敲代碼，另外移位注意有沒有出現錯誤，並考慮某些策略性的問題。
成功運用結對編程的關鍵
1、用編碼規範來支持結對編程：如果兩個人整天把時間浪費在爭論代碼風格的問題上，那麼結對編程就不可能發揮它的威力。應該嘗試對風格進行標準化，以便程序員將精力集中在本質的任務上。
2、不要讓結對編程編程旁觀：不掌握鍵盤的那個人應該主動參與到編程當中，他應該分析代碼，提前思考接下來的代碼應該做些什麼，對設計進行評估，並對如何測試代碼做出計劃。
3、不要強迫在簡單的問題上使用結對編程：絕大多數的結對編程都是對部分工作採用結對編程，而不是全部。
4、有規律地對結對人員和分配的工作任務進行輪換，有規律的進行輪換有助於知識的互相傳播。
5、鼓勵雙發跟上對方的步伐，要是其中一個人相對走的過快的話，那就會大大限制了其結對搭檔的作用。
6、確認兩個人都能看到顯示器
7、不要強迫程序員與自己關係緊張的人組隊
8、避免新手組合
9、指定一個組長：即時整個隊伍希望所有工作都通過了結對編程的方法來做，你還是需要指定一個人來協調工作的分配，對結對負責以及負責與項目外其他人聯繫。
結對編程的好處
1、與單獨開發相比，結對能夠使人們在壓力之下保持更好的狀態。
2、能夠改善代碼的質量
3、能縮短進度
4、利於傳播公司文化，知道初級程序員以及培養集體歸屬感。
正式檢查
正式檢查即詳查，它是一種特殊的複查，它在偵測缺陷方面特別有效，並且相對測試來說更加經濟合理。
詳查能夠帶來的結果
獨立的詳查通常能夠捕捉到60%的缺陷。設計和代碼聯合詳查通常能夠去除產品中的70%到85%，甚至更多的缺陷。對設計和代碼都進行詳查的項目，詳查會佔到項目預算的10%到15%，並且通常會降低項目的整體成本。
詳查中的人員角色
1、主持人：負責保證詳查以特定的速度進行，使其既保證 效率，又能發現儘可能多的錯誤。
2、作者：直接參與設計或代碼的人，這種人在詳查中扮演次要角色，因爲詳查的目標之一就是讓設計或者代碼本身能夠表達自己。
3、評論員：評論員是同設計和代碼有直接關係，但又不是作者的人。
4、記錄員：將詳查會議期間發現的錯誤，以及指派的任務記錄下來。
5、經理：在詳查的時候讓經理參加通常不是一個好主意。軟件詳查的要點是一個純技術性的複查，而不是行政上的問題。
詳查的一般步驟
1、計劃：作者將設計或者代碼提交給主持人，而主持人決定那些人複查這些材料，並決定何時何地召開會議。
2、概述：當評論員不熟悉他們所要詳查的項目時，作者可以花一些時間來描述一下這些設計和代碼的技術背景。
3、準備：每一個評論員獨立地對設計或者代碼進行詳查，找出其中的錯誤。最搞笑的詳查速度變化範圍很大，因此，要保留所在組織的詳查速度記錄，以便於確定你所在的環境中最高效的詳查速度。
4、詳查會議：不要在開會的過程中討論解決方案，小組應該把注意力保持在識別缺陷上。某些詳查小組甚至不允許討論某個缺陷是否確實是一個缺陷。他們認爲如果使某個人困惑，那麼就應該認爲是一個缺陷了，設計、代碼或者文檔應該進一步清理。會議時間最好不要超過2個小時，否則注意力低下不集中。
5、詳查報告：詳查會議之後，主持人要寫出一份詳查報告，列出每一個缺陷，包括它的類型和嚴重級別。詳查報告有助於確保所有的缺陷都將得到修正，還可以開發出一份覈對表，強調與該組織相關的特定問題。如果收集了歷次詳查花費的時間和所發現的錯誤數量的數據，就可以利用這些客觀數據來應對有關詳查效率質詢。
6、返工：主持人將缺陷分配給某人來修復。
7、跟進：主持人負責監督在詳查過程中分配的任務返工任務。
詳查中的自尊心
詳查的目的是發現設計或代碼中的缺陷，而不是探索替代方案，或者爭論誰對誰錯，其目的絕不應該是批評作者的設計或者代碼。對於作者來說，詳查的過程應該是正面的，在這一過程中的團隊參與使程序得到了明顯改善，對所有參與者都是一個學習的過程。
評論員必須記住，最終是由作者來負責決定如何處理缺陷。應該享受尋找缺陷的雷區，但每一個評論員必須尊重作者決定如何解決某個錯誤的最終權利。
