结对编程项目总结(王开207, 唐彬170)

一、说明结对编程的优点和缺点


说实话这次我们对于结对编程的体验并不是太好,由于我们在国庆假期基本上都是分开的,然后我们的代码并不是完全按照结对编程的要求来实现的,我们两个人只是在项目的设计,功能设计,代码设计,思路等部分一起讨论了,然后一起规定了类的接口,商量了注意事项和细节功能等,具体的代码实现实际上是分开的,调试的时候我们有合作,但是代码实现的时候并没有做到两个人同时码。这里上的图是我们在讨论设计的时候的图片,代码实现的时候我们是分开的。

在这里可以展示部分我们一起的设计:

 

不过虽然只是部分,对于结对编程的优缺点我也是有一定理解的。

先说优点:

1、两个人一起思考,在代码设计的时候考虑周到,减去很多思考时间。

在设计代码和功能的时候,一个人提出来一个想法,另一个人可以很快地补充,然后在一个人卡壳的时候,另一个人可以很快的提醒。比如在实现某个功能的时候,我会想到一个实现方法,然后对方可以很快提出来这个实现方法可能的问题。然后在一时间没想好怎么样才可以处理得更简便快捷的时候,另一个人可以提出来一个比较合适的方法。两个人一起就会大大加快思考的速度。

2、代码审核的时候,两个人一起可以加快错误处理的时间

经常调试一个bug的时候,两个人一起看的时候,就很容易知道问题发生在哪里,这样比一个人差错找来找去的效率高很多。

 

缺点:

1、两个人一起工作,难免会存在有不同想法的时候。

我们这次的项目就是这样,两个人在实现方法上有一定的想法不同。刚开始我们统一按照我的伙伴的想法来实现,他的想法是使用c++编写dll,然后交给visul basic .net来编写界面调用。这个就出现了很大的问题,因为如果是交给.net框架下的语言调用,我们就需要使用C++/CLI 来实现,可是这个与c++还是有很大不同的,尤其是变量引用等方面有很大的区别,在写的时候造成了很大的问题。我当时一度有点想临时改回用MFc来写界面算了,但是同伴还是想继续用vb.net来写。因为那个界面他已经写了不少了,所以不想改。这样我们就在这个地方纠缠了很久,然后工程拖延了很久

2、两个人一起,经常时间很难统一

我们这次就是这样,我们两个人在码代码的时候就没有能够在一起的时间。我们都是很晚才集合然后把各自代码汇合的。然后才能开始调试。这就很麻烦

3、这个问题应该不是结对编程的问题,是我们单独的问题

因为我们码代码的时候是分开的,所以调试的时候有很大的问题。一个人调试完,发现问题是另一个人的部分,然后就得等那个人调试完他的部分,然后再回来调试自己的部分。当然这是我们的问题,因为真正的结对编程不应该出现这样的情况。所以我们会吸取这次的教训。

 

二、结对的每一个人的优点和缺点在哪里


 王开:

优点:这个实在不好说...感觉自己说自己优点好别扭...优点是应该没有那么坑吧...

缺点:拖拉,效率低下

唐彬:

优点:逻辑性好,喜欢钻研缺点:也许事情比较多所以这个项目会稍微那个一点...

三、Information Hiding, interface design, loose coupling说明如何利用好这些原则


 

Information Hiding

信息隐藏是结构化设计与面向对象设计的基础。在结构化中函数的概念和面向对象的封装思想都来源于信息隐藏。即保证封装代码模块的”私有性“。该原则可主要用于以下3个方面:

1) 多层设计中的层与层之间加入接口层;
2) 所有类与类之间都通过接口类访问;
3 )类的所有数据成员都是private,所有访问都是通过访问函数实现的;

interface design

接口的设计是为了统一标准。按行为定义接口,要进行该类操作时只需调用接口即可,不须关心具体实现。

Loose Coupling

 松耦合降低了软件在结构上的相互依赖程度,通过以接口的方式实现软件模块间的调用使得部分模块在发生改变时软件的其他部分可以保持不变。

 

四、Design by Contract, Code Contract的优缺点,如何融入你的设计中


这个就是契约式编程。由前置条件,后置条件,不变式组成,它明确的规定了在调用某个操作前后应当属于何种状态,所谓契约就是在代码实现之前,将契约建立好,并且保证实现的代码一定是满足三个条件的。如果满足契约则认为程序满足正确性,若否则程序是不正确的。

优点:

1. 契约的存在,使得使用者必须要规范自己的调用行为,而开发者必须要处理契约中涉及的相关条件。即契约关系的双方是平等的,对整个bussiness的顺利进行负有共同责任。

2. 对于使用者而言,提高了代码的可复用性,在考虑是否可以使用某一函数时,只需考察其契约是否满足需求,而不需要考虑其内部的具体实现。

3. 对于开发者而言,提高了代码间的可替换性,对于不同的函数实现,只要保证其契约含义相同,则在调用时可以相互替换。

缺点:

契约关系经常是相互的,权利和义务之间往往是互相捆绑在一起的。因为是双方共同承担责任,若一方违规而没有及时告知对方,会造成巨大损失。

 

在本次结对项目中,我们一开始讨论的时候就定下来各种类,类的属性,名称,方法的参数,以及向外的接口等等。经过这样的定义,对内对外我们都可以保证直接使用,不需要考虑具体细节。(细节也在之前的规定中设计好了)

 

五、说明你的算法的关键以及独到之处


总共有四个类,一个core类,负责调用各种类实现最终功能;Equation类,这是算式类,负责生成算式;Fraction类,分数类;tools类,工具类,在这里主要提供随机数以及求最大公因数的动能。算式类和分数类都有输出函数,在计算的调用的参数都是字符串,包括保存分数等都是通过字符串操作来做的。

生成算式主要依靠的是Equation类的方法。在这里的方程式类,数字是以fraction类的形式生成的,运算符是以int值来存储的,括号也是通过int来进行操作,开了一个int数组作为括号位置,所以在这里我们有要求运算符个数不能超过10个。生成全靠随机数,按照范围来实现,通过范围可以规定概率等,在这里试图让整数和正数多一点,这样比较符合正常的四则运算。括号生成的正确靠的是两个参数,左括号个数和右括号个数。会要求左括号数一定会大于等于右括号数,即右括号不可能先于左括号出现,另外会保证如果已经很多左括号,会预留足够空间生成足够的右括号。负数也是通过随机数控制,分数等都是。查重主要通过一个数组,存的是答案,这里单纯按照答案相同就算重复来,所以肯定会有很多的缺失,这是以后需要优化的地方。本来是希望生成hash表的方式来做的,可能就得放在进阶版本了。检查过程中是否有负数等是靠着计算方法实现的。

计算中缀转后缀。

检查没啥。

六、代码覆盖率


 

 

七、UML类图


 

 

 

posted on 2015-10-07 02:23  开开开开开  阅读(162)  评论(2编辑  收藏  举报

导航