两人合作是团队合作的基础；这里介绍的这个基础型“团队”中通用的一些方法以及最重要的——交流——的细节

1.代码规范

1. 代码风格规范。主要是文字上的规定；
   • 缩进：4个空格，而不是tab；
   • 关于断行与空白的{}行：【作者的建议深得我心——{ 、}单独占一行；中间的代码缩进】
   • 下划线：用来分割变量名字中的作用域标注和变量的语义
   • 大小写：通用的做法是，所有的类/函数名都采用所有单词首字母大写（Pascal）的形式；所有的变量首字母小写，随后的单词首字母大写(Camel)；
   • 注释：解释程序做什么、为什么这样做以及要特别注意的地方。注释只用ASCII码字符，不要用中文或者其他特殊字符，否则会影响可移植性
2. 代码设计规范。牵涉到程序设计、模块之间的关系、设计模式等思维和价值观角度的东西。
   • 函数：只做一件事，做到最好。【这句话在我学java之初就听老师反复说过，印象十分深刻；这几乎可以上升到编程的“哲学智慧”层次了】
   • 函数：最好有单一的出口，必要的时候可以使用goto；
   • 错误处理：
     • 参数处理：在debug版本中，所有的参数都要验证其正确性；
     • 断言：Assert(一定正确的某条语句)

2.代码复审

代码复审的目的在于找出代码的错误。因为越是项目后期发现的错误，修复的代价就越大——这也是learning by doing思想的体现。

• 优秀的代码复审者应该把眼光放长远，考虑除了当前代码或者改动之外的、可能产生持久影响的问题
• 代码审核表应该囊括（不局限于）这些方面
  • 概要部分（整体风格）
  • 设计规范部分（按照已知的规则去约束）
  • 代码规范部分
  • 具体代码部分
  • 效能
  • 可读性
  • 可测试性【我认为其实最后两个是一种“精益求精”的标准】

3.结对编程

1. 结对编程中有两个角色
   1. 驾驶员（driver）：控制键盘输入；
   2. 领航员（navigator）：领航提醒。
2. 在结对编程的过程中不断重复的互相复审
   1. 传统复审最大的缺点是复审者缺少对程序的深入了解；【这正是互相复审的最大优点】
   2. 传统复审设计人员多，复审效率不能平衡。互相复审则可以十分默契地提高效率；
   3. 结对编程最大的特点在于“领航员”的引入。如果实际中这个角色不能“领航”，则不如放弃结对编程
3. 极限编程
   • 把一些认为有效的方法发挥到极致（效用和占比最大化）
4. 关于交流的基本素质【个人认为这一点完全可以说开去】
   1. 评论人的三种层次：
      1. 最外层：行为和后果【就事论事，对方仍然可以改正】
      2. 中间层：习惯和动机【比较难以澄清】
      3. 最里层：本质和固有属性【人格上的攻击或者赞美，基本上无法改变】
   2. 反馈的顺序
      1. 做好铺垫，拉近距离，使得对方处于相对安全的环境；
      2. 核心是对方的做法和后果，比较容易接受和改进；
      3. 最后提出鼓励和期望

构建之法 第四章 两人合作