个人理解的项目重点:
主要是处理答题竞赛活动的房间状态，用户身份，以及前端的请求。
5个主要过程,等待,开始答题发布题目和确认答案,请求复活,中途退出,以及最后显示奖励;
结合redis的队列,框架的组,可多并发多进程,(异步非堵塞这个概念不太清楚是不适用,待跟进);
框架处理了客户端的请求与响应,轮询判断用户是否在线即心跳检测;
我们只需要关注Events这个类里面的业务逻辑即可,大大提高了工作效率;
各个环节碰到的问题:
数据结构上:
redis的队列,哈希,集合;框架中的组;
数据库具体字段的处理,字段关联;
业务逻辑中要求的数据,一维/多维数组,字符串或json格式;
业务逻辑上:
1个用户,多个用户同时进场,退场,队列和组的处理,这个感觉还没处理好;
redis和mysql数据库的配合,暂时没处理好;
最后奖励与后续学习券系统的发放,使用还没结合到一起;
开发测试上:
项目的环境不好处理，linux虚拟机，公网的数据库，redis，代码库都出过问题，两人用一台电脑开发，后面我带自己配好的一台电脑去做测试以及代码的开发,并不是分工合作,各自把代码更新到一个代码库中，一个人的工作需等另一个人。
项目部署到测试环境中，共用redis会出现冲突,需要关掉线上服务才可本地测试;
面对复杂逻辑的程序时，前一个或者后一个模块影响了这个的数据
开发前,没有清晰要实现什么流程，哪些参数变化以及变化的过程是否与预期一致。
手动改变一些状态触发事件比较麻烦，测试脚本待跟进,控制流程和参数变化:
主要控制redis的数据(增删改),数据库的数据(增删改),服务开启关闭,引发程序变化;
代码协同上:
后台在和前端对接数据结构和整个流程上花了不少时间,很大一部分时间在排查错误。
另一小伙伴的代码习惯，面向过程方式，没有考虑到复用和封装，代码逻辑只为了解决一个或是一次性问题，而不考虑多个，多次或客户端同时请求引发的问题。
个人措施与思考:
我倾向于MC(控制器逻辑与数据处理分离)的方式,寻求一种通用的解决方案;
明确要做的事情,写注释让代码逻辑更清晰和方便维护;
项目采取方式:一是封装方法,另一是多个switch,case嵌套结构(参考之前)而不是if,else,较明显的是针对房间状态和用户身份做对应的处理.清晰明了;
采取比较明确的标识输出,查看前端过来的值,及我们后台代码执行到的模块;
switch($param){//可支持多层嵌套,return标识不继续判断下一个case
case1://注意:case'1':与case1有很大区别;
switch($param){
case11:
return;
case12:
return;
}
return;
case2:
return;
};
阶段性收获:
先把大致流程走通,再细化每一个小模块里面的;
如何准确高效严密处理好一件事? 编程过程中处理的三个点，一个是数据结构，一个是状态，另一个是什么时候转换数据结构与状态（这个可以理解为算法？）
算法理解：针对处理的效率、可信度。
然后发现自己不熟悉的东西很多，基础的数据类型，数据结构，循环遍历，函数的使用，redis的增删查改还不大会。
