结对编程收获
结对编程收获
结对项目总结
总结博客地址:http://www.cnblogs.com/ustcfanli/p/8847037.html
技术提升
C++ 编程
联想到第一次个人代码作业,由于一开始思考得不够充分,导致后面重构代码,其中大费周折,那些当时看似是浪费的精力,到回头来看的时候都变成了宝贵的并无比真切的经验。所以这次作业一开始的时候,我们就并未着急编写,仔细思考了多种方案。最终选择创建储存操作信息的类,并用类去创建二叉树刻画表达式的信息。
首先,由于操作数可能是整数,小数,或者分数,因此计算起来会比较麻烦。但是我们先总结归纳了操作数统一的性质,其实也很简单,计算的数都是有理数,即所有的数都能以分子和分母的形式存储,而加减乘除乘方的计算就是对于该类的运算符的重载,因此需要创建类来存储操作数信息。
而对于表达式,即使用 string 类也能生成和计算,但是考虑到我们要进行查重、检测、计算甚至修改等操作,string 是不利于维护的,而二叉树则拥有天然的优势,因为二叉树其实反映了最本质的信息,而其中递归的操作也更能反映计算或维护表达式的本质结构,因此运用我们创建的类进行创建二叉树。
回过头来看,一开始可能会觉得创建类,重载方法可能会很麻烦,毕竟 C++ 用的也并不熟悉。而且二叉树比起直接用 string 来说看似更加复杂。但是我们并没有因为一时的抵触而放弃思考,事实上证明这种结构是对的,在分工之后,很快我们就写出了二叉树的随机生成和递归计算递归维护,之后并未进行代码的重构,顺利地完成了项目。其中练习了 C++ 只是其中的一方面,在加深了面向对象的理解之余,更深的认识是,我们应该将要处理的信息总结出统一的结构,找出不变而简洁的属性,刻画最本质的结构和信息,这对以后的编程极为有帮助。
DLL 对接
DLL 对接是后期最大的一个问题,在仔细学习了相关博客之后,尝试并调整之后,我实现起来并不困难。但其中一个重大的问题是,接口的问题,由于之前的放养状态,其实我们并未规定一个统一的接口,导致 UI 组在测试的时候可能面临巨大的工作量。
由此还要反思,既然是两组之间需要对接,那么就需要加强沟通,不能等到最后期限将至的时候才去思考这个问题。而如果再去发沟通时,即各组各做各的时候也应该为别的组设身处地地想一想,尽量提供更人性化的接口,比如既用 string 类,同时也支持文件读写,这其实在代码上改动并不大,但是在与 UI 组缺乏沟通的时候,当两组都充分为对方考虑时,最终对接会简单很多。
结对分工
结对编程可以极大地提高效率,但前提是建立在合理分工的基础上的。
在实际编写代码之前,我们是一同进行规划的,这时候两个人的思维会被互相启发,考虑也会更加完善和细致。
而在具体代码编写的时候,两个人需要分别谈一谈对任务的理解,并结合自己的思维偏好和编程偏好,比如由于我用 C++ 相对更熟一点,我就负责类的封装,并进行二叉树的递归计算和维护;而我觉得随机生成表达式树的任务可能比较麻烦,而队友则觉得更有思路,后来完成得也很出色。当两人进行充分沟通并合理分工的时候,效率大大提高。
而最后我们自己编写测试程序的时候,又是分别测试的,这样避免了个人思维偶然性对队友的影响,两人分别测试更能检测出 bug 并更加详尽的考虑到了各种情况,最终程序更加健壮和易用。
佛系心态
面对再一次的编程任务,我们抱以一种佛系的心态,一开始并未着急编写,吸取上次经验,讨论了很多种方案,仔细分析优劣,最终理清思路并梳理了整体的框架,有条不紊地编写时并未出现太多意料之外的困难。
面对问题的处理方式是多种多样的,结对编程优势之一就是,两个人的积极性互相被调动,个人陷入局部困境导致整体目标变模糊的概率也大为减小,与之同时,不论焦急还是从容,死限 DDL 来临的速率是一个常数,所以不妨用更加佛系的心态,减少实际行动中漫无目的或毫无效率忙碌,更多地在思维活跃而清晰之下充分调用自身能力,稳健地去面对。
非智力收获
既然甲方频繁更改需求,并认为这(看似)合情合理,也是日后的常态;那么乙方奋起反抗,并且真的合情合理地表达心声,也应该成为一种常态,只是在一部分面向 RMB 编程的未来的日子里,也许有更多的无奈。但希望还是用能力说话,真正用好的产品去说服他人,也真正为社会做点微小的工作。
另外,从心理上而言,这次任务是不少同学心中的一个节点,完成之后内心解脱,进入下一个相对轻松的状态;但是突如其来的重新提交测评的任务,会让人从心理上有一定波动,不引起公愤才怪,所以以后教育工作者应该更合理地站在学生的角度考虑,至少从心理方面多做一些体贴的思考。