https://github.com/z472/code_all/blob/master/test2.py
PSP2.1 |
Personal Software Process Stages |
预估耗时(小时) |
实际耗时(小时) |
Planning |
计划 |
0.5 |
1 |
· Estimate |
· 估计这个任务需要多少时间 |
48 |
72 |
Development |
开发 |
2 |
2 |
· Analysis |
· 需求分析 (包括学习新技术) |
1 |
1 |
· Design Spec |
· 生成设计文档 |
0 |
0 |
· Design Review |
· 设计复审 (和同事审核设计文档) |
1 |
3 |
· Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
1 |
1 |
· Design |
· 具体设计 |
10 |
10 |
· Coding |
· 具体编码 |
20 |
22 |
· Code Review |
· 代码复审 |
0.5 |
0.5 |
· Test |
· 测试(自我测试,修改代码,提交修改) |
4 |
4 |
Reporting |
报告 |
1 |
1 |
· Test Report |
· 测试报告 |
1 |
0 |
· Size Measurement |
· 计算工作量 |
0 |
0 |
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
1 |
1 |
合计 |
43(不算估计时间Estimate) |
46.5(不算估计时间Estimate) |
3.效能分析:没有对比的方法得到提高程序性能的情况,但是在编程的时候还是考虑尽量减少重复的部分。我们的思路是,先自动根据用户输入数据来生成未经约束的算术表达式,这些式子可能是不符合数学规律,除数为0,也可能是不符合要求。在最终的方法End_ari_exp()时候汇集那些有约束效果的方法,得到合适的算术表达式。
4.设计实现过程:总的方向上是每次做一两个功能,最初就是写函数,最后在用户输入时统一调用。把大的功能分的细小。还有把会复用的代码段单独列出形成方法。由于写好的函数会对后面函数的编写起到作用,所以要有分析先写哪个地方。并不是完全按照功能的
顺序来写。1.自由生成算术表达式 2.计算算术表达式 3.判断非负性和重复性 4.写输出到两个文件的功能 5.写用户的输入 这几个功能是主干内容,也是独特的,其他的内容可以通过组合和调用实现。
5.代码说明:1.自由生成算术表达式:先实现自动生成根据输入的数据生成数,然后调用随机数来随机产生运算符,拼接成一个普通的表达式。这里的括号是随机插入一对括号。(多对括号的代码以下写的话还要添加搜索括号位置的代码在别的函数内,原理其实是一样的),注意的地方是除数为0 2.计算算术表达式:如果有括号,先找到括号,计算并返回新的列表,计算的话要按运算优先级,都在Compute_non()中,注意的点就是数的类型不同,先得转化成一致的格式,比如转成分数(也可以是真分数);还要注意对原先列表的改变,注意索引的位置,还有0的情况 3.判断非负性:按照运算过程,要做减法的时候,返回值来区分出异常 ; 重复性:我们的思路是得到,运算过程的表达式字符串,然后存入集合中,之后新建的算术表达式从集合中寻找,若交集是空集就存入 4.打开文本文件,然后将之前合适的表达式字符串输入,答案同理输入另一个文件中。5.写的有点偷懒,这里的判断两个文件中算术表达式的文件名传入,没有处理,功能实现了,可以通过test_txt()验证得到。
6.测试运行:这是最后用户输入的内容
在当前目录生成文件。打开文件,
最后调用a.test_txt('Exercise.txt','Answer.txt'),也测试了text_txt()功能。在第一个图中
用户输入出错:
8.项目小结:错误总结,python的错误报告很细致,配合输出语句,很好找到错误的地方,但是有一个format_str()函数第一次写的时候没有错误,但是死循环无输出,找了好久,因为怀疑是别的函数的问题,因为它功能太少,不可能出错以为。结果就是它的
for循环的写法,可以换种写法解决。这个bug是解决的非常痛苦。就是低估了简单代码。 最初的结果是以假分数的形式,被对方提醒到。结对感受很好,减少了工作量。促进了沟通。