第四章

Posted lgx19

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了第四章相关的知识,希望对你有一定的参考价值。

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

(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):在看别人编程时,修改代码时,因为不熟悉别人的代码,修改时大幅度的跳跃和转换,让人不知道整个工程的现状。这个时候可以适当让实施者停下,和他讨论修改或者跳跃的原因,理清思路。

 

 





















以上是关于第四章的主要内容,如果未能解决你的问题,请参考以下文章

第四章

第四章(上)

第四章队列

Python第四章

python 入门到实践第四章案例

构建之法 第四章 读后感