《构建之法（第三版）》第四章
4.1 代码规范
代码规范可以分为两个部分：
- 代码风格规范：主要是文字上的规定
- 代码设计规范：牵扯到程序设计，模块之间的关系，设计模式等方方面面的通用原则。
4.2 代码风格规范
代码风格的原则是简明，易读，无二义性
- Tab键在不同的情况下会显示不同的长度，严重干扰阅读体验。4个空格的距离可读性最好
- 行宽必须限制，可以限定为100字符
- 在复杂的条件表达式中，用括号清楚地表示逻辑优先级
- 每个“{”和“}”都独占一行
if (condition)
{
DoSomething();
}
else
{
DoSomethingElse();
}
- 不要把多条语句放在一行上，更严格地说，不要把多个变量定义在一行上，如：
Foo foo1, foo2; - 匈牙利命名法：
fFileExist 表明是一个bool值，表示文件是否存在；
szPath 表明是一个以0结束的字符串，表示一个路径
- 下划线用来分隔变量名字中的作用域标注和变量的语义
- 所有的类型/类/函数名都用Pascal形式(所有单词的第一个字母都大写)，所有的变量都用Camel形式(第一个单词全部小写，随后单词随Pascal形式)；类/类型/变量为名词或组合名词，如Member、ProductInfo等；
函数用动词或动宾组合词来表示，如get/set、RenderPage() - 不要注释程序是怎么工作的（How），注释是为了解释程序做什么（What），为什么这样做（Why），以及要特别注意的地方。复杂的注释应该放在函数头，很多函数头的注释都用来解释参数的类型等。注释（包括所有源代码）应该只用ASCII字符
4.3 代码设计规范
代码设计规范不光是程序书写的格式问题，而且牵涉到程序设计、模块之间的关系、设计模式等方方面面。如果所写的程序会被很多人使用需要遵守以下规则：
- 函数最好有单一的出口，为了达到这一目的，可以使用goto
- 在Debug版本中，所有的参数都要验证其正确性。在正式版本中，对从外部（用户或别的模块）传递过来的参数，要验证其正确性。当觉得某事肯定如何时，可以用断言：
Assert (p != NULL)。如果认为某事可能会发生，这时就要写代码来处理可能发生的错误情况。如:
……
p = AllocateNewSpace();
if (p == NULL)
{ // error handling.
}
else
{ // use p to do something
}
4.4 代码复审
代码复审就是看代码是否在“代码规范”的框架内正确地解决了问题。形式有自我复审、同伴复审、团队复审，同伴复审是最基本的复审手段。
代码复审核查表应该囊括（不局限于）概要部分（整体风格）、设计规范部分（按照已知的规则去约束）、代码规范部分、具体代码部分、效能、可读性、可测试性。
4.5 结对编程
结对编程中有两个角色：
- 驾驶员（driver）：控制键盘输入
- 领航员（navigator）：起到领航、提醒的作用
结对编程步骤：
- 驾驶员：写设计文档，进行编码和单元测试等XP开发流程
- 领航员：审阅驾驶员的文档、驾驶员对编码等开发流程的执行；考虑单元测试的覆盖率；思考是否需要和如何重构；帮助驾驶员解决具体的技术问题
- 驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟。领航员要控制时间
- 主动参与。任何一个任务都首先是两个人的责任，也是所有人的责任。没有“我的代码”、“你的代码”或“他/她的代码”，只有“我们的代码”
- 只有水平上的差距，没有级别上的差异。两人结对，尽管可能大家的级别资历不同，但不管在分析、设计或编码上，双方都拥有平等的决策权利
- 设置好结对编程的环境，座位、显示器、桌面等都要能允许两个人舒适地讨论和工作。如果是通过远程结对编程，那么网络、语音通讯和屏幕共享程序要设置好
传统复审最大的缺点是复审者缺少对程序的深入了解，
传统复审设计人员多，复审效率不能平衡。在结对编程的过程中不断重复的互相复审可以十分默契地提高效率。结对编程最大的特点在于“领航员”的引入。如果实际中这个角色不能“领航”，则不如放弃结对编程。
4.6 两人合作的不同阶段和技巧
两人合作分为萌芽阶段，磨合阶段，规范阶段，创造阶段，解体阶段。
评论人的三种层次，评论别人的代码的时候也是要注意自己侧重那个层次的，这样才能达到最好的效果，被评论人才能更好地找出自己需要改正的地方并解决：
- 最外层：行为和后果
- 中间层：习惯和动机
- 最里层：本质和固有属性
本章讲了很多两人合作的问题，如果两个人之间的合作都处理不好，又如何谈团队合作？有些人技术相当好，但是却不能很好地与人沟通，不能与团队中其他人的风格相融通。团队中只有通过频繁地相互交流，互相融通，在研发过程中遇到的困难能最快、最有效地得到解决。
