1 、结对项目的案例与论文

　　论文已阅读。

2、性格对合作的影响

　　我的ＭＢＴＩ为：ESTJ 管家型——掌控当下，让各种事务有条不紊地进行

　　ESTJ型的人高效率地工作，自我负责，监督他人工作，合理分配和处置资源，主次分明，井井有条；能制定和遵守规则，多喜欢在制度健全、等级分明、比较稳定的企业工作；倾向于选择较为务实的业务，以有形产品为主 ；喜欢工作中带有和人接触、交流的成分，但不以态度取胜；不特别强调工作的行业或兴趣，多以职业角度看待每一份工作。ESTJ型的人很善于完成任务；他们喜欢操纵局势和促使事情发生；他们具有责任感，信守他们的 承诺。他们喜欢条理性并且能记住和组织安排许多细节。他们及时和尽可能高效率地、系统地开始达到目标。ESTJ型的人被迫做决定。他们常常以自己过去的经历为基础得出结论。他们很客观，有条理性和分析能力，以及 很强的推理能力。事实上，除了符合逻辑外，其他没有什么可以使他们信服。同时，ESTJ型的人又很现实、有头脑、讲求实际。他们更感兴趣的是“真实的事物”，而不是诸如抽象的想法和理论等无形的东西。他们往往对 那些认为没有实用价值的东西不感兴趣。他们知道自己周围将要发生的事情，而首要关心的则是目前。因为ESTJ型的人依照一套固定的规则生活，所以他们坚持不懈和值得依赖。他们往往很传统，有兴趣维护现存的制度。 虽然对于他们来说，感情生活和社会活动并不像生活的其他方面那样重要，但是对于亲情关系，他们却固守不变。他们不但能很轻松地判断别人，而且还是条理分明的纪律执行者。 ESTJ型的人直爽坦率，友善合群。通常他 们会很容易地了解事物，这是因为他们相信“你看到的便是你得到的”。

3.是否需要有代码规范

1. 这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。（反驳）

也许规范对个人的开发效率会有负面影响。但是放到整个团队层面上，它恰恰是能够节约大家的编程时间的东西。那个版本管理员花费的三、四个小时，本来可以用来测试、用来修正bug，却因为我的代码不规范而被浪费掉了。

　　2.我是个艺术家，手艺人，我有自己的规范和原则。（反驳）

一个人的那也叫规范？最多叫个人习惯。足球里有一句话，没有哪个球员比球队更重要。项目组也一样，没有哪个人的个人习惯大过团队规范。
就我那个错误来说，我也有我的规范和原则。事实上，我犯错误的那次所使用的格式化规范，也是我原来所在 项目组的通用规范。但是，在新的项目组里，它变成了我的个人习惯，并且，我的个人习惯导致团队工作受到了严重的影响。如果你是那个新项目组的成员，你能忍我？

　　3.规范不能强求一律，应该允许很多例外。（反驳）

规范应该尽量一致；即使有例外，也只能是少数情况，而不能是很多例外。
说到这个例外，我想起另一个例子来。古人取“字”的时候，常常按兄弟次序取“伯仲叔季幼”，例如“季常”、“幼常”。但有一次有个哥们就问我：为什么这个哥哥字“叔x”，而弟弟字“伯y”？是不是史书写错了？
这就是规范中“例外”情况导致的混淆甚至是混乱。
　　4.我擅长制定编码规范，你们听我的就好了。（反驳）

如果对规范有意见，可以通过一定方法修订并发布新的规范。但是在新的规范发布之前，请遵守旧的规范。

4.代码复审的讨论

5 .阅读别人的代码有多难

关于自己编写代码时，如何让代码更易于阅读与维护。代码维护一定要多注意接口设计。注意你的接口，接口设计完美，整个系统就是完美的。因为即便你出错，做的复杂，他们也封装在完美的接口后面而不会对整个系统造成太大影响。接口设计就是一切。

６.结对编程中不好的习惯——你经历过么，如何提醒同伴改进

*不拘小节的人：两人在一起近距离的工作，但是却不注意个人卫生和互相尊重。开始合作前，吃了很多的大蒜就来了。

*喜欢发号施令的人：总是对敲键盘的人说：“到末行，加个反括号，然后......”。他不去关注解决方法和下一步该怎么做，而过度关注一些编程细节。

*拼写纠错者：坐在你的旁边，纠正你输入的每个错误字符。当然，他没有时间来真正进行导航。

*深藏不露者：仅仅自己敲着代码而不告诉别人他在做什么。领航员不得不靠自己去弄懂代码。关于该用什么方法，该选择哪种设计，领航员和实施者之间完全没有交流。

*跳跃很大的人：他们喜欢在代码中进行大范围的跳跃，这样领航员便不知道进行到哪里了。

1.首先要肯定对方的提醒，其次也向他提出，我们应该首先解决问题，等一下再一起纠正这些编程规范。
2.好像是开车的时候被人不断提醒一样，有的时候这点确实让人心焦，尤其是很多的拼写错误都是一时手误而且编程工具会自动提醒，当遇到这样的伙伴时，我觉得应该引导他像别的方向注意，在编程前就提出一定的问题希望帮忙留意。让其把重点放在代码上。
3.以前在另一个课程设计时做过项目经理，这点倒是经历过，当时还是大二，编程水平高的同学没有现在这么多，一个组里往往会有一个超过别人很多的人，他的思路和使用的新的技术往往让人一头雾水。结构和代码也不太理解。这个时候应该做出改变的不只是实施者，还有看代码的人，要直接提出疑问，让实施者回答，并且多进行讨论交流意见，并且希望在编程中注释。
4.在看别人编程时，修改代码时，因为不熟悉别人的代码，修改时大幅度的跳跃和转换，让人不知道整个工程的现状。这个时候可以适当让实施者停下，和他讨论修改或者跳跃的原因，理清思路。