拿到糟糕旧页面，前端选择重构还是修补？
每个做Web前端的人，几乎都接过"祖传页面"。文件上千行，JS/TS和业务逻辑混在一起，组件没有边界，接口调用散落各处，改一个按钮都担心影响其他功能。很多人的第一反应是全部重构，但真正在线上项目里，这往往不是最优解。重构的前提是收益大于风险。如果这个页面还会长期迭代，涉及多个业务模块，尽早拆分React或Vue组件、梳理状态管理、统一工程规范，是值得投入的。如果只是临时活动页，或者半年后就会下线，花大量时间重构，业务价值并不高。我更认可一种做法：边开发边治理。每次需求只优化自己修改到的部分，把重复逻辑抽离，把命名规范统一，把容易出问题的模块逐步替换。几轮迭代之后，代码质量往往比一次性重构更稳定，也更容易被团队接受。技术决策没有标准答案，关键还是看业务生命周期，而不是代码写得漂不漂亮。
发布于 山东
分享
评论
赞
未登录
友善发言
评论
加载中
