1.结对项目的案例和论文
因为教材上给的案例是全英文的，而我的英语水平是异常异常的烂，看见英语就头疼，就没有了看见下去的欲望，我在网上找到了邹欣老师的观点，以下是他的观点。
总结1：那是project到了比较关键的创造阶段，整整一天，我们俩椅子靠椅子的坐在电脑前，一边讨论一般coding，那次才真正的体会到结对真的能够带来效率。一整天的coding是容易走神的事，还好有pair在旁边指导，总是不断在我敲某某变量之前提前告诉我成员变量的名字，数据修改时帮忙检查是否有漏掉的，变量和函数定义的时候一起为其取名字，感觉有点眼花了，就换了个角色，我也开始对他“指指点点”了，一个人coding，一个人review，确实能减少一些不必要的错误，减少一些漏洞，算法实现后一起做些简单的测试，看到bug了再一起分析，我能明显的感觉到与以前的个人编程不一样，我们能比较快的找到bug初始点，并能提出比较的修改方法。特别是当看到功能进一步实现时，心里确实挺happy，更重要的这份感受有同伴与你一起分享。
总结2：于是我们进行了项目中最关键的一次Pair Programming，我们利用编译课上机时间，在机房里Pair完成了整个项目的类的设计与程序结构的设计。我们一起分析出类，然后找属性，写方法头，开始是WG用键盘，后来我用。一个明显的好处是，写完一条自己不确定的语句，马上可以跟Pair一起缕一缕思路。一下午下来，感觉甚为清爽，因为终于清楚这个项目的做法了。
2.性格对合作的影响
人和人不一样，在和别人合作的时候，要注意各人表达观点的方式和思考的方式不尽相同。
迈尔斯布里格斯类型指标（MBTI）表征人的性格，是美国心理学家布里格斯和迈尔斯母女凯恩琳·布里格斯和她的女儿伊莎贝尔·布里格斯·迈尔斯制定的。该指标以瑞士心理学家荣格划分的8种类型为基础，经过二十多年的研究后，编制成了《迈尔斯-布里格斯类型指标》，从而把荣格的类型理论付诸实践。迈尔斯在荣格的优势功能和劣势功能、主导功能和从属功能等概念的基础上，进一步提出功能等级等概念，并有效的为每一种类型确定了其功能等级的次序，又提出了类型的终生发展理论，形成四个维度。约翰.毕比博士在《类型与原型》中，将心理类型理论和原型理论系统地结合在一起。华南师范大学申荷永教授将心理类型引进了中国并加以扩展这四个维度就是四把标尺，每个人的性格都会落在标尺的某个点上，这个点靠近哪个端点，就意味着这个人就有哪方面的偏好。
我的MBTI的类型是外倾直觉情感知觉（ENFP）：热情洋溢、富有想象力。认为人生有很多的可能性。能很快地将事情和信息联系起来，然后很自信地根据自己的判断解决问题。总是需要得到别人的认可，也总是准备着给与他人赏识和帮助。灵活、自然不做作，有很强的即兴发挥的能力，言语流畅。
不同性格类型对合作是有很大影响的，所以要合作之人相互磨合，慢慢的培养彼此之间的默契，这样合作出来的成果也就越来越好。
3.是否需要代码有规范
代码是需要有规范的
每个人对于什么是“好”的代码规范未必认同，这时我们很有必要给出一个基准线—什么是好的代码规范和设计规范计算机只关心编译生成的机器码，你的程序采用哪种缩进风格，变量名有无统一的规范等，与机器码的执行无关。但是，做一个有商业价值的项目，或者在团队里工作，代码规范相当重要。“代码规范”可以分成两个部分：1. 代码风格规范——主要是文字上的规定，看似表面文章，实际上非常重要2. 代码设计规范——牵涉到程序设计、模块之间的关系、设计模式等方方面面的通用原则
4.代码复审的讨论
金无足赤，人无完人，这句话同样适用于代码，任何刚写出来的代码，都不可能是非常完美的，就像人一样，每个人都有这样或那样的缺点，需要我们自己或求助他人帮我们找出自身的缺点和不足，并加以改正，让自己不断的向完美靠近，这同样适用于程序，经过自己和团队其他成员的审核，检查，将程序中的bug和缺陷找出来并改正，让程序不断的向完美靠近。接下来就让我们谈谈如何复审。
首先，复审的人不可能只是自己，仅是自己不可能将程序中的bug全部找出来，还要依靠团队中对自己这部分比较熟悉的人审核，这样效率也比较高。审核的目的主要是查找编码错误，代码规范问题，还有逻辑错误，算法错误，发现潜在的错误和回归性错误，还有需要改进的地方，不仅是这样，复审还能更好地让团员之间更好地了解对方的开发风格，开发习惯等。在审核过程中，要将错误一一记录，如果是比较简单的，直接修改，记录或修改之后继续下一处，等到了最后将错误一一修改，并经过测试无错误之后就可以了。做完这些后，我们需要分析这些错误，进行反思，并将这些错误记住，下次不能再犯同样的错误。
在团队开发的时候，我们经常忽略代码复审的这个环节，每个人自己写完自己的代码之后，自己做测试，自己认为没问题之后就不再管，直到整合的时候，在发现问题就晚了。然而我们忽略的这个环节恰恰是最重要的环节，尤其是对于那些刚刚成立的小组，组员之间彼此都不太熟悉，不了解各自之间的开发风格和习惯，通过代码复审这个过程，让其他人审核饿自己的代码，在找自己错误的过程中了解这个人的开发习惯，这样不但可以增进队友之间的熟悉度，也可以让别人了解你经常犯错的地方。下次可以快速的帮你找到问题，当然找到我们发错误之后，我们要努力改正。通过这本书，我了解到代码复审的重要性，所以在下次的项目中，一定要增加真个过程，让组员之间更加熟悉，了解。
5.阅读别人的代码有多难
我们经常抱怨阅读别人的代码很难， 我们自己在写代码的时候，或许也没有考虑到如何让代码更易于阅读和维护。
几乎很少有人能读代码但不会写代码。所以我们在编写代码时，尽力去做一些事，目的就是使其他人能轻松阅读：1. 使代码遵从工具2. 坚持使用一种命名模式3. 使用断言来记录先决条件（preconditions）和后置条件（postconditions）4. 别缩写英文单词确切来说，别缩写成稀奇古怪的形式。5. C语言标准运行时库的设计不是很优秀。别去效仿它6. 别写“聪明”的代码当代码出现问题，维护代码的程序员没时间去理解你的聪慧。7. 理解编程语言特性的设计初衷，使用这些特性去做它们适合完成的工作，而不是它们能做到的工作8. 按功能单元划分源码树，而不是按组织结构。
6.对于编程中不好的习惯-你经历过么，如何提醒同伴改进
在合作编程中，肯定会出现或多或少的矛盾，那么我们要做到的是善于解决这些矛盾，而不是让矛盾加深。对于不同的分歧问题要大胆的提出，而不是窝在心里不去解决，这样你的同伴也意识不到问题，自己还感觉窝火，两人合作最重要的就是沟通。
原文地址：https://www.cnblogs.com/July1/p/9031409.html