结对编程收获

结对编程收获

结对项目总结

总结博客地址：http://www.cnblogs.com/ustcfanli/p/8847037.html

 

技术提升

C++ 编程

联想到第一次个人代码作业，由于一开始思考得不够充分，导致后面重构代码，其中大费周折，那些当时看似是浪费的精力，到回头来看的时候都变成了宝贵的并无比真切的经验。所以这次作业一开始的时候，我们就并未着急编写，仔细思考了多种方案。最终选择创建储存操作信息的类，并用类去创建二叉树刻画表达式的信息。

首先，由于操作数可能是整数，小数，或者分数，因此计算起来会比较麻烦。但是我们先总结归纳了操作数统一的性质，其实也很简单，计算的数都是有理数，即所有的数都能以分子和分母的形式存储，而加减乘除乘方的计算就是对于该类的运算符的重载，因此需要创建类来存储操作数信息。

而对于表达式，即使用 string 类也能生成和计算，但是考虑到我们要进行查重、检测、计算甚至修改等操作，string 是不利于维护的，而二叉树则拥有天然的优势，因为二叉树其实反映了最本质的信息，而其中递归的操作也更能反映计算或维护表达式的本质结构，因此运用我们创建的类进行创建二叉树。

回过头来看，一开始可能会觉得创建类，重载方法可能会很麻烦，毕竟 C++ 用的也并不熟悉。而且二叉树比起直接用 string 来说看似更加复杂。但是我们并没有因为一时的抵触而放弃思考，事实上证明这种结构是对的，在分工之后，很快我们就写出了二叉树的随机生成和递归计算递归维护，之后并未进行代码的重构，顺利地完成了项目。其中练习了 C++ 只是其中的一方面，在加深了面向对象的理解之余，更深的认识是，我们应该将要处理的信息总结出统一的结构，找出不变而简洁的属性，刻画最本质的结构和信息，这对以后的编程极为有帮助。

 

DLL 对接

DLL 对接是后期最大的一个问题，在仔细学习了相关博客之后，尝试并调整之后，我实现起来并不困难。但其中一个重大的问题是，接口的问题，由于之前的放养状态，其实我们并未规定一个统一的接口，导致 UI 组在测试的时候可能面临巨大的工作量。

由此还要反思，既然是两组之间需要对接，那么就需要加强沟通，不能等到最后期限将至的时候才去思考这个问题。而如果再去发沟通时，即各组各做各的时候也应该为别的组设身处地地想一想，尽量提供更人性化的接口，比如既用 string 类，同时也支持文件读写，这其实在代码上改动并不大，但是在与 UI 组缺乏沟通的时候，当两组都充分为对方考虑时，最终对接会简单很多。

 

结对分工

结对编程可以极大地提高效率，但前提是建立在合理分工的基础上的。

在实际编写代码之前，我们是一同进行规划的，这时候两个人的思维会被互相启发，考虑也会更加完善和细致。

而在具体代码编写的时候，两个人需要分别谈一谈对任务的理解，并结合自己的思维偏好和编程偏好，比如由于我用 C++ 相对更熟一点，我就负责类的封装，并进行二叉树的递归计算和维护；而我觉得随机生成表达式树的任务可能比较麻烦，而队友则觉得更有思路，后来完成得也很出色。当两人进行充分沟通并合理分工的时候，效率大大提高。

而最后我们自己编写测试程序的时候，又是分别测试的，这样避免了个人思维偶然性对队友的影响，两人分别测试更能检测出 bug 并更加详尽的考虑到了各种情况，最终程序更加健壮和易用。

 

佛系心态

面对再一次的编程任务，我们抱以一种佛系的心态，一开始并未着急编写，吸取上次经验，讨论了很多种方案，仔细分析优劣，最终理清思路并梳理了整体的框架，有条不紊地编写时并未出现太多意料之外的困难。

面对问题的处理方式是多种多样的，结对编程优势之一就是，两个人的积极性互相被调动，个人陷入局部困境导致整体目标变模糊的概率也大为减小，与之同时，不论焦急还是从容，死限 DDL 来临的速率是一个常数，所以不妨用更加佛系的心态，减少实际行动中漫无目的或毫无效率忙碌，更多地在思维活跃而清晰之下充分调用自身能力，稳健地去面对。

 

非智力收获

既然甲方频繁更改需求，并认为这（看似）合情合理，也是日后的常态；那么乙方奋起反抗，并且真的合情合理地表达心声，也应该成为一种常态，只是在一部分面向 RMB 编程的未来的日子里，也许有更多的无奈。但希望还是用能力说话，真正用好的产品去说服他人，也真正为社会做点微小的工作。

另外，从心理上而言，这次任务是不少同学心中的一个节点，完成之后内心解脱，进入下一个相对轻松的状态；但是突如其来的重新提交测评的任务，会让人从心理上有一定波动，不引起公愤才怪，所以以后教育工作者应该更合理地站在学生的角度考虑，至少从心理方面多做一些体贴的思考。