WHAT :重构是什么？ Martin Fowler :重构是软件内部结构的一种改进，其目的是在不改变软件可视行为的情况下，使其更容易理解，降低修改成本。
大型重构对象：对系统、模块、代码结构、类与类之间关系等的重构方法：分层垂直分割、模块化水平分割、解耦、抽象UI组件、抽象业务组件、抽象块方法论设计模式的影响：引入代码变更多、影响面广、难度大、耗时的高错误风险小型重构对象：对类、函数、变量等代码级的重构方法：规范命名(知道名称)、规范可eslint等方法论)代码样式的统一、规格的制定、语义编程、对eslint的影响)引入影响面小、难度低、次数多、错误风险低的WHY ) )。 由于软件最初设计时没有考虑到所有功能和细节的软件需求变更和持续迭代，因此原设计已经不适合消除破窗效应。 代码中有不好的味道，如果不马上改善的话，易碎的罐子会坏并加速恶化。 HOW :如何重建代码？ 利用编程范式思想，以面向对象的过程导向函数型编程设计原则为核心，以solidkissdryyagnilodcrpeslint为基础手段，逐步定制airbnbstandardrecommandedprettier 在不影响持续集成、进度控制、流程可逆性、常规业务开发进度的前提下，根据金字塔原则划分项目代码将业务模块进行水平划分，对代码进行分层垂直划分和评估， 各重构单位需要花费时间合理地评价工作量，以提高重构的性价比来提高重构的控制性，或者计划中的业务单位顺利地完成重构，其他部分留出空闲时间依次重构如果确实存在，则只能说明项目太小或稳定且迭代少。 在这种情况下，需要考虑是否真的需要重建！ 如果没有锤子(重构方法论)，全世界都要钉钉重构的不是软件开发所需要的过程，而是现有代码的组织缺陷和不合理的修复方法。 养成好的代码风格和code review的习惯避免代码的不好的味道是根本WHEN :你什么时候重构？ 不是在积重难成瓶颈之后再进行重构，而是大规模、高水平的重构需要时间和劳力，难度极大。 树立渐进持续重构的意识，发现当前业务代码格式存在问题应立即进行小规模重构。 不是技术债务的漏洞。 重构不是会引入新的bug吗？ 是的，所以怎么办？
如何在完整的单元测试中保证重构前后的外部可视性一致有条件的话找专业测试进行端到端测试和灰度测试RISK :如何解决重构在线带来bug的风险？ 如果不通知业务方直接在线重构的代码，出现问题时，你一定要负全责，重构没有功劳也没有辛苦
有条件要找专业测试进行端到端测试和灰度测试，必须通知业务方，说服业务方同意，让业务方做好准备，然后进行核查。 如果真的引进了bug也很少追究责任。 因为在预料之中，我们的目标也是为了项目的长期发展。 FEASIBILITY :如何让业务方认识并同意现阶段的重建？ 让业务方、产品、测试看到开发中的痛点和技术瓶颈，让所有人都意识到缝合修补破窗效应所带来的问题加剧，要提供一个强调重构带来的技术效益和业务效益的可行且可控的重构计划方案PERFORMANCE已经很困难了如果重建的价值得不到认可怎么办？ 明明是因为你的代码烂了才重构的，还有脸浪费时间提高性能吗？ 想吃个屁，就承认自己写bug，表示没有程序员不写bug，勇于承担和弱化责任，表示业主身份和地盘，需求频繁变动，紧急需求反推工时，使业务长期规划方向信息不同步于开发没有eslint规范等(虽然主要责任不在我，但表示意识到问题并积极解决了)强调重构带来的好处)错误数量减少、维护成本降低、错误排查加快、开发速度加快等欢迎友好交流) )。