结队编程作业
结对成员信息:
201521123063 林羽晴
201521123065 洪亚文
码云项目地址:https://gitee.com/jmulyq/CreateFormula.git
1.改进现有的代码
我们选择的是第四个项目
他/她的博客:http://www.cnblogs.com/shizhuangde
git地址:https://coding.net/u/shizhuangde/p/Myapp/git?public=true
原题目要求:
- http://www.cnblogs.com/happyzm/p/6472120.html
- http://www.cnblogs.com/happyzm/p/6509116.html
- http://www.cnblogs.com/happyzm/p/6558307.html
(1)源码分析及修改内容
- fra_formula
这个类里面主要是一个output的方法,还有输出格式,我认为只需要将随机生成的式子用字符串的形式打印出来即可,那样一个一个判断条件,有点太繁琐了 - Fraction
parseFraction()方法中只考虑了用户输入结果为分数或者整数的情况,在此处添加了小数转为分数的功能,还有遇到负数的情况
而且在判断结果是否正确的equals()方法中只通过比较分子和分母是否一样,还不够严谨,如果输入的是假分数,那么也应该可以判定为正确的,所以在这个地方只要保证这两个分数转为小数的结果(保留三位小数)相等就可以了 - int_formula
这个类是通过setFormula()方法来随机产生
出现的问题:随机产生的格式比较固定,对两个分数,或一个分数一个整数,或两个整数进行加减乘除,不够灵活 - main函数,每次循环产生新的题目,题目数量没有更新,导致产生的数目有误
整体分析:
代码随机产生两个分数,分数的分母为1即为整数,最后,再随机加减乘除,对这两个分数再进行对应的加减乘除,没有任何优先级之分,所以感觉这个代码可以推翻90%重构
(2)生成的类图
修改之后的
(3)单元测试并测试覆盖率
单元测试代码:(部分)
- 未修改之前单元测试:
未修改之前的覆盖率:
- 修改之后的单元测试:
修改之后的覆盖率:
通不过的原因果然是因为有小数,以及负数的情况没有考虑充分!
(4)出现的bug以及修改方法
- 添加负数和小数的判断和转化
- 对结果增加了通分,如果是负数的话,则统一把分子看做负数,分母看做正数
-将结果全部转为带小数的值(只保留三位)如果出现无限不循环小数,方便和答案统一 增加了init_num的重新赋值
(5)修改之后重新测试
2.功能的改进与扩展
(1)增加乘方的功能
主要根据优先级来计算,具体的详见代码
(2)随机产括号和乘方
只随机产生一对或者不加括号,考虑到了冗余的情况,去掉类似(1+2)这种的括号
(3)查重的功能
这个要用到树的最小表示法,首先要将表达式用二叉树存储,要比较两个表达式是否一样,就是要得出它们的最小表示法,当符号为+或者为*的时候,才比较左右子树,保证左子树的hash值要大于右子树,最后会发现,如果是同一个表达式,它们的最小表示式是一样的,但是这个功能由于时间的关系,没能及时完成,待后续补充
添加功能之后的类图
重新单元测试:
覆盖率:
回归测试:
能保证原来的计算功能!
效能分析:
花费在时间上比较多的是计算的方法,还有事随机式子的产生,在判断有级的时候,暴力给定有限级的效率会比较低一点,觉得可以给符号标记数字,用枚举变量的方式可能会简单一点
逻辑泥球:
在输出的格式上编写太复杂了,其实可以直接用一个字符串数组,或者用list来存放这些数和操作符,最后直接遍历输出就可以了
提交的记录:
结对编程照片:
编码规范:
1.类名的首字母大写
Main:main入口函数及执行
Function:含有所有的功能方法
Stack:自定义的栈
Fraction:分数类
2.内部的方法全部以驼峰式命名
ParseDouble:将字符串转为浮点型小数
CreateFormula:随机产生四则运算的式子
Calculator:用来计算结果
3.变量名全部小写
Main当中
number:用来计数
all:生成的题目总数
correct_num:回答正确的题目数
get_answer:用户输入的答案
right_answer:计算机计算的正确答案
option:值为0退出,1继续
在CreateFormula当中:
list:存放式子
number:随机产生数的个数(2-4)
bracket:括号的个数(0-1)
left:表示左括号在第left个数的前面
right:表示右括号在第right个数的后面
PSP表格:
PSP2.1 | 个人开发流程 | 预估耗费时间(分钟) | 实际耗费时间(分钟) |
---|---|---|---|
Planning | 计划 | 10 | 8 |
· Estimate | 明确需求和其他相关因素,估计每个阶段的时间成本 | 5 | 5 |
Development | 开发 | 110 | 135 |
· Analysis | 需求分析 | 5 | 3 |
· Design Spec | 生成设计文档 | 10 | 11 |
· Design Review | 设计复审 | 10 | 8 |
· Coding Standard | 代码规范 | 2 | 1 |
· Design | 具体设计 | 10 | 12 |
· Coding | 具体编码 | 120 | 180 |
· Code Review | 代码复审 | 20 | 18 |
· Test | 测试(自我测试,修改代码,提交修改) | 40 | 50 |
Reporting | 报告 | 15 | 20 |
. | 测试报告 | 10 | 10 |
. | 算工作量短文本 | 3 | 3 |
. | 并提出过程改进计划 | 2 | 3 |
结队编程小结:
本次编程作业,我和我的小伙伴合作完成,期间也有意见不合的时候,也有不知对方所云的时候,友谊的小船说翻就能翻的那种。
但是最后还是比较顺利地完成了任务,给我的感受是1+1=1.5的那种吧,还达不到1+1>2的效果,唯一有点遗憾的是查重部分没有及时完成,根据树的最小表示法原理,一开始查找网页的详解还是一头雾水,看了JLdalao的源代码,发现不是一个上午就能完成的,看来编程能力还要提高,毕竟距离上次敲代码已经有三四个月了吧!
来源:https://www.cnblogs.com/lyq063/p/8590403.html