这两个半月时间主要是接手离职同学的工作，大概是英雄和人物的技能及战斗，buff/ai相关，完成了一些跟技能相关的需求和bug修复，虽然代码挺多的，但各模块间还是比较清晰，实现比较容易扩展，如果出现bug或者修改代码，应该不是特别难，之前也翻过一遍和优化过这块。

也开发了一个约两千多行的帮派战，因为这个玩法一般在游戏中都会有，也考虑到承载人数上限和优化的方法。其他的就是各种大大小小的需求会以及一些问题的解答，不过总的来说，不是特别忙，也学习了一些其他的基础知识，为后续的计划作些安排。

然后因为之前优化过低层框架，虽然性能提升15%-22%，但是不支持改系统时间，因为一改导致存在短时间cpu高负载，具体原因不再细说。所以这里有个问题，因为线上基本是不会改时间的，只是在开发阶段会这样，那是否为了性能而对舍弃方便测试呢？

其中修复两个跟战斗状态相关的bug，都是跟fighting字段有关，因为配置中的类型是string，而实际使用时是boolean，所以在进战时会设置true，客户端使用是if not fight_state then这样的语句，所以在为true时是不管取出的true是boolean或string，所以逻辑没问题，但当为false时，因服务器设置为false，导致类型不对，同步此状态到客户端时因为协议，没把这个包发下来，进而导致客户端的角色状态不对。还有一个跟在主动退出副本时切场景，需要脱战fighting=false，但因为同步此状态时机不对，导致发包的时候，发不到客户端，所以这个状态一直是战斗中，导致其他问题。

在开发中，因为qa测试过的功能是正常的，但不知道在什么时候坏了，qa那边反馈给我，我这边查了好几个bug，都是跟不知道是哪位同学修改客户端代码有关，然后可能没测试充分就提交。所以有时候在想，改一处代码，一定要熟悉它，且知道哪些地方调用它。把接口改了，一定要修改使用到它的地方，参数明了。如果改实现，要充分测试，并通知相关使用到它的其他同学，所以这里有个责任归谁。有时改代码出于什么目的，是重构或优化或功能不对，先保证功能正确性，再考虑优化或者重构，如果是自己写的比较熟悉，如果其他同学写的，要通知到相关同学并熟悉下这里的实现和一些注意点，并进行code reivew和回归测试。

还有一个可以总结下，就是在战斗释放技能时的处理，之前的项目是在离目标过远时，比如某个技能需求是当释放范围太大，导致不能释放，这里在客户端判断并拦截，寻路过去且会跟着目标，当到达目标时，会再判断一次其技能流程，此时再请求释放，之后服务器处理。这里会简单一些，比如切换目标或者打断。但在新项目时，这块有较大的变化。中间的一些原因跳过，此时在客户端的某个技能判断有目标且过远时，是需要寻路过去，要告诉服务器请求到某个目标周围，到达周围时再告知客户端再走那个技能流程，那么这里要考虑很多且我在实现过程中发现的问题。比如，先释放技能普功1，此时请求到服务器寻路，客户端立即再次普功2(因为不是主动技或者大招有cd，而普功是可以连续释放)，那么客户端是否要放行这个2到服务器？或者快速切换目标，此时要中断之前的寻路或进行新目标的寻路？或者角色有其他状态和操作，请求寻路时的处理是否要考虑到或中断？这里两边可能要维护状态导致复杂度增加和引入其他bug。这块还是要再考虑下怎么处理。

总的来说，接手技能工作这块，需要思考之前的实现为何这么写，以及因修复bug而引起实现的改动，是否会引入新的问题，要综合权衡。后续的工作主要还是在人物技能和英雄技能两套，以及战斗和AI相关。