<aside> 💡 说一说: 重构是门行为艺术
</aside>
略略略
重构哪一部分是必须要在重构工作之前就确定好的，不然你的重构工作会没完没了。但如果出现某一个部分不算重构工作的一部分，但代码质量堪忧，如果时间充裕，建议立即重构该部分代码。
不要被前者思维困住手脚，因为有些东西当初设计者在设计的时候也没有想好。身为一名去重构的背锅侠，你的眼界一定要高于前者，就算没有像前者那么熟悉项目，但也要压其一等，不然以着矛盾的心理去进行重构是很可怕的。
其次就是要看熟文档，至少所以大标题都要有一遍印象，这种印象浅一点也没关系，只要出现了某个问题，你能及时在文档里找到解决方案就好了，而且自我还要对整个项目在心中有成熟的心智模型，所有重构的内容都要保证可控、可预测。
我重构了他的重构，这种现象据说在大厂很常见，无限刷新 Kpi， 轻轻松松 375 。说实话，虽然这样确实有助于项目的技术栈与时俱进和愈来愈可控。但重构不只是重构代码呀，身为一名背锅侠，你也要把前者留下的所有东西都要 refactor / patch，包括文档。
略略略
略略略