【构建之法】第4章-两人合作

本章重点：

• 代码规范
• 极限编程
• 结对编程
• 两人合作的不同阶段
• 影响他人的技巧

1 代码规范

代码规范可以分成两个部分：

• 代码风格规范：主要是文字上的规定；
• 代码设计规范：牵涉到程序设计、模块之间的关系、设计模式等方方面面的通用原则。

1.1 代码风格规范

代码风格的原则是：简明，易读，无二义性。

规范	说明
缩进	空格 or Tab？
行宽	/
括号	在复杂的条件表达式中，用括号清楚地表达逻辑优先级
断行于空白的{}行	{和}都独占一行，用于明确展示程序的结构
分行	不要把多条语句放在一行上
命名	统一命名规范
下划线	/
大小写	用大小写区分多个单词组成的变量/函数等（驼峰命名法）
注释	有些程序本身就可以说明其是怎么工作的，避免多余的注释

1.2 代码设计规范

规范	说明
函数	只做一件事，并且要做好（单一职责原则）
goto	/
错误处理	-参数处理：对从外部（用户或别的模块）传递过来的参数，要验证其正确性； -断言：用于验证正确性；
如何处理C++中的类 （详细内容参加原书第70页）	-类 -class vs. struct -公共/保护/私有成员（public、protected和private） -数据成员 -虚函数（Virtual Function） -构造函数（Constructors） -析构函数（Destructor） -new和delete -运算符（Operators） -异常（Exceptions） -类型继承（Class Inheritance）

2 代码复审

代码复审的正确定义：看代码是否在代码规范的框架内正确地解决了问题。

2.1 代码复审的形式

名称	形式	目的
自我复审	自己 vs. 自己	用同伴复审的标准来要求自己。不一定最有效，因为开发者对自己总是过于自信。如果能持之以恒，则对个人有很大好处
同伴复审	复审者 vs. 开发者	简便易行
团队复审	团队 vs. 开发者	有比较严格的规定和流程，适用于关键的代码，以及复审后不再更新的代码； 覆盖率高-有很多双眼睛盯着程序，但效率可能不高（全体人员都要到会）

2.2 代码复审的目的

• 找出代码的错误：编码错误、不符合团队代码规范的地方；
• 发现逻辑错误；
• 发现算法错误；
• 发现潜在的错误和回归性错误；
• 发现可能需要改进的地方；
• 教育（互相教育）开发人员，传授经验，让更多的成员熟悉项目各部分的代码，同时熟悉和应用领域相关的实际知识。

2.3 代码复审的步骤

在复审前，要确保以下事情：

• 代码必须成功地编译，在所有要求地平台上，同时要编译Debug | Retail版本，编译要用团队规定的最严格的编译警告等级（如C/C++中的W4）；
• 程序员必须测试过代码；
• 程序员必须提供新的代码，以及文件差异分析工具；
• 在面对面的复审中，一般是开发者控制流程，讲述修改的前因后果。但是复审者有权在任何时候打断许数，提出自己的意见；
• 复审者必须逐一提供反馈意见；
• 开发者必须负责让所有的问题都得到满意的解释或解答，或者在TFS（Team Foundation Server，一种分布式文件系统）中创建新的工作项以确保这些问题会得到处理；
• 对于复审的结果，双方必须达成一致的意见；

2.4 代码复审的核查表

• 概要部分：代码是否符合需求规格说明、设计是否考虑周全、可读性、可维护性等；
• 设计规范部分；
• 代码规范部分；
• 具体代码部分：错误处理、无用元素等；
• 效能；
• 可读性；
• 可测试性：是否有单元测试，是否更新测试代码。

3 结对编程

/