第四章

Posted 2020-11-20 lgx19

一。学术界、工业界对结对编程已经有不少研究，请阅读至少两篇相关论文或论文，结合自己的切身体会总结一下？

（1）提高效率
　　结对编程的形式使得代码处于不断地审查过程，每一段代码都由一个人编写，另一个人检查，最大程度上减少了出现bug的可能；两人互相交流，商讨实现方式，遇到问题时，能够做到互补。
（2）互相学习
　　结对编程也是一个互相学习的过程。在结对编程过程中，两人会不断对实现方法、代码风格或命名方法等进行讨论，两个人的思路能够进行互补，在编写过程中能够学到对方解决问题的思路和方法，对于提高自己解决问题和编程能力有很大的帮助。

二。性格对合作的影响？

（1）
外向（E）和内向（I）
感觉（S）和直觉（N）
思考（T）和情感（F）
判断（J）和知觉（P）

（2）

ISTJ

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

ISFJ

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

INFJ

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

INTJ

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

ISTP

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

ISFP

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

INFP

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

INTP

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

ESTP

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

ESFP

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

ENFP

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

ENTP

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

ESTJ

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

ESFJ

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

ENFJ

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

ENTJ

坦诚、果断，有天生的领导能力。能很快看到公司/组织程序和政策中的不合理性和低效能性，发展并实施有效和全面的系统来解决问题。善于做长期的计划和目标的设定。通常见多识广，博览群书，喜欢拓广自己的知识面并将此分享给他人。在陈述自己的想法时非常强而有力。

三。是否需要有代码规范？

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

- （2）我是个艺术家，手艺人，我有自己的规范和原则？

- （3）规范不能强求一律，应该允许很多例外？

- （4）我擅长制定编码规范，你们听我的就好了？

       首先，代码规范是一定要有的，这一点不容置疑。记得刚学C语言时，老师跟我们讲一些编码的例子，譬如说等号两边要加空格，运算符的两边也要加空格。那个时候打心眼里觉得这些规矩太过繁琐迂腐，觉得咱们中国人就是喜欢搞这种形式化的东西。

      说心里话，按照系统的提示，将代码一点一点修改后，明显感觉到代码从视觉上更为美观了。与此同时我也逐步发现身边的同学们也在养成这样的习惯，自己也理解了这样规范的意义所在。所谓规范，更像是一种约定俗成的惯例，你可以选择不遵守，规范并不是法律。但是只要你需要融入一个集体，需要和一群人进行交流，合作完成一个项目，需要阅读别人的代码也需要把自己的代码供他人阅读，这时候，规范的价值就得以体现。如果团体内的成员都能够遵守同样的规范，养成一种被普遍接受的代码风格，那么会减少很多阅读习惯带来的困扰，能够让大家心情愉悦。

基于以上的感悟，其实上面的几个问题就不难回答了。

（1）.比起在命名上花点心思、敲几个空格浪费的时间，读代码时不能正确理解变量的含义，因为代码堆在一起看着心情烦躁更加影响效率、浪费时间。

（2）..这一点并没有问题，如果你的能力特别强，能够独立支撑起一个庞大的项目，在今后的工作中完全不需要和别人合作，那你可以特立独行。

（3）..这一点并没有问题，如果你的能力特别强，能够独立支撑起一个庞大的项目，在今后的工作中完全不需要和别人合作，那你可以特立独行。

（4）.有资格说这句话的人，整个计算机科学界，基本不超过十个。

