一、仓库地址
https://git.coding.net/wowomilkycandy/OPERATION.git
二、PSP
刚开始我是准备把psp的二、十二分着写的，但是看过了夏江华同学的psp，我觉得合在一起写对比的更加明显。
|
PSP |
任务内容 |
计划时间（min） |
完成时间（min） |
|
Planning |
计划 |
40 |
60 |
|
Estimate |
估计这个任务需要多少时间，并规划大致工作步骤 |
40 |
60 |
|
Development |
开发 |
55.5*60 |
68.6*60 |
|
Analysis |
需求分析 |
50 |
45 |
|
Design Spec |
生成文档 |
0 |
0 |
|
Design Review |
设计复审 |
2*60 |
4*60 |
|
Coding Standard |
代码规范 |
15 |
15 |
|
Design |
具体设计 |
16*60 |
10*60 |
|
Coding |
具体编码 |
12*3*60 |
12*4*60 |
|
Code Review |
代码复审 |
5*60 |
5*60 |
|
Test |
测试 |
25 |
40 |
|
Reporting |
报告 |
9*60 |
|
|
Test Report |
测试报告 |
20 |
10 |
|
Size Measurement |
计算工作量 |
40 |
60 |
|
Postmortem& ProcessImprovement Plan |
事后总结, 并提出过程改进计划 |
2*60 |
5*60 |
三、接口设计
Information Hiding（信息隐藏）：指在设计和确定模块时，使得一个模块内包含的特定信息（过程或数据），对于不需要这些信息的其他模块来说，是不可访问的。信息隐藏在设计的所有层次上都有很大作用：从用具名常量代替字面常量，到创建数据类型，再到类的设计、子程序的设计以及子系统的设计等
a.为什么要隐藏？
1. 隐藏复杂度：这样你就不用再去应付它，除非你要特别关注的时候；
2.隐藏变化源：这样当变化发生时，其影响就能被限制在局部范围内。复杂度的根源包括复杂的数据类型、文件结构、布尔判断以及晦涩的算法等等。
b,未使用信息隐藏的案例：
描述：在系统内部到处都有与人机交互相关的内容，如果突然某一天要改变交互方式——如从图形用户界面变为命令行界面——那么所有与之相关的代码都需要改动
建议：可以将与人机交互逻辑集中到一个单独的类、包或者子系统中，这样，改动就不会给系统带来全局性的影响了
Interface Design（接口设计）：面向对象设计最大的原则就是针对接口设计。可见接口的重要性，如果接口能够定义好，不仅便于自身维护，而且也导致上层应用不需要太多变动，下面是接口设计的原则，只有按照原则才可能设计出高性能的接口。
接口设计原则：
原则一：必须符合Restful，统一返回格式，约定业务层错误编码，每个编码可以携带可选的错误信息。
原则二： 命名必须规范、优雅。
原则三：单一性
原则四：可扩展
原则五：必须有文档。良好的接口设计，离不开清晰的接口文档表述，文档表述一定要足够详细。
原则六：产品心。
原则七：第三方服务接口数据能缓存就缓存。
原则八：第三方服务需要做降级。
原则九：建议消除单点。
原则十：接口粒度要小。
原则十一：客户端能处理的逻辑就不要给服务端处理，减少服务端压力。
原则十二：资源预加载。
原则十三：不要过度设计。
原则十四：缓存尽量不要穿透。
原则十五：接口能缓存就缓存。
原则十六：思辨大于执行
高性能：如果我们发现这个接口tps和响应时间没有达到我们的要求怎么办。
-
A：数据存储方面：我们会想数据库有没有分库、分表、有没有做主从，有没有读写分离、字段是否有加索引、是否存在慢 sql，数据库引擎是否选用合适、是不是用了事务；
其次我们会想到是不是引用了分布式缓存、缓存 key 大小是否合适，失效时间是否设置合理，会不会大量缓存穿透、有没有引入本地缓存。
-
B：业务方面：是否有大量的计算、能否异步处理。是否需要引入线程池或者 MQ 来异步处理任务。有没有必要将接口进行垂直拆分和水平拆分、将接口粒度变小。
-
C：其他方面：nginx 层面做缓存、加机器、用 ssd，资源放 cdn，多机房部署、资源文件预加载。
高可用：如何保证服务高可用，需要从几个维度来实现：
-
A：消除单点，基于高可用第二位。
-
B：能做集群的全部做集群。譬如 Redis 集群、mysql集群、MongoDB副本集。
-
C：能做读写分离的都做读写分离。
-
D：异地多机房部署，接入 GSLB
-
E：必须有限流、降级机制。
-
F：监控。高可用的保证，基于第一位。
Loose Coupling（耦合性）：耦合性也叫块间联系，指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块之间越独立则越差，模块间耦合的高低取决于模块间接口的复杂性，调用的方式以及传递的信息。所以低耦合性和接口设计密不可分。其实所谓的低耦合就是将代码模块化，形象的说，就是要将代码写的和电脑一样，主类就是电脑的主机箱，当程序需要实现什么功能的时候只需要加其他的类引入接口，就像电脑上的usb接口。
在我们的结对项目中，对计算模块的函数进行了封装，将数据从前台页面提交到contoller层，数据从controler层传送到jsp页面中，在这个JSP页面中调用计算函数，进行运算。这个过程，我们看不见具体的计算函数，只是看的见参数调用这个方法后产生的结果，实现了信息隐藏。出题模块和做题模块利用了接口设计，实现了低耦合。
四、接口实现
后端代码共5个类，出题的类，计算的类，测试的类，判断的类，文件生成的类。
五、效能分析
项目总体分析图，从内存，多线程，CPU等方面分析了计算模块的性能，截图如下
六、单元测试
测试产生计算式，中缀转后缀和计算：
七、异常处理
在整个Java的异常处理中，实际上也是按照面向对象的方式进行处理的，处理步骤：
1，一旦产生异常，则首先会产生一个异常类的实例化对象。
2，在try语句中对此异常对象进行捕捉。
3，产生的异常对象与catch语句中的各个异常类型进行匹配，如果匹配成功则执行catch语句中的代码。
捕获异常，获取生成文件的路径。
八、模块设计
用户在"生成题目 (文档)"上左键单击(在"生成题目 - Mozilla Firefox"中)
用户在"下载 (按钮)"上左键单击(在"生成题目 - Mozilla Firefox"中)
用户在"确定 (按钮)"上左键单击(在"正在打开 result.txt"中)
用户在"文本编辑器 (编辑)"上鼠标滚轮向下滚动(在"result-3.txt - 记事本"中)
用户在"返回 (按钮)"上左键单击(在"生成题目 - Mozilla Firefox"中)
用户在"上传 (按钮)"上左键单击(在"生成题目 - Mozilla Firefox"中)
用户在"浏览… (按钮)"上左键单击(在"上传题目 - Mozilla Firefox"中)
用户在"result.txt (列表项目)"上左键单击(在"文件上传"中)
用户在"上传 (按钮)"上左键单击(在"上传题目 - Mozilla Firefox"中)
用户在"题目上传成功，点击这里开始答题！ (编辑)"上左键单击(在"上传题目 - Mozilla Firefox"中)
用户在"答题 (文档)"上左键双击(在"答题 - Mozilla Firefox"中)
用户在"结束 (按钮)"上左键单击(在"答题 - Mozilla Firefox"中)
用户在"返回 (按钮)"上左键单击(在"答题 - Mozilla Firefox"中)
九、模块对接
其实我们的功能是有很多缺陷的，目前只能实现整体提交的题判断对错，不能对每一道题展示出对错，我们结对的两个人都不是工作室成员，以前也不怎么编程
是因为这门课程，从头开始学的，很多不懂的地方都是查博客，问大佬，敲了很多遍的。前后端交互的过程中，连el表达式都是现学的，前端写的东西，我后端没有
能实现这个功能，我的小伙伴是在前端做了计时器的，登录注册，记录使用软件的每个人的做题记录，但是对于我这个初学的人来说，挺不容易的，如果之后有时间
的话，我们还会一起商量改好这个代码的。
和身边的大佬们存在很大差距，人家学了两年的代码，积累了很多的代码经验，我用一个月的时间肯定是达不到那个水平的，但是我们也没有放弃这个作业，硬
着头皮赶完了项目。两个人互相鼓励，这个对接的过程让我收获的是一段友情，同学间的关心，队友间的照顾，挺好的。
十、结对同伴
一张合照：
李金昊 （红衣直男）优点：做事认真、为人正直、动手能力强
缺点：缺少积极性、性子比较直、
我 （傻的乐观 ）优点：目标明确、知道自己要干什么、做事认真
缺点：缺少毅力。
十一、结对编程思考
凡事都是有正负面的，结对编程也是有利有弊的，但我觉得更多是利。
结对编程的优点：
1.减轻独自编程的工作量
2.两个人互相讨论，提高了编程乐趣，互相提出意见一起改进，一起进步
3.因为这个项目不仅是自己的，还有同伴的付出，不能半途而废，所以平时对零散时间的利用率就比较高，抓紧一切时间写
结对编程的缺点：
1.结对难，一般都是前后端结对效果比较好，但是前后端会的程度也各不相同，所以真正分工的时候就比较难，会出现会的多的多做，会的少做就做得少。
2.沟通不到位会浪费时间，前台写好的东西，后台用不上，后台写好的功能在前台没法实现。
3.讨论的激烈容易引起矛盾
引用的博客：
https://blog.csdn.net/gongchuangsu/article/details/53895916
https://blog.csdn.net/xottmeqg/article/details/53349070
https://blog.csdn.net/struggleoldboy/article/details/51868660