https://github.com/Lucius3451/Simple-Arithmetic.git
| PSP2.1 |
Personal Software Process Stages |
预估耗时（分钟） |
实际耗时（分钟） |
| Planning |
计划 |
60 |
60 |
| · Estimate |
· 估计这个任务需要多少时间 |
500 |
500 |
| Development |
开发 |
450 |
450 |
| · Analysis |
· 需求分析 (包括学习新技术) |
100 |
100 |
| · Design Spec |
· 生成设计文档 |
0 |
0 |
| · Design Review |
· 设计复审 (和同事审核设计文档) |
0 |
0 |
| · Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
0 |
0 |
| · Design |
· 具体设计 |
80 |
80 |
| · Coding |
· 具体编码 |
300 |
300 |
| · Code Review |
· 代码复审 |
30 |
30 |
| · Test |
· 测试（自我测试，修改代码，提交修改） |
100 |
100 |
| Reporting |
报告 |
10 |
6 |
| · Test Report |
· 测试报告 |
0 |
0 |
| · Size Measurement |
· 计算工作量 |
0 |
0 |
| · Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
0 |
0 |
| 合计 |
|
1600 |
1596 |
设计实现过程
这里就说下思路好了
理解了需求之后
核心就是制造算式和苏安出答案
一开始就有了所谓的传统正规做法的想发:
用栈装入随机的项数和运算符
计算答案时再利用栈变成逆波兰表达式
然后再用栈算出答案
这种做法的好处大概就是可以不被括号约束，另外就是生成的运算式没有上限
但我们想偷鸡:
先制造答案 再制造随机项数和随机运算符
这样还可以自己写个字符串修改函数随便插入括号
不过等写完运行发现由于是先生成答案 会导致项数总会超过需求中的项数限制值
并且容易出现负数。 虽然可以会精力去修正概率和表达式，但这显然违背了初心
故决定放弃这种做法
(你可以在上面那个仓库上的old.cpp看到我的做法)
所以再次认真分析了需求，我们发现最多就4个项数的限制条件。我们将乘除当作A(优先级都为1)，同理加减当作B，那么总共就用14中情况而已
从这里入手 不用传统做法也可以
至于复杂的括号情况 也因此在此变得简单，但我们没有去实现，因为这不是很重要了。
具体的可以看源码
类什么的不说, 个人认为比较重要的是自定义了struct 结构来应对分数等麻烦的细节 将自定义的数据类型再升级 代码可以更易读和高效
但我不想再在这个上再多耗费时间 不过倒是也算得到了教训吧
效能分析
个人认为我们所采用的做法比传统做法肯定是要会花费少的，因为需求规定了运算规模就那么大，故自然是我们这种”一次性代码”的针对性更强 和 效率更高。
不过需要承认的是我们的做法是不可拓展的(随着运算符数目的增加，分类情况会指数式的增加)
测试运行
程序正确我们不能保证, 虽然每段代码都看了两次以上，以及从有限次的运行来看已经修正完毕。因为这次项目是赶工出来的，自然无法对复杂的程序块进行全面剖析。
虽然封装的次数还没有最大化， 但也足够保证一定的正确性了。
其他图就不贴了(你可以从源码看见)
项目小结
首先是没有对时间进行合理的规划，另外从需求分析来全局出发真的很重要，
以及记录下曾经的想法也是必要的。做得不好的地方 还有代码的可维护性和注释基本没怎么写。虽然项目是勉强合格(在我看来)，但我不会忘记这个项目给我的警示。
细致和勤快 是不能丢下的东西。