第四章 练习与讨论

1、结对项目的案例和论文
学术界、工业界对结对编程已经有不少研究，请阅读至少两篇相关论文或论文，结合自己的切身体会总结一下。
（1）提高效率
　　结对编程的形式使得代码处于不断地审查过程，每一段代码都由一个人编写，另一个人检查，最大程度上减少了出现bug的可能；两人互相交流，商讨实现方式，遇到问题时，能够做到互补。
（2）互相学习
　　结对编程也是一个互相学习的过程。在结对编程过程中，两人会不断对实现方法、代码风格或命名方法等进行讨论，两个人的思路能够进行互补，在编写过程中能够学到对方解决问题的思路和方法，对于提高自己解决问题和编程能力有很大的帮助。

2.性格对合作的影响
人和人不一样，在和别人合作的时候，要注意各人表达观点的方式和思考的方式不尽相同。请看网上关于MB TI的文章[注释4]，测试并分享各自的MB TI类型，讨论不同性格类型对合作有多大的影响，在合作的各个阶段应该如何应对[注释5]。
(1)这个是我的测试：http://www.apesk.com/mbti/submit_email_date.asp?code=223.73.241.5&user=16614475
(2)
外向（E）和内向（I）
感觉（S）和直觉（N）
思考（T）和情感（F）
判断（J）和知觉（P）

ISTJ

安静、严肃，通过全面性和可靠性获得成功。实际，有责任感。决定有逻辑性，并一步步地朝着目标前进，不易分心。喜欢将工作、家庭和生活都安排得井井有条。重视传统和忠诚。

ISFJ

安静、友好、有责任感和良知。坚定地致力于完成他们的义务。全面、勤勉、精确，忠诚、体贴，留心和记得他们重视的人的小细节，关心他人的感受。努力把工作和家庭环境营造得有序而温馨。

INFJ

寻求思想、关系、物质等之间的意义和联系。希望了解什么能够激励人，对人有很强的洞察力。有责任心，坚持自己的价值观。对于怎样更好的服务大众有清晰的远景。在对于目标的实现过程中有计划而且果断坚定。

INTJ

在实现自己的想法和达成自己的目标时有创新的想法和非凡的动力。能很快洞察到外界事物间的规律并形成长期的远景计划。一旦决定做一件事就会开始规划并直到完成为止。多疑、独立，对于自己和他人能力和表现的要求都非常高。

ISTP

灵活、忍耐力强，是个安静的观察者直到有问题发生，就会马上行动，找到实用的解决方法。分析事物运作的原理，能从大量的信息中很快的找到关键的症结所在。对于原因和结果感兴趣，用逻辑的方式处理问题，重视效率。

ISFP

安静、友好、敏感、和善。享受当前。喜欢有自己的空间，喜欢能按照自己的时间表工作。对于自己的价值观和自己觉得重要的人非常忠诚，有责任心。不喜欢争论和冲突。不会将自己的观念和价值观强加到别人身上。

INFP

理想主义，对于自己的价值观和自己觉得重要的人非常忠诚。希望外部的生活和自己内心的价值观是统一的。好奇心重，很快能看到事情的可能性，能成为实现想法的催化剂。寻求理解别人和帮助他们实现潜能。适应力强，灵活，善于接受，除非是有悖于自己的价值观的。

INTP

对于自己感兴趣的任何事物都寻求找到合理的解释。喜欢理论性的和抽象的事物，热衷于思考而非社交活动。安静、内向、灵活、适应力强。对于自己感兴趣的领域有超凡的集中精力深度解决问题的能力。多疑，有时会有点挑剔，喜欢分析。

ESTP

灵活、忍耐力强，实际，注重结果。觉得理论和抽象的解释非常无趣。喜欢积极地采取行动解决问题。注重当前，自然不做作，享受和他人在一起的时刻。喜欢物质享受和时尚。学习新事物最有效的方式是通过亲身感受和练习。

ESFP

外向、友好、接受力强。热爱生活、人类和物质上的享受。喜欢和别人一起将事情做成功。在工作中讲究常识和实用性，并使工作显得有趣。灵活、自然不做作，对于新的任何事物都能很快地适应。学习新事物最有效的方式是和他人一起尝试。

ENFP

热情洋溢、富有想象力。认为人生有很多的可能性。能很快地将事情和信息联系起来，然后很自信地根据自己的判断解决问题。总是需要得到别人的认可，也总是准备着给与他人赏识和帮助。灵活、自然不做作，有很强的即兴发挥的能力，言语流畅。

ENTP

