两人合作
代码风格规范
代码风格的原则是：简明、易读、无二义性，具体包括以下几个方面：
1、缩进：最好用4个空格，因为编辑工具可以设置一个tab键为几个空格，如果设置被修改的话会影响阅读体验。
2、行宽：80个字符（以前），现在随着硬件升级可以提高到100个字符
3、括号：选择最清晰的程序结构：
if(condition)
{
DoSomething();
}
else
{
DoSomethingElse();
}
4、不要把多条语句放在一行，不要把多个变量的定义放在一行
5、命名：对于不区分变量类型的语言来说，命名中要有变量类型让人一眼看出来变量是什么类型，避免可能的错误，这就是匈牙利命名法，一些强类型的语言中就没有必要在命名中加入变量类型。命名一定要避免过多的描述，能从上下文得到的信息就无需写在变量名中（如Employee类的姓名变量可以简单的起名为name，而不是employeeName），避免过多的形容词，如state、data等。
6、下划线的使用：各公司标准不同
7、大小写：类的所有单词首字母都大写，即Pascal风格；变量名和函数名除了第一个单词以外的所有单词首字母都大写，即Camel风格。常量全部字母都大写，单词间用下划线隔开。函数名可以用动词或动宾组合来命名。
8、注释：注释不要解释程序是怎么做的（how），而应该介绍程序做了什么（what）、为什么这样做（why），以及需要特别注意的地方。注释也要根据程序的修改而不断更新，一个误导的注释比没有注释更糟糕。
代码设计规范
函数设计时遵循的最重要的原则是：只做一件事，而且要做好。
面向对象编程的几个原则。
代码复审
代码复审的三种形式：自我复审、同伴复审、团队复审
代码复审的目的：
1、找出代码的错误，如不能通过编译的代码、不符合团队规范的代码
2、找出逻辑错误
3、找出算法错误，如算法优化不够，边界条件没有处理好
4、发现潜在的错误和回归性错误
5、提出可能改进的地方
6、互相传授经验，熟悉项目各部分的代码
代码复审的步骤：
1、代码首先要通过编译、完成自测
2、通过文件差异分析工具对比代码
3、由开发者讲述修改的前因后果，由复审者提出问题或意见，复审者不必亲自调查每一件事，开发者有义务作出详尽的解答，或者确保这些问题得到处理。
不仅仅要提出实际的问题，还要把眼光放远，问一些这样的问题：
（1）修改后别的功能会受到影响吗？有没有别的成员需要告知？还有别的地方需要类似的修改吗？
（2）有没有留下足够的说明和注释？
（3）导致问题的根本原因是什么？如何能自动避免这样的问题出现？
注意在项目开发的早期无需计较一些细枝末节。
4、双方达成复审的结果，结果包括发现致命问题打回去、有一些小问题但可以先同意、放行。
5、代码复审后，开发者应该把错误整理出来防止再犯。
代码复审的核查表：
结对编程
结对编程就是一种无时无刻不在代码复审的工作方法，也就是一对程序员共同工作，坐在一台电脑前。结对编程有两个角色：驾驶员Driver控制键盘输入、领航员Navigator起到领航和提醒作用。
结对编程中通过随时的代码复审和交流，程序各方面的质量取决于水平较高的那一位，这样就能提升程序的质量，如果运用得当，结对编程可以取得更高的投入产出比。
结对编程最关键的是如何发挥领航员的作用。
不是所有情况都适合结对编程，如需要长期独立钻研的处于探索阶段的项目、后期维护时、测试需要很长时间时等。
两人合作的不同阶段和技巧
两人合作的各个阶段：
1、萌芽阶段：刚刚认识，很有礼貌，避免冲突和容易引起争论的观点，彼此不了解
2、磨合阶段：开始有观点上的冲突
3、规范阶段：彼此逐渐了解，许多事情达成一致
4、创造阶段：彼此很了解，可以高效率的共同工作
5、解体阶段：如果磨合过多可能会散伙
影响对方的几种方式：
合作的关键是如何正确的给予反馈，评价别人有几种层次：
最外层的是行为与后果，中间层的是习惯与动机，最内层的是本质与固有属性。
加入某人在项目的源代码中使用了tab缩进，这和团队规定的代码规范相违背，他的同伴可以这样提意见：
1、行为与后果：我注意到你用的是tab缩进，我们当初指定规范说好了用4个空格，如果个别人使用了不同风格，以后大家阅读和修改代码时就很不方便，对工作有影响。
2、习惯与动机：你怎么又搞tab缩进？这都第几次了？你是对大家的决议不满吗？
3、本质和固有属性：你太没脑子了，我们之前决定的编码风格你怎么都听不进去！你只想着你自己的方便，你们xx学院出来的学生怎么都这么没有团队精神！
很显然，一旦攻击深入到核心，被攻击方就难以做出回应，合作的关键在于提供他人容易接受的反馈，这里推荐一个“三明治”办法：
1、首先做好铺垫，强调双方的共同点，从团队共同的愿景讲起，让对方觉得自己处于安全的环境
2、然后再提出建设性的意见，不要提以前的事，也不要做评价下结论，应该多展望未来的结果，强调过去虽然做的不够，但是我们将来可以做的更好，一般不要贸然深入到中间层和最内层，着重反馈行为与后果。
3、鼓励对方把工作做好。
上例中，对团队成员的反馈应该这样进行：
1、做好铺垫：我觉得你这几段代码写的很快，解决问题的思路也不错，和以前比大有进步
2、提出意见：我注意到你用的是tab缩进，我们当初指定规范说好了用4个空格，如果个别人使用了不同风格，以后大家阅读和修改代码时就很不方便，对工作有影响。
3、鼓励对方：你这几段代码还是很关键的，要好好做，既然已经做了很多工作，那就再进一步，留下高质量的代码。