重构

突然觉得这项工作还是要定期去做，之前由于赶时间完成功能，有些代码写的比较乱，且随着新的需求加入，这里加点，那儿删点，修修补补的导致可能隐藏bug问题和代码的"臃肿"。后面有人接手或者加个小需求，都不太敢乱改，必须要知道这些代码是什么意思，为什么这么写，改了后会不会引入其他问题和多余的测试工作。

由于项目上线后，总会出现偶现的bugs，基本上对于复杂的代码块，测试用例没有充分覆盖到的话，后期很可能暴bugs。本来是测试都没有问题的功能，后面如果加几行代码，可能要调整代码逻辑，抽象出接口等工作，而引入新问题，所以在做这些工作前，需要先评估下。

年后遇到过两次，一个情况是发现偶现的bug去尝试修复这个问题，然后和客户端同学约定协议，然后增加十多行代码。当时只考虑到三种情况，还有一种情况没有考虑到，所以线上出了严重问题。为了修复偶现的bug却引入新问题，有点得不偿失。关于这个问题，是因为客户端和服务端对于时间的检查不一样，可能在客户端那边认为超时了我可以免费复活，而在服务器检查到没有超时故做了扣费复活，这种逻辑本来就有问题，但是因为小概率出现。修复后的代码块出问题的情况是，我超时后不复活，但后面我再也没机会复活了，因为检查时间远远大于代码中的判断期限内。

当初这块设计的有点小问题，但因为历史代码块不太好改动，所以只能稍微修改下。同样的问题反应到第二个问题。

因为第一版功能测试的没问题，后来因为加了个小的需求作为引导任务，任务的内容是进副本，需要点一下任务就完成，我这边需要解锁该副本，然后就因为是两部分功能，一个是任务，一个是副本，而且完成任务就一次机会，导致在尝试进副本的时候，如果条件不通过则不能进副本，包括解锁副本，而此时任务已经完成了，后期再也无法进了。

因为这个问题在年后的其他版本中出现，是偶现的，由于进副本前的判断逻辑较多，任何一个判断都失败，导致无法解锁。当时想改任务那块，但怕因为小需求而影响了任务模块，有点耦合吧。后来这个问题修复后，在主干测试过，在分支测试过，合到另外版本后测试过，后面没有再合到另外版本的分支上去，导致出现了问题。

可能当时写的一个接口实现行数不多，但后面慢慢加需求变复杂，比如checkxxxxx的函数，只作检查功能。可后来又加了需求要setxxxx修改数据，仅一行，单独拿出来吧，前面的逻辑可能要再写一遍，不太好分开，这个只能修改checkxxxxx重新命名。自己写代码比较严谨，考虑到可读性和健壮性，包括扩展性，能写意图明确的接口，尽量分出来。也可能当时因为赶着项目上线，一个月完成两三个大需求，连着数月十一二点下班，确实没有多余时间做这些工作。

希望以后多注意些。