笔记：记录工作中的愚蠢时刻

记录一下我这次的开发经历：
开发一套刷题的小程序，我主要负责做题的主流程，概括起来主要就是获取题目和提交答案，先说说我最开始设计思路吧（后来也按这个思路写了，越写越觉得给自己挖了个大坑，然后也没有时间重构了/(ㄒoㄒ)/~~），大致思路就是一道一道的去拿题目，提交答案也是一道道的提交。获取题目的时候把上一题下一题，题目详情，用户答题记录，还有进度条都一起返回了，一句话说就是把所有用到的数据都揉到一起返回了，获取题目的时候也发现进度条一直控制不好，还有一个比较傻X的就是学习记录是放在另一个系统（我也不知道为什么要放在另一个系统，当时说是以后要把不同系统的答题记录都放到一起，后来发现这个完全可以当作日志用，不用依赖这张表），由于我提交答案也是一道一道提交的，就要不断的向另一个系统写入记录，获取题目又不断的从这个学习记录里拿取用户答题情况，就导致接口在不断的在不同系统之间来回跳动，显然我这个设计思路是不对的，但是当时没想到啊，经验太少，系统设计方面太薄弱，有些东西不是都要后端返回的，这种错误思路就体现在了上线之后，刚上线时，因为用的人少，并没有发现什么问题，第二天用的人多了，就崩了(ㄒoㄒ)，然后大家就开始紧急抢救，同事们先帮忙把错误捕获一下，数据表给相关字段加索引，起码让流程能进行下去，然后我开始优化代码，但此时还是在这个设计的基础上做的优化，把该加的缓存全都加上，优化相关的慢查询语句，该做异步的做异步，优化完压测之后又重新发了一版，这个时候速度明显提升，卡顿也没了，但是又出现了新的问题，真是一波未平一波又起，每天都会有几十个用户用不了，然后就排查问题出在哪，发现在异步提交答案的时候，有提交失败的情况出现，因为异步任务用的celery,只有一个服务，当并发上来时，就会有任务执行失败的，后来加了执行失败重试，但是发现没有起作用，最后我就临时补偿了一下，起了个定时任务，每个小时检查一下，对异常的数据进行处理（后面还有优化版的，这里就暂时这样处理了），因为还有二期的功能要开发，优化版就由新加入两个同事负责了，来补我的锅😅😅😅；然后跟同事们也学到了一波，其实我刚开始的设计思路就是有问题的，把逻辑搞复杂了，应该把业务都剥离开，解耦，我之前的设计耦合度太高了，拿题就是单纯的拿题，并且拿题的时候，是可以把题目id列表全返给前端，这样学习进度，用户答题状态这些都可以由前端控制，提交答案同步在本系统记录数据，另一个系统的学习记录就当作日志异步执行写入，这样也避免了提交答案失败的情况出现，还没写完，待续。。。。。
还有我之前设计的表结构会导致后面产生很多无用的数据，当数据量上来时，查询速度也会变慢，以上这些个问题，帮忙补锅的同事后来都解决了，实际上相当于代码重构了，真心感谢我滴同事们~ 接下来就是二期的开发了，其实跟一期的类似，这次的设计就很简单明了了，开发过程也算顺利，经历过这次事情，感觉收获了不少，开始开发之前一定要前后台好好沟通，双方沟通好，这样会减少很多不必要的返工，也要设计好了，想好了怎么做，然后再开始写，心态要调整好，不要对自己太苛刻，给自己太大心理压力，总之，也算是一次宝贵的经验积累了，希望以后代码写的越来越好，设计思路也更加明了