不只是前端工程师，我相信，任何程序员多多少少都会面临这样的问题
起因有很多，上任团队的技术水平，代码规范；当前团队的不靠谱队员；经历了产品大型改革之后，新老逻辑耦合在一起，等等原因，最终导致你手上的工作就是一坨shit。
注意，我们不可能让一个项目短时间内焕然一新，一定有一个过程，在代码质量和产品进度之间，我们一定要有所取舍，因为
程序猿产出的是价值，而不是代码
所以，价值（按时交付功能）永远是我们排优先级的最重要指标，但是代码质量，和产品的进度，落实到你手上的一行行代码时，就要加以对比和考量，这也是我们的工作内容之一。
看老代码
看其实并不准确，我们要将它跑起来运行，我曾经见过因为两天没有跑起来项目的同事，抹不开面子求助，最后耽误进度还疯狂甩锅……
看代码的时候，要首先关注我们目标代码块，什么是目标代码块呢，如果你是为了提升老项目的性能，就打开控制台的performance，看哪一部分耗时最长，网络原因、js运行、渲染效率、预加载懒加载不合理，都有可能是问题，找到问题所在。
如果你要添加新的需求，找到你的需求和主线逻辑的关系，找到哪些可以用的代码，他们是你“揭竿而起”的最好帮手，能从烂摊子中找到这些是一种能力。
如果是技术栈的翻新，不要着急直接动手，找到那种麻雀虽小，五脏俱全的模块，拿vue项目举例，比方说一个小弹框，里边vuex、网络请求、依赖一些小库等等都有，先拿出来这一部分进行翻新，保证最小范围的尽善尽美，踩到绝大多数的坑。
总之，看代码的目的除了看懂逻辑之外，最重要的就在于找。
工作从白板开始，而不是键盘
找到一些烂摊子里的好东西之后，就要开始动手了，但是处理烂摊子这种事情，有他的特殊性，把烂摊子变的好一点，不会产生价值——因为原来又不是不能用～
所以作为一个搬砖的人来说，你要先搞清楚，如何体现你工作的价值，这好像是个挺油的做法（可以向领导汇报），但这绝对是一个值得思考的问题，定位你要输出的价值，明确的指导自己的工作流；代码设计的时候，明确要点；优化点优化到何种程度，才可以达到投入产出比最优。也可以合理的想同事和项目负责人反馈，你的工作意义何在。
所以一切都是从设计开始，整理出一条路径，关键组件要画出时序图，接下来就是轻装上阵，但是设计本身不建议花太多时间，开始工作之后可以逐步完善。
举个栗子
前段时间接手了一个微前端项目，主工程和子工程都是用的vue-cli作为脚手架
1、网络请求问题，接口转发，mock方案 2、组件拆分不合理，导致大量重复代码 3、有些报错控制台报不出来
网络问题
由于很多原因，前后端的接口在此项目中其实都是一个接口。。。 用接口中的一个参数来路由到底是那个接口功能。。。 既然大环境改变不了，那就用技术改变生活，改善自己的开发体验，上代码
/**
* 通用转发接口
* @param {String} serviceAlias 服务别名
* @param {Object} data 请求数据
* @param {Boolean} isMock 给mock和dev接口分流，一部分接口和人联调，一部分接口自己mock
*/
export function actionRequest(serviceAlias, data, isMock) {
// 调试使用
const devUrl = ‘http://122.249.157.194:8080’
// 如果通过devUrl连到对应后台，需要做跨域设置
const baseUrl = ‘/product/action?s=‘ + serviceAlias
let url = ‘’
if (isProd) {
url = ‘/prod’ + baseUrl
} else {
url = isMock ? ‘/mock’ + baseUrl : devUrl + baseUrl
}
return request({
url,
method: ‘post’,
data: new dataFactory(serviceAlias, data)
})
}
满足三种场景，生产环境、开发联调、自给自足（mock） 相对于原来mock发挥能力有限、接口在文件中使用大量重复代码、参数拼接混乱，已有很大改善。
组件拆分不合理，导致大量重复代码
这么说吧，有那么几个1000多行的文件，其中大半在另外一个需求中会用到
首先要找到这些可以拿出来用的逻辑，用mixin或者extend，和抽取组件的方式先将需要用到的大块逻辑拿出来（不能一口吃个胖子），写到这的时候才知道vue3中的新特性 Composition API 在写组件的时候有多爽（组件抽取非常方便）
主要的原则就是责任单一、props简洁易懂（不容易懂就加注释），子级帮助父级消化非主线逻辑，只给父级结果，最重要的是，不能影响原有的功能！！！
各种原因不贴代码啦～
有些报错控制台报不出来
因为架构的原因（微前端），有些写法在（自工程）本地环境什么问题都没有，但是一拿到主工程来编译，会在vue-router里报出一个莫名其妙的错误。
这种情况遇到好几次，每次都是摸索，从头到尾刷代码，看看砍掉一部分代码会不会报错消失。
另一个困难是，每次都要等部署，才能检验代码
逐渐摸索之后，我们提高了效率，二分法。。。。
真的是没有办法的办法了啊。。。
再后来意识到，我们要有在本地完美复现线上环境的能力（微前端开发模式，我们只负责一部分的子工程），于是自己用node起服务，模拟部署了主工程和子工程的代码，终于将实验效率搞上来了。。
最终查询出来的问题大多是语法问题
最后的办法就是优化eslint的配置，避免掉不良代码，CR也不能一句一句看不是。。。
最后
当然我们不喜欢处理烂摊子，因为同样的难度，却很难有产出，但是有困难就有痛点，不然你的价值在哪呢
愿天下没有成坨的代码
