经历一个月紧张的开发，安全教育项目终落下帷幕。在这谈一下项目历程以及项目开发中存在的问题。
此次项目开发一共经历了四个阶段，当然，准备的说是五个阶段。项目准备——前后端初版开发——前后端对接口——问题修改——部署上线测试。
项目准备：
准备阶段主要做了三件事情：需求分析，人员分配分工，ER图及数据库建库建表和原型图制作。
需求分析：
这个项目的服务对象是大学新生，主要目的是大学生入学前参与安全知识考试，学校管理员通过学生成绩来判断学生哪方面安全意识较薄弱，所以我们所有的功能都是围绕这个入学考试展开的。但是当时提出了这样一个问题，如果我们设计程序时，就只考虑入学考试这一种情况，如果以后想扩展功能时，比如发布其他考试，那么我们的系统就会受到限制。因此在我们设计时，我们进行了考试类型的保留，即使之后项目进行迭代或需求变化，能够进行简单的更改就适应其他类型的考试。
人员分工：
在人员分工上，这次主要遵从了大家的开发意愿，最大程度上保证每个人都能开发自己喜欢的模块。虽然项目不大，但五脏俱全。复杂的业务，EXCEL处理，数据爬虫，数据统计，以及微信小程序开发等。在分工时，我和学长进行了讨论，尽量把这些特色的功能均分给每一个人。最后团队形成了有专一做爬虫的，有专一搞文件处理的，还有专一搞小程序开发的。在保证项目能按时完成的情况下，尽可能让每个人都能接触到比较新颖的业务。
ER图和数据库建库建表和原型图制作：
上次画ER图，还是在去年的这个时候，是吧，很难想象一个搞后端开发的竟然将近一年没有画过ER图。这次的ER图的制作由三名后端人员参与，经过无数此的修修改改，三天后，ER图，数据库等这些内容都基本定稿。（说句实话，有点丑，但我原谅了自己）。
前后端初版开发：
这是项目开发的第一周，主要任务很简单。前端所有静态页面，后端所有接口。这一阶段遇到的很大一个问题就是前台原型图没有定稿。因为项目比较紧急，开学就得上线，所以我们是边画原型图，便开发。最终的结果是，本周的任务完成了90%左右。后端虽都提供了相关接口，但是大多数接口都测不通。拿我自己来说，初版接口的开发特别粗糙，虽然都能测的通，但是代码写的很邋遢，封装，规范等等都没有很好的遵守。核心业务没有考虑充分，出现了许多小的问题，导致的结果就是花费了第二周的两天时间来补第一周的漏洞。前端出现的问题在于好多页面的弹窗没有做，就一个整体的框架，任务并没有完美的完成。
前后端接口对接：
第二周的主要任务就是进行接口的测试，前端调接口，后端该问题。这周周一晚上我们项目同步时，发现大家都在改上周的问题，本周的进度很少开始。这样下去很可能导致本周的任务也没有完成。因为每周的任务在项目开始前我们做了十分详细的规划，如果继续下去会恶性循环，所以就进行了相关的调整，大家停下第一周的任务，着手第二周任务的开发。
但计划赶不上变化，因前台原型图的重新设计，好多第一周开发的页面要换掉，开发前台系统的同学面临很大的挑战，既要制作页面，又要和后端对接接口，考虑到有可能超时，所以我们就将每个人的任务做了更详细的划分。大家先做核心功能，非核心功能先停下。以保证本周结束后，我们的所有核心功能能跑的通。
这周结束时，核心功能的接口对接的差不多，但是总体任务完成的并不是太好。我们是全天候开发，是完全可以做的更好的。
问题修改
这周的任务可以说是最轻松的，也可以说是最复杂的。轻松在于项目已初步成形，所有的开发都是在原来的基础上修改，复杂在于优化。本周项目同步时，我们看的不再是功能是否实现（当然功能必须得实现），更看重页面的效果和用户的体验感。页面布局是否统一，页面的设计是否合理，是否设计了多余的内容，前台设计有没有严格遵循原型图等等。同步时，我们都在一个个的扣问题，每次花费的时间也都在3个小时左右。好的是，大家的问题并不是很多，这周的时间也很宽裕，有充足的时间来修改上周未完成的任务。
这周结束时，项目总体进度不错。大部分都完成了，不过bug依旧。
部署上线
因为本周五项目就要完成并且部署好，所以我们的时间很有限。周一晚上的细致联调后，给大家限制了一个时间，所有问题在周三之前改好。因之前我们还没有在微信小程序上部署过，不确定会出现哪些问题。还记得周三的那个晚上，项目组的成员在这里加班部署，一路跌跌荡荡，最终完成。完成的那一刻，每个人都如释重负，看到我们奋斗一个月的成果，每个人都很兴奋。
后续的两天我们不断完善和修复一些bug，目前我们的体验版和后台环境已经部署好，准备迎接第一批用户的测试。
自我总结及问题反思
在上个项目时，我们项目组人员变动比较大，前前后后换了有五六位开发人员，加上需求的变化，总体推动较慢。所以在这个项目中，总结了之前的教训和经验，项目初期就进行了细致的分工和规划。虽出现了一些小的变动，但总体没有受到很大的影响。
项目同步会：
1.会议前准备不够充分。出现部分同学未及时提交代码，会议到时间还在拉取代码，不能在约定的开会时间正常展示项目，浪费总体时间。
解决方案：约定会议时间时，提前约定代码提交时间。过完这个时间后不再拉取代码。提前准备好展示能容，约定开始时间时，保证项目能直接展示。
2.会议效率低，总体时间较长。主要原因：部分业务实现后，开发人员没有自己去测试，或者并没有考虑这样设计是否合理。
解决方案：在准备会议前，可以把大致的功能先看一下，将不合理的地方标注，最好能提前想好解决方案。会议上直接将此问题提出来，合理即采用。减少会议中的思考时间和讨论时间。当然，并不是绝对的。项目正式开发前，提醒大家开发中一定要把自己看待成用户，不合理的地方一定要及时提出来讨论，不能等会议时靠大家一块去发现这个问题。
3.会议过于频繁，没有把握好会议重点。项目整体同步会几乎是3天一次，经常出现上次问题没有修改完，新问题又暴漏的问题。
解决方案：初期项目同步时，我们都是看项目整体，没有针对之前的问题去看，造成会议拖得很久，新问题也不断暴漏。之后改成只针对问题进行联调，这样提高了开会效率。（项目总体完成后，可以先进行两次总体的联调。之后联调主要针对问题进行联调。同时，提前结束开发任务的同学可以先加入联调的任务中）另外参考下4
4.问题建立待办不及时，导致项目进度没有把控好。
解决方案：每次联调完后，进行小型总结会议。主要根据大家任务的完成度和问题程度，为大家的问题分优先级，预估问题修改完成的时间。（预估问题修改的完成时间非常重要，关乎你下次联调的效果）统计大家开发中遇到的问题，鼓励团队。另外督促大家及时建立待办，设置待办完成时间。
5.需求对接问题。实际开发中，某些设计不合理的地方没来的及和总负责人对接，按照自己的想法完成。
解决方案：小型的变化可以适当发挥，但比较大的就需要讨论了。不然很可能前功尽弃。
技术：
1.编码效率低，初版接口开发时粗糙，没有规划好。
解决方案：出现这个问题最主要的原因，就在与之前项目的总结不够。许多需要注意的地方在新的项目中并没有注意，导致开发效率低。做好项目总结工作和代码的复盘工作。
2.开发中遇到的问题没有当时总结，总想着放在项目结束后。
解决方案：这个问题很严重，每次开发完我都得花好长时间总结项目。之后开发项目时，做好项目开发记录。记录业务实现逻辑和开发中遇到的问题。当前功能开发完毕后，即可进行总结。
3.处理复杂业务花费时间较长，理清逻辑需要花费很长时间
解决方案：注重算法和数据结构学习，之前一直没有提上日程。从现在开始必须提上日程。
4.技术面比较窄，需要扩展
解决方案：同期的好多同学都学了部署这一块内容，但是我这方面知识缺失，需要尽快学习和完善。
5.技术深度不够 在编写代码时，使用Java提供的一些集合的工具类，面对大量数据，不知使用什么技术实现
解决方案：注重算法和数据接口学习，剖源码。
6.对框架的使用还行，但是对整体的流程并不是很清晰。
解决方案：深入框架本身学习。