反应快、睿智，有激励别人的能力，警觉性强、直言不讳。在解决新的、具有挑战性的问题时机智而有策略。善于找出理论上的可能性，然后再用战略的眼光分析。善于理解别人。不喜欢例行公事，很少会用相同的方法做相同的事情，倾向于一个接一个的发展新的爱好。

ESTJ

实际、现实主义。果断，一旦下决心就会马上行动。善于将项目和人组织起来将事情完成，并尽可能用最有效率的方法得到结果。注重日常的细节。有一套非常清晰的逻辑标准，有系统性地遵循，并希望他人也同样遵循。在实施计划时强而有力。

ESFJ

热心肠、有责任心、合作。希望周边的环境温馨而和谐，并为此果断地执行。喜欢和他人一起精确并及时地完成任务。事无巨细都会保持忠诚。能体察到他人在日常生活中的所需并竭尽全力帮助。希望自己和自己的所为能受到他人的认可和赏识。

ENFJ

热情、为他人着想、易感应、有责任心。非常注重他人的感情、需求和动机。善于发现他人的潜能，并希望能帮助他们实现。能成为个人或群体成长和进步的催化剂。忠诚，对于赞扬和批评都会积极地回应。友善、好社交。在团体中能很好地帮助他人，并有鼓舞他人的领导能力。

ENTJ

坦诚、果断，有天生的领导能力。能很快看到公司/组织程序和政策中的不合理性和低效能性，发展并实施有效和全面的系统来解决问题。善于做长期的计划和目标的设定。通常见多识广，博览群书，喜欢拓广自己的知识面并将此分享给他人。在陈述自己的想法时非常强而有力。
3.是否需要有代码规范
对于是否需要有代码规范[注释6]，请考虑下列论点并反驳/支持：
1）这些规范都是官僚制度下产生的、浪费大家的编程时间、影响人们开发效率、浪费时间的东西。
2）我是个艺术家，手艺人，我有自己的规范和原则。
3）规范不能强求一律，应该允许很多例外。
4）我擅长制定编码规范，你们听我的就好了。代码复审检查表：
答：1）不支持这个观点。代码规范并不是官僚主义的产物，而是为了增加代码的可读性，使代码变得易读且易维护。书写符合代码规范的代码并不会降低开发效率，相反，这样做可以提高人们的开发、维护效率。在刚开始写代码的时候，老师就叮嘱我们要培养一个良好的代码风格，不仅仅是为了自己在以后阅读的时候能够方便简单的读懂，也是为了便于他人阅读理解。尤其是在团队合作的时候，如果每个人都很随意的自己用自己的方式，不仅不好维护，互相也不能理解代码意思。这样反而拖延工作量，浪费时间，降低效率。
就好比无规矩不成方圆，如果每个人都坚持自己的代码风格不做规范，那么在代码交接的时候会因为彼此的意见观点不同发生冲突更让人厌烦。所浪费的时间要比制定规范的时候浪费的更多。
2）观点2，不支持这种观点。编程的艺术不是从代码规范中体现的，代码的艺术更多的体现在算法设计、数据结构的选取等方面。符合一定的公认的代码规范只会为我们的代码添彩，不会降低代码的艺术性。我认同程序员也可以称得上艺术家，我们和他们的不同就是我们的艺术发挥在机器上。每个人都是不一样的，每个人都有自己的习惯爱好，就如同每一位艺术家手艺人都会用自己的方式在作品上留下属于自己的记号，但是很多时候不是独特才是最好的，有许多事并不一定有什么最佳答案，只要能解决问题的方法就是好方法。同样，规范风格有时候也谈不上是不是最好的，应用起来方便、高效，这就是好规范。

