两人合作vs结对编程

一、代码规范

易读，指机器和人都要

二、solid code

1. 零缺陷
2. 易懂
3. 明确地定义你的假设。
4. 显式定义依赖项

三、代码复审核查表

概要部分

1） 代码符合需求和规格说明么？ 2） 代码设计是否考虑周全？

3） 代码可读性如何？ 4） 代码容易维护么？5） 代码的每一行都执行并检查过了吗？

设计规范部分

1） 设计是否遵从已知的设计模式或项目中常用的模式？

2） 有没有硬编码或字符串/ 数字等存在？

3） 代码有没有依赖于某一平台，是否会影响将来的移植（如Win32到 Win64）？

4） 开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现？在本项目中是否存在类似的功能可以调用而不用全部重新实现？

5） 有没有无用的代码可以清除？

具体代码部分

1） 有没有对错误进行处理？对于调用的外部函数，是否检查了返回值或处理了异常？

2） 参数传递有无错误，字符串的长度是字节的长度还是字符（可能是单/双字节）的长度， 是以0 开始计数还是以1 开始计数？

3） 边界条件是如何处理的？switch语句的default分支是如何处理的？循环有没有可能出 现死循环？

4） 有没有使用断言（Assert）来保证我们认为不变的条件真的得到满足？

5） 对资源的利用，是在哪里申请，在哪里释放的？有无可能存在资源泄漏（内存、文件、 各种GUI资源、数据库访问的连接，等等）？有没有优化的空间？

6） 数据结构中有没有用不到的元素？

效能

1） 代码的效能（Performance）如何？最坏的情况是怎样的？

2） 代码中，特别是循环中是否有明显可优化的部分（C++中反复创建类，C#中 string 的操作是否能用StringBuilder来优化）？

3） 对于系统和网络的调用是否会超时？如何处理？

可读性

 代码可读性如何？有没有足够的注释？

可测试性

 代码是否需要更新或创建新的单元测试？针对特定领域的开发（如数据库、网页、多线程 等），可以整理专门的核查表。

四、代码复查的步骤

1）在复审前，代码必须成功地编译，程序员必须测试过代码。

2）在面对面的复审中，一般是开发者控制流程，讲述修改的前因后果。但是复审者有权在任何时候打断叙述，提出自己的意见。

3）复审者必须逐一 提供反馈意见。

4）开发者必须负责让所有的问题都得到满意的解释或解答。

5）对于复审的结果，双方必须达成致的意见。

      打回去

      有条件地同意

      放行

五、结对编程

驾驶员/领航员，两人共享一个键盘，电脑，屏幕

驾驶员：写设计文档，进行编码和单元测试等开发流程。

领航员：审阅驾驶员的文档；监督驾驶员对编码等开发流程的执行；考虑单元测试的覆盖率，写测试用例；思考是否需要和如何重构；帮助驾驶员解决具体的技术问题。

 驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟。 领航员要控制时间。

 主动参与。

任何一个任务都首先是两个人的责任，也是所有人的责任。

只有水平上的差距，没有级别上的差异。两人结对，尽管可能大家的级别资历不同，但不管在分析、设计或编码上，双方都拥有平等的决策权利。

设置好结对编程的环境，座位、显示器、桌面等都要能允许两个人舒适地讨论和工作。如果是通过远程结对编程，那么网络、语音通讯和屏幕共享程序要设置好。

1、好处

提高设计质量

更好的设计，避免愚蠢的bug，

降低成本

分享知识，更少的debug时间

提高解决问题的信心

        结对经常能解决 “不可能的任务

提高士气

觉得自己的工作有另一人认可.

减轻风险

在团队中有一些 “知识的冗余”，降低了成员离开的负面影响

提高效率

两人在一起不好意思偷懒或开小差上网

2、坏处

工作方式的不同

大多数人觉得喜欢一个人工作

让人感觉到威胁

新手 vs. 老手

时间可能花在培训上面 （也有价值）

老手 vs. 新手

对个人情绪，自尊的影响

“my code”  vs. “your code”

3、最合适的场景

降低容易犯的错误

新手 + 新手， 或者双方各有明显弱点

探索一个新的领域

传播知识和技能

老手 + 新手 也可以

4、过程

• 萌芽
• 磨合
• 规范
• 创造

5、影响

断言/桥梁/说服/吸引