音悦app-个人总结
引言
github的链接: https://github.com/hideonbushhhhhhh/MusicAppSys
需求文档链接: https://www.showdoc.cc/hangzhouwh?page_id=3482265840936782
墨刀原型链接: https://free.modao.cc/app/9d6afab630db73f204b02ff29474043a4e8a76d4
音悦app原型: https://www.cnblogs.com/zucc31701087/p/11973760.html
音悦app项目设计: https://www.cnblogs.com/zucc31701087/p/11885443.html
音悦app需求分析: https://www.cnblogs.com/zucc31701087/p/11785844.html
一、个人分工
在这一次的项目中，我开始的任务是负责建立数据库与绘制ER图等数据库相关方面的工作，后来我的主要任务是后端的API编写，然后和写前端的哥们和负责交接的哥们解决出现的bug。遇到有问题的时候顺便改一下数据库，改一些小问题。
我们组由四个人组成。小组共提交了75次修改，其中我进行了总共28次提交，新增了8000多行的代码，相比与别人可能稍微少了一点，但是该实现的功能都给实现了。我感觉后端的工作，从0开始有点难，但是越写就会越得心应手，写到后来就感觉没有什么API是不能写出来的了，对后端api的熟练度大幅的提升。
二、个人项目总结
1. 回顾本次的项目过程，体验最深的就是项目的标准一定要早点确定下来，数据库也一定要统一，只有在最早的时候把所有的标准都确定下来，才能在之后的工作中省时省力的完成后续的开放工作。
2. 最早是我建的数据库，也是我画的ER图。但是因为我的考虑不周以及当时组内交流的不够深刻，数据库的问题一直到写爬虫的同学需要存储到数据库的时候才发现问题，并在那个时候大改了一次数据库，对之后的工作还是存在了一定的影响的。
3. 关于后端的编写，我本来是使用Springboot中自带的一个泛型Result类来进行参数的传递的，但是后来我经过测试发现这个传递的方法解析起来极其麻烦，不仅我接受这类数据进行处理很麻烦，前端的同学拿到我的返回数据后进行处理同样非常麻烦，所以在我们的项目前期，前端工作和后端工作的对接过程中出现了非常多的问题，项目进度也因此被拖延了不少。于是后来我和组内的其他同伴商量后，决定使用阿里巴巴FastJson中的JSONObject类来进行参数的传递，使得我后端的工作变得顺利了很多，所以有的时候遇到了问题就应该马上改，不然一直用那个Result类来写，我估计我还得踩很多的坑。
4. 后端编写过程中还有些比较扎心的事情就是：数据库有的时候会变;因为前端的需求的变动，我要改动一些后端的API。首先，数据库的变动会导致我的后端有很多东西要改，数据库映射文件(Mybatis)要改，一些函数要改，sql语句也有部分要改，很多时候都有点牵一发动全身的感觉，所以我觉得有些标准还是要早点定下来，有些基础的东西还是不能想改就改的。然后关于前端需求的变动，这个东西要分两种，有一部分是很简单的，只要多加一点sql语句啥的就能处理完；但是有一部分的改动真的是非常的麻烦，我记得有一个API我当时半个小时写完了，但是后来改动这个API花了两个小时。。。所以我觉得标准的统一真的还是很重要的，一定要先定好前端的标准，再来写后端的API，因为后期API写起来真的挺快的。
5. 总体来说本次项目我们是由组内的四个人共同完成的，大家的齐心协力，出现问题后一起讨论问题，解决问题，都是非常难得的经历。中间有发生过争吵，但是我们还是这么一步步走下来了，最终因为时间的原因没能把网页端的成品做出来，但是ios和安卓端的功能，我们都实现并调试好了，基本不存在大的bug了，所以感觉这一次软工的作业任务我们完成的还算是达到标准吧。
三、对课程的建议
1. 关于课程建议的话，说实话因为要赶项目，所以我课上基本上都是听了一半，然后剩下的一半时间用来写项目，所以我对于课上的内容可能了解的不深，因为我们小组里有一个人是专门负责写文档的，我们剩下的人基本都是只要配合完成文档，所以就比如说我对UML图就没啥了解，但是组内还是能把作业交上去，所以吧建议至少每节课搞个一道小题目来测试一下，题目么可以交给助教来出，doctorz上做题也方便，小测试一手还能算平时分(我真是个恶魔)。
2. 关于定期举行小组会议，我觉得真的没有必要，因为问题不会固定的出现在某一个时间，而是随着你项目进度的不断推进而逐步被发现的。就比如说我们组，已经建立好了一个微信群聊了，一旦有啥问题就会直接问，出了个什么问题，需要怎么操作，大家都会在群上交流，然后定下了解决的方向。因为小组分工的关系，我们组还有一名负责协调，统筹全局的人，所以问题处理的挺快的。定期的小组会议对于我们来说其实就是把原来的问题重新提一下，也没有什么新的内容，因为都在群上说了，而且因为我们组中的三位成员都是同一个实验室的，所以交流特别方便，谁出了问题直接喊他就可以了，所以定期的小组会议对于我们的来说就是负担而感觉没啥用。因为项目最终肯定是要完成的，所以我觉得中期检查和后期检查就够了，而且文档也上交了不少，所以我觉得稍微好一点的组都会在出现问题的时候直接解决掉而不是等到小组会议上才讨论出一个结果。
3. 针对上一个问题，我觉得可以每节课(不一定每节课，可以单双周)找一个组上去准备好ppt，组里出个人讲一下小组的进度，说一下未来的展望与方向，演示一下他们的成果，好的话可以加分，不好的么可以早点发现小组的问题，如果班里小组太多么可以报名啥的，太少么就中后期在举行。