3）观点3，不支持这种观点。每个团队都可以制定自己的代码规范，但是这也是要建立在一定的公认的基础上的。因为公认的代码规范之所以能流传下来，一定有他的道理，这样的代码规范符合人们对代码的认知，便于大家理解代码。国家政策也是根据地区不同制定不同的规则。代码规范也不是强制的全部一模一样。如果遇到一些因为代码规范不能解决的问题，那么就不得不变通了。对于一个团队而言，我们每个人都只是一份子没有谁是绝对的独裁者，因为合作所以我们要照顾每个人的风格
4）观点4，不支持这种观点。一个团队的代码规范往往需要结合大家的意愿来制定，一些规范（比如大括号不换行和大括号换行的两种信仰……）不能仅听一个人的，而应符合大多数人的习惯。这种想法不仅仅是在码代码的合作时不能有这种想法，为人处世其他方面也都厌烦这种专制。
4.代码复审的讨论
小飞：哇，这么多酷的C++功能都不能用，那我们还学什么C++，为了迎接考试，我都把OperatorOverload、Polymorphism背得滚瓜烂熟了，为什么不让我用？
阿超：我们写程序是为了解决问题，不是“为赋新词强说愁”，这些高级的语言特性，不是不让用，而是要用得慎重，不要动不动就写三五个类，一个套一个，要把注意力集中在能否用简洁的方法解决问题上来。
小飞：这么多规范，我都不知道怎么写第一行程序了。
阿超：自我复审也很重要——把代码摆在面前，当作是别的菜鸟写的。把你通常问别人的，以及别人会问你的问题都自己问一遍，这样就能发现不少问题。
小飞：如果开发者很厉害，那么复审者就没有什么作用，也许这些复审都是走过场？
阿超：同理可以推论，如果开发者很厉害，那么测试人员也没什么作用，也是走过场，干脆把他们送回家得了。我们敢这样做么？
小飞：这些规范啊，建议啊，都是细枝末节的东西，我们要做世界级的软件，搞这些东西是不是太小家子气了？
阿超：首先世界级的软件也会因为小小的纰漏而导致世界级的问题。例如我们常常听到的安全漏洞和紧急补丁。其次，软件的开发是一个社会性的活动，有它的规律。其中一个规律就是“破窗效应”（Broken Windows Theory），如果团队成员看到同伴们连一些细小的规范都不遵守，那自己还要严格执行单元测试么？另一个成员看到这个模块连单元测试都没有，那他自己也随意修改算了。这样下去，整个软件的质量可想而知。
答： 首先世界级的软件也会因为小小的纰漏而导致世界级的问题。例如我们常常听到的安全漏洞和紧急补丁。其次，软件的开发是一个社会性的活动, 有它的规律。其中一个规律就是“破窗效应”，如果团队成员看到同伴们连一些细小的规范都不遵守，那自己还要严格执行单元测试么？另一个成员看到这个模块连单元测试都没有，那他自己也随意修改算了。这样下去，整个软件的量可想而知。所以代码应该复审，规范应该要保持。
5.阅读别人的代码有多难？我们经常抱怨阅读别人的代码很难，我们自己在写代码的时候，是否考虑到如何让代码更易于阅读和维护呢？
https://kb.cnblogs.com/page/192086/
(1)坚持使用一种命名模式
如果你打算用匈牙利命名法，那就坚持并广泛使用，否则将适得其反。使用匈牙利命名法来记录数据，而不是存储类型；记录普遍事实，而不是临时条件。
(2) 别缩写英文单词
确切来说，别缩写成稀奇古怪的形式。
6.结对编程中不好的习惯—你经历过么，如何提醒同伴改进？
不拘小节的人　两人在一起近距离地工作，但是却不注意个人卫生和互相尊重。开始合作前，吃了很多大蒜就来了。
喜欢发号施令的人　总是对敲键盘的人说：“到末行，加个反括号，然后……”。他不去关注解决方法和下一步该怎么做，而过度关注一些编程细节。
拼写纠错者　坐在你旁边，纠正你输入的每个错误字符。当然，他没有时间来真正地进行导航。
深藏不露者　仅仅自己敲着代码而不告诉别人他在做什么。领航员不得不靠自己去弄懂代码。关于该用什么方法，该选择哪种设计，领航员和实施者之间完全没有交流。
跳跃很大的人　他们喜欢在代码中进行大范围的跳跃，这样领航员便不知道进行到哪里了。
答：（1）个人的仪表是对对方的尊重，如果我的同伴真的这样，首先我会提出一起去外面咖啡厅工作或者讨论，这样一般就会适当得体一些，并且给他口香糖吃。
（2）首先要肯定对方的提醒，其次也向他提出，我们应该首先解决问题，等一下再一起纠正这些编程规范。
（3）好像是开车的时候被人不断提醒一样，有的时候这点确实让人心焦，尤其是很多的拼写错误都是一时手误而且编程工具会自动提醒，当遇到这样的伙伴时，我觉得应该引导他像别的方向注意，在编程前就提出一定的问题希望帮忙留意。让其把重点放在代码上。
（4）一个组里往往会有一个超过别人很多的人，他的思路和使用的新的技术往往让人一头雾水。结构和代码也不太理解。这个时候应该做出改变的不只是实施者，还有看代码的人，要直接提出疑问，让实施者回答，并且多进行讨论交流意见，并且希望在编程中注释。
（5）在看别人编程时，修改代码时，因为不熟悉别人的代码，修改时大幅度的跳跃和转换，让人不知道整个工程的现状。这个时候可以适当让实施者停下，和他讨论修改或者跳跃的原因，理清思路。