起因
看到项目恶心的代码就忍不住重构,我相信很多人都是有同样的想法.
只不过我这次比较莽,改完之后没有经过专业的测试去测,只是产品和研发自行测试就上线了,最终导致线上环境用户无法扫码登录等问题,持续了一个小时,差点就被祭天了(总监还坐我旁边叫我别紧张,慢慢来,特喵的你坐我旁边我能不紧张么)
处理
看到有用户反馈无法登录,我立刻就去尝试,随后负责人联系到我,叫我看,就在我看了几分钟后,不断的有用户反馈无法登录,此时我第一反应回滚部署,可是上一手负责人仿佛给我挖了一个深坑,回滚的版本设置了只保留两个,因为之前发布过一次,所以无法回滚了,怎么办.
我又想到,回滚分支吧,但master分支合并了几个功能分支和一些bug分支,自己平时也在上面改点小的东西,最主要的是提交日志不规范,导致使用git reset时选择错版本(当时没发现),于是push代码后由gitlab去走ci,ci这家伙好像是跟我作对似的,这个时候就开始慢起来了,打包加部署居然花了十分钟,期间总监不断走过来问我进度,我更慌了.
更骚的是,ci跑到部署的步骤居然出错了,得,合着我前9分钟白等了....,期间用户又反馈了几个问题,在用户和总监的双重压力下,我终于回滚代码并且重新发布一次.
发布完之后,得,用户开始无限跳转登录页了,此时我感觉我的职业生涯就要完了,脑子已经想象到总监找我喝茶直接把我炒由于的画面了.
就在我心态快崩掉的时候,我发现原来服务器上还按hash值保留着发布的文件,并没有真正意义的删除,只是不能根据版本号去回滚发布,当即立即选中之前没有问题的版本的hash值,回滚.
终于,用户们都安静了,殊不知我的心在这半小时内像坐过山车般刺激,感觉一下子老了几岁.
反思
在这次技术优化中回过头来发现自己的确是很多地方做得不够好:
- 没有先设计后实现,而是想到哪里做到哪里,导致会遗漏掉很多场景
- 组件没有单元测试,没有e2e测试,流程没办法保证,该项目以前就没有,如果要引入花费代价还是比较大的
- git提交日志不规范,老友条式的提交代码,例如提交日志写的是修改等无意义字眼
- 没有与组员进行code review,所谓集思广益
- 重大改动需要测试人员在场参与
- 多了解公司内部的项目管理系统,以便进行更迅速的回滚发布
- 灰度发布,对于此类影响比较大的修改可以采取灰度发布,目前公司只有基于服务器的灰度,没有基于用户的灰度,以后可以考虑实现一个
- 旧代码存在就是合理,不要随便删掉,即使它看起来毫无作用
- 不要太莽,看到不好的就想重构,对于系统来说,稳定可用是第一前提
- 优化需要考虑用户电脑配置,这次加了动画过渡和缓存之后,用户电脑反而更加了
总结
这次优化自己总算是明白为什么很多人宁愿守着恶心的代码也不重构了,毕竟没有完善的重构会引起更大的问题,也让自己成长了很多,知道自己很多点考虑得不周全,期望以后的优化都能稳而准,就算出问题也能光速回滚.
