团体项目—音悦app-个人总结—第十一组
一、项目代码文档整合
二、项目总结
主要功能完成进度
- 收藏歌单，歌曲功能 ☑️
- 播放歌曲 ☑️
- 浏览歌单广场 ☑️
- 浏览专辑 ☑️
- 搜索歌曲功能 ☑️
- 查看个人 创建的歌单和收藏的歌曲功能 ☑️
- 创建歌单 ☑️
- 评论歌曲 ☑️
- 发表社区动态（可带图片） ☑️
- 点赞社区动态 ☑️
- 关注用户 ☑️
- 查看自己关注的人和粉丝 ☑️
三、个人工作
本人在本项工作中主要负责的是建立基于SpringBoot+Flutter的前后端的框架架构、编写大部分API文档保证前后端数据接口一致，前后端数据接口对接并对其进行测试，大部分前端部分的数据绑定，一部分前端bug的修复。
由于前端部分的叶家鑫同学没有进行github版本控制上传，每一个里程进度由我上传，有一部分属于他的贡献
3.1建立SpringBoot+Flutter前后端框架
3.1.1 SpringBoot部分
在选用这个框架之前，其实我也没怎么学习过这个框架，之前接触过SpringMVC，在接触了这个SpringBoot之后感觉这个比之前的MVC更加轻量化，更加简洁。主要分为了三层Controller层，Service层，Dao层，最底层融入了Mybatis数据库映射工具以用于定制化SQL查询语句。在这一模块并没有花太多时间，因为Mybatis自带代码生成工具，可以一键生成最基本的增删改查语句（实际证明大部分语句需要认为添加）
3.1.2 Flutter部分
由于本小组选用app作为自己的前端，为了兼容ios端和安卓端应用，对两个平台进行跨平台开发，我们选择了使用Flutter作为自己的前端编写框架，由于之前没有学习过，对于他的数据绑定，画面渲染，刷新机制，花了我和前端设计师大量时间，由于对框架的不熟悉，常常面对一个bug，调试大半天的也有。简单的数据绑定，一步一步debug问题总会被找到的，但是对于页面刷新。那真是太痛苦了，没有办法debug，只能百度阅读大量的文章，来寻找问题的所在。虽然最后解决了大部分问题，但还是有一些美中不足的。比如评论之后无法及时刷新。
3.2 建立API文档
在前后端分离的架构中，前后端如何进行通讯是一个大问题，因为后端不知道前端数据绑定长什么样。不知道前端需要什么样的json格式，前端同样也不知道后端会发送什么样的格式给后端，于是为了前后端并行工作，API文档是必不可少的，作为前后端对接和前端部分数据绑定的代码编写者编写API文档是必须的，这样可以大大减少后端和前端对接时出现bug情况。3.3 前后端接口对接
看起来这活很轻松，前端把界面写好了交付给你了，后端也把API写好给你了，以为只要测试前端能否成功获取到前端信息就好了，那就太天真了由于我们组人少，会前端的只有两个人，常常是前端只写完了UI和少量数据绑定接口，需要重写数据接口进行尝试。并且其实后端的接口虽然经过一轮测试，但也会出现一些bug，比如后端一些无关紧要的空指针，在前端就会变成导致一个页面崩溃的错误，由于一些逻辑错误导致的一些bug等，因此在测试时先要分清楚前端bug还是后端bug，然后对症下药进行解决。3.4 其他工作
除了以上一些部分工作，还参与了一些前端bug修复，前端部分数据绑定工作，需求文档和设计文档的部分填写。
四、个人工作总结
在本次团队项目中，我主要负责的工作就好像是全栈工程师，不需要仔细了解前后端的代码是如何实现的（在本次作业中是不可能的）但是要了解整个框架的全局，实时了解前后端模块的工作进度，并且根据前后端提出的问题做出一一调整，保证项目进度能够及时推进。所以建立一个showdoc文档来了解前后端进度变得尤为重要。但是比起文档，更重要的是每个小组成员的互相沟通，每个小组成员必须及时提出问题，反馈bug和设计失误的地方，以便整个项目不会因为一块设计失误和bug做出一些无用功。所以出了一些无法解决的问题必须及时沟通，来及时解决问题，而不是让问题继续留存下去。
在本次团队作业中，事实也证明了在实际开发中，使用一个自己并不怎么熟悉的框架会导致起初进度变得很慢，因为每一个框架拥有自己的学习成本，前期项目的代码质量会相对较差，但是在开发过程中会变得逐渐熟练，因此代码质量会逐渐变高。但是可能就是一开始写的代码会让你无法继续提高后期的代码质量，比如在这次flutter中，数据绑定的格式有部分是不能复用的，一个User写了好几遍，就是因为这个小小的问题，导致在后期编程中要写入多个前缀来避免这个类名相同的问题，对编程起了一定的障碍，但是这时已经到了项目快要验收的后期，没有时间整改这些问题了，只能在原有的代码基础上进行修修补补，于是这也加重了后期debug难度。所以在一个软件工程的团队中设立一个代码审核的机制是相当重要的，只是在整个课程中没有办法去实现这个机制。熟练使用一个框架或者一种语言也是相当重要的，至少在编写过程中尽量避免这些问题。
对于这个团队项目本身，自我感觉收益还是蛮大的，在此之后个人觉得可以在每次写一个项目或者稍微大点的程序之前先列下一个提纲，把软件的大致框架结构和功能写下来，以此在写的时候不会有迷茫感并且更加熟练。
五、课程建议
个人觉得即使是分工明确，其实需要完成整个项目的所有进度那也会是非常累的一件事情（也许是对于前端框架的不熟悉导致的），最好在整个课程中添加一些连贯性，把文档编写任务时间压缩，比如在个人作业阶段，就讲授一些uml图、类图、时序图等图形和需求文档编写方法，以至在团队项目中，同学们可以更好更快的设计一个软件。或者是在个人作业时添加一些在后期团队工作中需要的组件。
通过整个项目完成下来，我发现最重要的是沟通，沟通，沟通。在软件开发过程中每个人不是一个孤岛，你的任务出现了问题，大体上就是这么几方面出现了问题：这个bug你自己难以修复，在定任务时任务设计出现问题，数据库等其他模块出现问题。那这时候不能让这个问题烂掉，而是及时寻找其他人寻求帮助。这样可以大大提高每个人的工作效率。我们比较特殊，有三个人在一个实验室，这样也大大加速了项目开发进度。我觉着如果没有这个条件。可以在两次会议的基础上，加上一份问题文档，把每次在开发古城中遇到的问题，通过这个文档进行反馈，当然可以创建一个微信群组或者是qq群组，遇到问题就把他发到群里去，如果真的解决不了，再将其放到会议上讨论大家一起解决问题。
在进度问题上，就算如此，其实我们也遇到了一个问题——deadline是第一生产力，我觉着这个问题是很多小组都会有的，我认为一次原型检查是远远不够的。可以在课堂上多放原型进度检查，这样可以最大程度上保证进度不出现压存的问题