看烂到什么程度以及当前的需求，如果能抢救，考虑人力成本还是抢救一下；如果挖坑太多，重写吧……

接手一个项目，无论多老多烂，第一点肯定是熟悉它的架构，以及使用的技术栈，分析其架构，如果时间允许，最好重新设计架构，选择新技术，出项目维护文档，这也是为以后做准备，如果时间不允许，我还是建议，主动加加班，重新设计，这是为以后的事情考虑，现在加把劲儿把项目做好，以后再加新需求就轻松、舒服多了，不然每次时间都很紧张，每次做的都很烂，只会越来越烂，每天面对一个烂项目，简直要疯掉。

这个问题好难回答呀，个人认为还是先明确需求痛点吧。
比如分为以下几类，统一代码规范、功能优化、功能重构拆分、更新技术栈、架构重构。

比如普通项目转为 cmd 模块化，统一命名规范，js 中的长字符串转 template 等，
这类对功能影响也不大，改起来应该不会很久，就看代码会爽很多。只是不宜一次性改太多。

比如部分页面加载时间过长，图片使用太多，接口出入参混乱等，
都是非常有针对性又可能无法预估耗时的改动，这样的优化相对需要更加谨慎。
但这个用来搞绩效会很有效果，非常容易得到赞许，看个人吧。

比如拆分 Date/金钱/对象数组的处理，统一类型与默认值判断等，
这类非常公用又能装逼的，也能一定程度上考验自己的代码理解能力和功能抽象能力。
排期上可能调研时间会更长些，但基本不会影响功能甚至能有一定优化。

比如 jquery 转 vue，react 升 16，iframe 转 jquery 等，
都更应该是递进式修改，先改不常用的页面，一步步地替换原页面。
注意，这里是不太适合使用 cli 框架的，直接引入 vue.js 文件开发要更好，
等一切结束了，再转为 cli 框架会轻松很多很多。

架构重构基本就很难讲了，如何存储如何通信如何复用可能都与现在情况不同咯。

所以，接手垃圾的老项目，一次性改完重构是不太现实的，按需求痛点一步步更新要更好些。

• 先熟悉业务逻辑，都有些什么功能，用到什么技术，然后逐层剖析细化，熟悉之后维护起来就顺手了。

跑路

重构项目需谨慎. 重构好了没奖, 出了问题有罚

rm -rf *

1. 项目烂，如果功能正常，就尽量不要改变已有功能。功能正常是第一位的
2. 新功能尽量新建项目添加，而不是在原来基础上做。可以应用微服务
3. 如果非要在原来基础上开发，必须要先完全清楚原来的架构，并添加必要的测试基础上修改

1. 项目烂，如果功能正常，就尽量不要改变已有功能。功能正常是第一位的
2. 新功能尽量新建项目添加，而不是在原来基础上做。可以应用微服务
3. 如果非要在原来基础上开发，必须要先完全清楚原来的架构，并添加必要的测试基础上修改