音悦APP团体项目_第十一组_个人总结

目录

• 项目相关链接

• 参与工作

  • 需求分析阶段
  • 项目设计阶段
  • 实现阶段

• 项目总结

  • 技术栈
  • 需求阶段
  • 设计阶段
  • 实现阶段
  • 其他

• 对课程的意见和建议

  • 课程节奏和进度
  • 团队

项目相关链接

• 项目完整源码

• 需求分析

• 项目设计

• 项目原型

• 墨刀原型

• 其他相关文档(包括需求文档、错误代码、数据字典、API文档和会议记录等)

参与工作

实现阶段的前期,由另一个后端队友先进行api的coding,我完成了大多数的scrapy爬虫之后才开始coding后端，所以提交主要集中到较后期。

需求分析阶段

1. 参与需求分析讨论
2. 进行分析建模，主要完成功能需求部分(将需求细分为用户、音乐和社区三个模块)
3. 文档撰写

项目设计阶段

1. 绘制用户用例图
2. 绘制类图,并描述相关的数据字典
3. 对数据库进行修改
4. 文档撰写

实现阶段

1. Coding Scrapy爬虫,通过策略 歌手->专辑->音乐 爬取全站音乐, 累计共360W左右音乐 3w3个歌手以及其他相关数据, 数据存入Json文件,并根据需要存入数据库(由于App响应速度原因，部分数据只放入部分数据)，这部分数据原本是用于
2. 设计部分API, 并Coding后端代码（部分模块：主要是用户模块,以及音乐、社区部分内容）

项目总结

技术栈

1. 本系统的设计主要是基于MVC设计模式，M代表模型Model，V代表视图View，C代表控制器Controller。MVC设计模式将系统分为三层，层与层之间又通过一定的模式联系，使数据实体、业务逻辑与呈现视图分离，同时降低耦合性、提高重用性和可维护性。
2. 本项目采用户SpringBoot(后端)+Flutter(前端)框架，View层交予Flutter解决，SpringBoot解决Controller层与Model层，MyBatis引擎解决SpringBoot与Database数据交互,另外基础数据使用Scrapy获取网易云音乐官方数据并进行。

关于需求

• 在需求方面, 由于本项目从一开始就借鉴了网易云音乐的App端设计，在大方向上不会有太大问题，但是在实际coding阶段发现，需求对实现的指导作用还是非常明显的。在项目的需求分析阶段，团队所有人都应该积极参与其中，只有将需求细化。

关于设计

• 在设计方面, 由于本项目在设计过程中参考了网易云音乐抓取的实际数据，但是在某些细节方面考虑并不是非常周全，比如由于抓取到的图片都是以URL存储的形式，所以在设计数据库时存储的图片格式都是默认存储url，但是在测试中发现，由于服务器端无法根据前端客户机的路径信息找到图片，将图片上传并转化为url,所以在后来的调整中，对于图片的处理由前端返回Base64编码。造成部分数据库格式不太一致(由于时间限制无法多进行调整)。另外API文档应该在设计接口时尽可能地全和完善，在coding阶段如果具备完善api文档，对于后端来说进度其实是可以非常快的。如果发现问题，及时与前端沟通即可。

关于实现

• 对于个人而言，由于自己的定位一直都是后端或者机器学习算法方向，所以一直都没有接触过前端(以后可能也不会考虑)。在本项目中实现Scrapy爬取数据，也尝试过scrapy-redis的分布式爬虫，但发现只有特定情况才适用scrapy-redis的增量型爬虫。同时由于爬虫所使用的是第三方提供的API服务，该api的proxy服务并不是特别好用，所以在部署爬虫的同时配置了tor环境(由于某些原因这里不对此进行赘述)。另外此前,只对Flask(python的轻量级框架)浅尝即止，并未尝试过Spring的框架，在本次项目中也算是大大熟悉SpringBoot+MyBatis的架构。

关于版本控制

• 本项目的版本控制是git,但是在实际使用过程中,仍然出现了一些问题。比如，虽然是项目是前后端分离的形式，但实际在repo中存放的不区分前后端和数据处理，所以在版本控制的过程中曾经出现过一些问题。此外，关于git中具体需要保存哪些内容，不需要哪些内容，应该另外再学习一下，规范化的版本控制方法对项目的开展还是很有帮助的。

• Git 指南 -- 什么应该被纳入管理？

• A collection of .gitignore templates

对课程的意见和建议

课程安排

• 个人项目与团队项目之间的间隔时间比较长（半个月），建议能够缩短这中间的时间，让大家能够有更多的精力去雕琢软件细节。
• 在项目的几个阶段之间设置具体的里程碑或者是deadline，课程体验下来，在团体项目的前期会有一段比较“轻松”的时间，主要是需求和设计阶段，每周主要的讨论时间还是集中在课上，课后属于比较进度比较慢的情况。如果每周都有更加明确的安排，比如某一周需要完成需求分析，应该形成需求文档（包含哪些内容），需求分析过程中需要着重考虑的是什么……当然这可能也跟我们第一次尝试目前这种教学方式有一些关系，在有了项目实施案例之后对于以后的学生在整个学习过程和项目的实施工程会更加友好。
• 每个里程碑建议能够展示不同类型项目的优秀成果，能够对其他团队起很好的示范作用，同时也能起到对比自查的作用（比较落后的组认识到差距或许会更加抓紧）
• 建议区分博客和项目文档，对于学生而言，博客更像是展示本阶段我们的工作成果的报告，而项目文档才是实际上的项目过程中一直起指导作用的文件。比如我们团队就由于这方面的认知，在第一次的需求分析博客中添加了当时已经初步设计好的API文档。可以使用更加有效或专业的文档合作管理工具，比如通过github管理文档或者是showdoc。

团队

例会

• 对于团队而言，个人感觉本课程安排的2次例会次数可能不足以支撑事实上的项目推进，但由于我们团队的三个人常驻在同一个实验室里面，每次有问题都是直接沟通，对我们影响并不是特别大。例会建议每周进行，一方面是每周检查进度，防范项目风险，另一方面是及时发现例如设计和交互方面的问题，减少无效或者重复工作。