title: GamePM项目总结
date: 2019-12-09 21:07:50
tags: cnbolgsWork
---
GamePM项目总结
自从开题选定GamePM这个项目以来，我们选定了小型社群赛事管理作为功能核心。经过近一个学期的努力，我认为我们的GamePM项目不完美结题了。
GitHub 设计存放和前后端对接
GitHub 前端代码
GitHub 后端代码
最终页面 pj.tenderkun.com
前期设计
在前期，我作为团队中唯一拥有编写类似软件经验的人担任组长设计了我们小组这个课题的技术栈。我选择后端使用spring boot使用spring cloud中的spring session鉴权，前端使用react+antd。同时使用分布式的后端在spring session的帮助下我们能不受限制的分工开发后端。选定这两端的技术的理由主要是这是目前前后端比较火热的选择，各种教程完善，就算是组员没有相关经验java和类似java的js能够让他们快速上手。
但是在分工部分我的决定开始有失误。我想当然的认为前端的工作比较繁琐但是非常简单，而我们赛事管理的各种赛事的算法需要我来着眼。但是我没有和我的组员组队编程的经验，我以前的开发时间安排并不适合我的组员，react作为新兴的前端框架功能强大，但是显然不如原生html+js或者古老的jquery更简单，所以我们的前端无法按照时间点完成开发。而对于后端，我虽然选定了分布式+spring session的解决方案，但是后端组员对于前后端分离开发缺乏经验，不理解为什么我们需要鉴权导致开发缓慢。在我开发完两个模块后，我们发现前端跨域的问题，虽然能够通过域名直接解析或者单独开发路由转发解决，但当时的开发进度已经严重延后，所以我们只能回归老式的大后端解决方案，由后端组员接手我已经开发的模块合并成一个大后端。
我的工作
关于云部署
我们预计使用spring session依赖redis来管理用户session，虽然后来我们不在选用分布式，但使用redis并不明显的影响速度，我们也可以在redis上实时检查session内容。
之后前端的页面部署在我的apache2服务器上。
关于后端
在开发的最开始我编写了关于比赛和主办方创建查询的相关机制和一个spring session使用demo，但都比较简陋没有和前端连接尝试，之后我转去前端，这部分由王逸康接手并入他的后端代码。
关于前端
在观察到前端进度无法跟进后我转去前端，接手时前端进度为一个index，登陆和注册页面，一个赛事简介框架。
其余前端部分均由本人编写。
前端的一些截图：前端原型
前端.信息后台
信息后台主要分成个人信息、团队信息和主办方信息。
个人信息的账号的密码由注册时填写，昵称邮箱和手机注册后在修改用户信息菜单填写。
主办方信息是注册后可以成为主办方，并且能够查看自己的主办方信息。
这两部分的信息都包括了对应的id，因为我们设计时考虑也会出现重名现象，需要id来保证唯一性。
这里主要工作在于设计页面和表单并且发送请求给后端，功能简单并且最先与后端交互，所以我最早开始编写，这也是我们上一次原型展示的主要工作。
这里的一些难点在于团队功能。因为我们设计系统时想要实现团队赛的赛事管理，所以在参赛前我们需要组成团队。
关于团队我们除了要实现创建删除和信息获取功能外，我们还要让团队内的成员能够向别的人发送组队请求，而接到请求的人也需要查看接收或者是拒绝。
这里的功能在上一次原型展示只完成了一半。
前端.赛事功能
赛事功能是我们的核心的功能，在具体的实现中这部分也是前端的主要难点。
一个难点是一个赛事的功能十分复杂，而我希望能够将这些功能放置在右侧隐藏抽屉中，所以要合理的安排空间。这里我使用目前react唯一官方指定的react-router来解决根据url转换不同控件的方法，但是这种方法理论上还是不够好，所以导致部署在服务器上的时候刷新时会返回404的问题，这是因为react中的url并不代表资源请求目录，所以在服务器需要做额外操作。
另外一个难点是我们要实现关于团队和个人的不同赛制需求，一方面页面就有微小的不同，而且请求的接口有所不同。
除此之外前端都是一些琐碎的工作，不具体阐述。
结题总结和感悟
不论怎么说，我们这个项目也需要结题了。目前看来我们实现的部分和预计的功能相比，所有信息管理都完成了，但是赛制模块我们只实现了一个个人单败淘汰赛和一个团队KOF赛制。对于这个进度，我感觉到不满意并且感到抱歉。因为我预估错误了我们组的工作能力，没有搜寻足够多的人手就选定了一个这么大的项目，并且因为住院缺席一周多。
同时我的技术栈选择也不是太好，当时选择的时候关注的主要就是当前主要热门的框架。
关于app实现，我们设计时有考虑app的功能，但是当时我想先实现前端react再用迁移到react native，但是迁移还是需要一定的工作量，而那时我们已经严重拖延，最终只交出网页前端十分抱歉。
关于会议：我们组虽然只有两次记录，但是实际开了非常多的会。每次都会安排工作，但是问题在于收到工作时都答应，但是临近ddl才开工，最后导致拖延，这部分工作只能又安排一部分到下一次ddl。
在这题课题中我和组员有了更多的交流和理解，这对于我以后真正从事软件开发过程有了很好的经验。虽然这次我在这个项目背了很多的锅，但是这些问题
在我以后的开发过程中就能避免了。以后我选择技术栈和选择与我合作的伙伴都将更加的谨慎，这让我对PM这个职位有了更多的理解。未来我可能会尝试增多团队成员，来提高我多人合作的能力，也能更合理的分配工作，而不是以己度人。
课程建议
关于软件工程，这是我大学以来学的最贴近不光是实际编码还是项目管理最近的一门课程。
在这个过程，编码的压力体现是越来越重的，因为前期的工作是需求分析，和各种类图设计，而接下来一周就是原型展示。因为这样的时间安排，我没有很好的理由说服我的组员提前进行工作。