AR的全称为助教机器人，是解决老师们上课期间学习内容的颗粒化。以及自动推送我们制定出来的课程内容。老师推送课程学生参与课程，在活动执行的过程中老师可以看见学生们参与活动的情况，以及回答的正确率参与度的情况。 由于划分的学习内容颗粒非常的小，所以同学们学习起来也非常的容易实现，过程中会有一些点赞和互相评论的环节也不会感到无聊。AR系统的核心是：让用户的学习看得见、抓得住、帮得上。
通过参加了AR的代码和UML图的验收，收获也非常的多。通过别人来反身自己，看看自己在开发的过程中会不会有同样的问题，进而进行规避。接下来通过四个方面来继续分析，包括可以优化的地方。
业务逻辑方面
业务逻辑方面从一开始的不熟悉到现在能够把业务的实现描述出来，对于每个模块的划分，以及 模块之间的关系都明确了很多。其中比较深刻的是上传资料模块。主要讲从学习通获取老师们上传的图片，还有一个是同学们回复的资源包括图片或者文件等等。一个叫网络链接上传一个叫文件上传。网络连接上传时首先获取到UML地址，把URL地址转换成文件流，最后把文件流转换成文件进行上传到文件服务器上去。文件上传是直接讲文件上传到文件服务器上，省去了网络链接上传里转换的一些步骤。还有就是目前在逻辑上存在一些问题的业务，比如说规则和激励配置模块。对于活动当参与度小于80%(都是可以配置的)的时候触发延时的策略。这都是成一个体系的。但是如果在配置的过程中，只配置了规则没有配置激励效果那么这个策略是不会生效的。这些方面还是需要进一步优化的。
代码规范方面
1.注释和代码要保持一致
2.定义变量的时候要放在类或者方法的上端，方面查找也减少了多次定义同一个变量的情况。
3.在Java只能怪变量的名称要采用小驼峰的形式。大家达成的一个共识。
面向对象方面
面向对象方面更对的是把相同的页面进行一个抽象和封装，比如爬取数据这个业务，如果两个模式甚至其他模块都需要爬取对应的数据，那我们就可以把爬取数据这个业务进行一个封装来提供给其他模块进行调用，还有就是在赋值的过程中如果值的路径比较深的话就可以把这个路径进行一个封装，这样既增加了代码的可读性还进行了封装。比如说string a= b.c.d.e和string b=b.c.d.f等类似的表达式，我们就可以把b.c.d进行一个封装。
性能优化方面
性能优化方面主要是减少一些IO的操作，尤其是在For循环中执行的IO操作。这样每循环一次都会执行IO操作就会对于我们服务器的资源进行强大的占用。还有一方面是对于我们不使用的业务要及时的注释掉，注释不仅仅是后端注释，前端也同样需要注释。比如说从前端获取数据传到后端插入的数据库中。如果我们只是对插入数据库对应语句进行了注释的话，那么前端获取数据的代码还是会执行的，但是执行之后并没有存到我们的数据库中。这样我们的就没有必要把前端获取数据的代码留下，留下不仅占用我们的资源而且对于我们的程序还没有起到任何的效果。
