协同开发概要
“协同构建”包括结对编程、正式检查、非正式技术复查、文档阅读，以及其他让开发人员共同承担创建代码及其他工作产品责任的技术。在设计过程中开发人员平均每个小时会引入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、跟进：主持人负责监督在详查过程中分配的任务返工任务。
详查中的自尊心
详查的目的是发现设计或代码中的缺陷，而不是探索替代方案，或者争论谁对谁错，其目的绝不应该是批评作者的设计或者代码。对于作者来说，详查的过程应该是正面的，在这一过程中的团队参与使程序得到了明显改善，对所有参与者都是一个学习的过程。
评论员必须记住，最终是由作者来负责决定如何处理缺陷。应该享受寻找缺陷的雷区，但每一个评论员必须尊重作者决定如何解决某个错误的最终权利。