软件架构————协同构建

协同开发概要

“协同构建”包括结对编程、正式检查、非正式技术复查、文档阅读，以及其他让开发人员共同承担创建代码及其他工作产品责任的技术。在设计过程中开发人员平均每个小时会引入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、跟进：主持人负责监督在详查过程中分配的任务返工任务。

详查中的自尊心

详查的目的是发现设计或代码中的缺陷，而不是探索替代方案，或者争论谁对谁错，其目的绝不应该是批评作者的设计或者代码。对于作者来说，详查的过程应该是正面的，在这一过程中的团队参与使程序得到了明显改善，对所有参与者都是一个学习的过程。

评论员必须记住，最终是由作者来负责决定如何处理缺陷。应该享受寻找缺陷的雷区，但每一个评论员必须尊重作者决定如何解决某个错误的最终权利。