课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
我们在上文中给大家简单介绍了代码重构的一些基础知识与操作方法等内容,而本文我们再来说说,代码重构常见问题与注意事项。
1、什么时候重构?
不要等到积重难返有了瓶颈之后再进行重构,大规模高层次的重构耗时耗力难度剧大
应该建立起渐进式持续重构的意识,发现当前业务代码写的有问题就应该及时进行小规模的重构,而不是欠一屁股技术债
2、重构会不会引入新的BUG?
会,所以怎么办呢?
通过完整的单元测试保证重构前后的外部可见性一致
有条件的话找专业的测试进行端到端测试和灰度测试
3、重构上线带来BUG的风险怎么解决?
如果不通知业务方直接将重构的代码上线,一旦出现问题,你肯定全责并且重构没有功劳也没有苦劳了
有条件的话找专业的测试进行端到端测试和灰度测试
必须通知业务方并说服业务方同意,让业务方做好准备上线后检查一下。如果真的引入了bug也不太会追责,因为在预期内并且我们的目标也是为了项目的长远发展呀
4、重构价值不被认可怎么办?
明明是你代码写的烂才导致的重构,浪费时间,还有脸要绩效?想屁吃呢
承认自己会写bug,表明没有不写bug的程序员(勇于担当并弱化责任,表明owner身份和地盘)
指出导致重构的其他原因:需求频繁变更,紧急需求倒排工时,没有将业务长期规划方向信息同步给开发,多人协作团队没有统一风格,团队没有codereview,没有eslint规范等等(表明主要责任不在我,但是我意识到了问题并主动解决了)
强调重构带来的优点:BUG数量减少,维护成本下降,BUG排查变快,开发速度增高等(业务价值才是绩效的根本)
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请在707945861群中学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。