四。代码复审的讨论
小飞：哇，这么多酷的C++功能都不能用，那我们还学什么C++，为了迎接考试，我都把OperatorOverload、Polymorphism背得滚瓜烂熟了，为什么不让我用？
阿超：我们写程序是为了解决问题，不是“为赋新词强说愁”，这些高级的语言特性，不是不让用，而是要用得慎重，不要动不动就写三五个类，一个套一个，要把注意力集中在能否用简洁的方法解决问题上来。
小飞：这么多规范，我都不知道怎么写第一行程序了。
阿超：自我复审也很重要——把代码摆在面前，当作是别的菜鸟写的。把你通常问别人的，以及别人会问你的问题都自己问一遍，这样就能发现不少问题。
小飞：如果开发者很厉害，那么复审者就没有什么作用，也许这些复审都是走过场？
阿超：同理可以推论，如果开发者很厉害，那么测试人员也没什么作用，也是走过场，干脆把他们送回家得了。我们敢这样做么？
小飞：这些规范啊，建议啊，都是细枝末节的东西，我们要做世界级的软件，搞这些东西是不是太小家子气了？
阿超：首先世界级的软件也会因为小小的纰漏而导致世界级的问题。例如我们常常听到的安全漏洞和紧急补丁。其次，软件的开发是一个社会性的活动，有它的规律。其中一个规律就是“破窗效应”（Broken Windows Theory），如果团队成员看到同伴们连一些细小的规范都不遵守，那自己还要严格执行单元测试么？另一个成员看到这个模块连单元测试都没有，那他自己也随意修改算了。这样下去，整个软件的质量可想而知。

       首先世界级的软件也会因为小小的纰漏而导致世界级的问题。例如我们常常听到的安全漏洞和紧急补丁。其次，软件的开发是一个社会性的活动, 有它的规律。其中一个规律就是“破窗效应”，如果团队成员看到同伴们连一些细小的规范都不遵守，那自己还要严格执行单元测试么？另一个成员看到这个模块连单元测试都没有，那他自己也随意修改算了。这样下去，整个软件的量可想而知。所以代码应该复审，规范应该要保持。

五。阅读别人的代码有多难？我们经常抱怨阅读别人的代码很难，我们自己在写代码的时候，是否考虑到如何让代码更易于阅读和维护呢？

    总结文章中主要观点：

    使代码遵从工具；

    坚持使用一种命名模式；

    使用断言来记录先决条件（preconditions）和后置条件（postconditions）；

    别缩写英文单词；

    C语言标准运行时库的设计不是很优秀。别去效仿它；

    别写“聪明”的代码；

    理解编程语言特性的设计初衷，使用这些特性去做它们适合完成的工作，而不是它们能做到的工作；

    按功能单元划分源码树，而不是按组织结构；

六。结对编程中不好的习惯—你经历过么，如何提醒同伴改进？
不拘小节的人　两人在一起近距离地工作，但是却不注意个人卫生和互相尊重。开始合作前，吃了很多大蒜就来了。
喜欢发号施令的人　总是对敲键盘的人说：“到末行，加个反括号，然后……”。他不去关注解决方法和下一步该怎么做，而过度关注一些编程细节。
拼写纠错者　坐在你旁边，纠正你输入的每个错误字符。当然，他没有时间来真正地进行导航。
深藏不露者　仅仅自己敲着代码而不告诉别人他在做什么。领航员不得不靠自己去弄懂代码。关于该用什么方法，该选择哪种设计，领航员和实施者之间完全没有交流。
跳跃很大的人　他们喜欢在代码中进行大范围的跳跃，这样领航员便不知道进行到哪里了。

（1）：个人的仪表是对对方的尊重，如果我的同伴真的这样，首先我会提出一起去外面咖啡厅工作或者讨论，这样一般就会适当得体一些。

（2）：首先要肯定对方的提醒，其次也向他提出，我们应该首先解决问题，等一下再一起纠正这些编程规范。

（3）：好像是开车的时候被人不断提醒一样，有的时候这点确实让人心焦，尤其是很多的拼写错误都是一时手误而且编程工具会自动提醒，当遇到这样的伙伴时，我觉得应该引导他像别的方向注意，在编程前就提出一定的问题希望帮忙留意。让其把重点放在代码上。

（4）：一个组里往往会有一个超过别人很多的人，他的思路和使用的新的技术往往让人一头雾水。结构和代码也不太理解。这个时候应该做出改变的不只是实施者，还有看代码的人，要直接提出疑问，让实施者回答，并且多进行讨论交流意见，并且希望在编程中注释。

（5）：在看别人编程时，修改代码时，因为不熟悉别人的代码，修改时大幅度的跳跃和转换，让人不知道整个工程的现状。这个时候可以适当让实施者停下，和他讨论修改或者跳跃的原因，理清思路。