现代软件工程 第四章 【结对编程】练习与讨论

  1. 云栖社区>
  2. 博客>
  3. 正文

现代软件工程 第四章 【结对编程】练习与讨论

嗯哼9925 2017-11-07 19:28:00 浏览1078
展开阅读全文

4.7.0 结对编程的练习题

         地铁导航和遍历

4.7.1  结对项目的案例和论文

在现代软件工程教学的过程中,同学们已经总结了不少切身体会。例如:

总结1[i]
那是project到了比较关键的创造阶段,整整一天,我们俩椅子靠椅子的坐在电脑前,一边讨论一般coding,那次才真正的体会到结对真的能够带来效率。一整天的coding是容易走神的事,还好有pair在旁边指导,总是不断在我敲某某变量之前提前告诉我成员变量的名字,数据修改时帮忙检查是否有漏掉的,变量和函数定义的时候一起为其取名字,感觉有点眼花了,就换了个角色,我也开始对他“指指点点”了,一个人coding,一个人review,确实能减少一些不必要的错误,减少一些漏洞,算法实现后一起做些简单的测试,看到bug了再一起分析,我能明显的感觉到与以前的个人编程不一样,我们能比较快的找到bug初始点,并能提出比较的修改方法。特别是当看到功能进一步实现时,心里确实挺happy,更重要的这份感受有同伴与你一起分享。

总结2[ii]
于是我们进行了项目中最关键的一次Pair Programming,我们利用编译课上机时间,在机房里Pair完成了整个项目的类的设计与程序结构的设计。我们一起分析出类,然后找属性,写方法头,开始是WG用键盘,后来我用。一个明显的好处是,写完一条自己不确定的语句,马上可以跟Pair一起缕一缕思路。一下午下来,感觉甚为清爽,因为终于清楚这个项目的做法了。

学术界、工业界对结对编程已经有不少研究,请阅读至少两篇相关论文或论文[iii]

4.7.2  性格对合作的影响

人和人不一样,在和别人合作的时候,要注意各人表达观点的方式和思考的方式不尽相同。请看网上关于MBTI的文章[iv],测试并分享各自的MBTI类型,讨论不同性格类型对合作有多大的影响, 在合作的各个阶段应该如何应对[v]

4.7.3  是否需要有代码规范

对于是否需要有代码规范[vi],请考虑下列论点并反驳/支持:

  1. 这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。
  2. 我是个艺术家,手艺人,我有自己的规范和原则。
  3. 规范不能强求一律,应该允许很多例外。
  4. 我擅长制定编码规范,你们听我的就好了。

代码复审检查表: http://blog.fogcreek.com/increase-defect-detection-with-our-code-review-checklist-example/ 

4.7.4  代码复审的讨论

小飞: 哇,这么多酷的C++ 功能都不能用,那我们还学什么C++,为了迎接考试,我都把Operator Overload、Polymorphism背得滚瓜烂熟了,为什么不让我用?

阿超: 我们写程序是为了解决问题,不是“为赋新词强说愁”,这些高级的语言特性,不是不让用,而是要用得慎重,不要动不动就写三五个类,一个套一个,要把注意力集中在能否用简洁的方法解决问题上来。

小飞: 这么多规范,我不知道怎么写第一行程序了。

阿超: 自我复审也很重要——把代码摆在面前,当作是别的菜鸟写的。把你通常问别人的,以及别人会问你的问题都自己问一遍。这样就能发现不少问题。

小飞: 如果开发者很厉害,那么复审者就没有什么作用,也许这些复审都是走过场?

阿超: 同理可以推论,如果开发者很厉害,那么测试人员也没什么作用,也是走过场,干脆把他们送回家得了。我们敢这样做么?

小飞: 这些规范啊, 建议啊, 都是细枝末节的东西, 我们要做世界级的软件,搞这些东西是不是太小家子气了?

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

 

4.7.5 阅读别人的代码有多难?

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

 

别人的代码: 

来源: http://dhruba.name/2012/08/21/do-you-hate-reading-other-peoples-code/ 

 

http://kb.cnblogs.com/page/192086/

 
4.7.6  结对编程中不好的习惯 - 你经历过么?
  •   喜欢发号施令的人总是对敲键盘的人说:“到末行,加个反括号,然后…”。他不去关注解决方法和下一步该怎么做,而过度关注一些编程细节。
  •   拼写纠错者坐在你旁边,纠正你输入的每个错误字符。当然,他没有时间来真正的进行导航。
  •   深藏不露者仅仅自己敲着代码而不告诉别人他在做什么。领航员不得不靠自己去弄懂代码。关于该用什么方法,该选择哪种设计,领航员和实施者之间完全没有交流。
  •   跳跃很大的人喜欢在代码中进行大范围的跳跃,这样领航员不知道进行到哪里了。
 
4.7.7  对合作伙伴的评价
(这个作业在学期结束的时候做)
经过一个学期的各种项目,你(一个学生)和至少6-7 个同学深入地合作过。  你一定会对大家的合作精神有切身体会。 我们来做一个统计:
每个学生在期末填写一个一维的表格 (没有并列),  像下面这样, 把你的小伙伴的合作精神由高到底列出来:
 
学生甲
学生乙
。。。
你自己(标明自己的名字)
学生丙
学生丁
。。。
 
最后老师会统计出来,整个学生集合中,谁的合作精神比较好,谁比较不好 (在同伴的眼里)。 计分方法是:“你自己” 得 0 分;  在 “你自己” 之上一格的同学得一分; 在“你自己” 之上两格的同学得两分,以此类推。。。  在“你自己” 之下的同学依次得 -1,-2, -3, ... 分。


[iii]     参见:http://c2.com/cgi/wiki?PairProgrammingCaseStudy 以及 http://www.thefreelibrary.com/Case+study%3a+using+pair+programming+in+development+of+a+complex+module.-a0246014267 以及http://www.cs.utexas.edu/users/mckinley/305j/pair-hcs-2006.pdf

其它论文:

    Williams, Laurie, Robert Kessler, Ward Cunningham, and Ron Jeffries. 2000. “Strengthening the Case for Pair Programming.” IEEE Software 17, no. 4.

 

[v]     另外请参见 《对性格内向者的10个误解》: http://blog.jobbole.com/12488/

[vii]     参见:http://en.wikipedia.org/wiki/Broken_windows_theory

 








本文转自SoftwareTeacher博客园博客,原文链接:http://www.cnblogs.com/xinz/p/3852241.html,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
嗯哼9925
+ 关注