不只是前端工程师，相信任何一个程序员都或多或少会遇到这样的问题。原因有很多，比如之前团队的技术水平，代码规范；产品大改后，新旧逻辑耦合在一起，等等各种原因，最后手上的作品一坨屎。注意，我们不可能在短时间内让一个项目焕然一新。必须有一个过程。我们必须在代码质量和产品进度之间做出权衡，因为程序员创造价值，而不是代码。因此，价值（按时交付功能）始终是我们优先考虑的最重要指标，但是代码质量，以及产品的进度，在实现您手中的每一行代码时都应该进行比较和考虑，这也是一个我们的工作内容。看旧代码其实不准确。我们需要运行它。我见过同事因为两天没跑项目，面子不上来求助。首先，注意我们的目标代码块。什么是目标代码块？如果想提升老项目的性能，打开控制台性能，看看哪个部分耗时最长，网络原因，js运行，渲染效率，预加载延迟加载不合理，可能是问题，找到问题所在.如果你要增加新的需求，找到你的需求和主线逻辑的关系，找出哪些代码可以使用。它们是你“显摆”的最佳帮手。这是一种从混乱中找到这些的能力。如果是技术栈改造，不要急着直接做。找到一个小而完整的模块。以vue项目为例。比如一个小弹框，里面有vuex，网络请求，依赖一些小库，先把这部分拿出来进行改造，保证最小范围内的完美，把大部分的坑都踩了。总之，看代码的目的不仅仅是为了看懂逻辑，更重要的是为了找到逻辑。工作从白板而不是键盘开始。在乱七八糟中找到一些好东西之后，你就会开始工作，但是处理乱七八糟的东西有它的特殊性。把乱七八糟的东西弄好并不会产生价值——因为事实证明不是不能用～所以作为搬砖的人，首先要弄清楚如何体现自己工作的价值。这种看似很油腻的做法（可以向领导反映），但绝对值得深思。对于问题，定位到你想要输出的价值，明确引导自己的工作流程；设计代码时，明确要点；优化点应该优化到什么程度才能达到最优的投入产出比。要求同事和项目负责人就您的工作的重要性提供反馈也是合理的。于是一切从设计开始，梳理出一条路径，画出关键部件的时序图，然后轻装上阵。但不建议在设计本身花费太多时间，可以在开始工作后逐步完善。举个栗子，前段时间接手了一个微前端的项目。主项目和子项目都使用vue-cli作为脚手架1.网络请求问题，接口转发，mock解决方案2.组件拆分不合理，导致大量重复代码3.部分错误控制台无法报网络问题。由于很多原因，前后端接口在本项目中实际上是同一个接口。..在接口中使用参数进行路由是该接口的一项功能。..既然不能改变大环境，那就用技术改变生活，提升自己的开发体验，上传代码/***通用转发接口*@param{String}serviceAlias服务别名*@param{Object}数据请求data*@param{Boolean}isMock拆分mock和dev接口，有些接口是人联合调试的，有些接口是自己mock的*/exportfunctionactionRequest(serviceAlias,data,isMock){//DebugusingconstdevUrl='http://122.249.157.194:8080'//如果通过devUrl连接到相应的后台，需要做跨域设置constbaseUrl='/product/action?s='+serviceAliasleturl=''if(isProd){url='/prod'+baseUrl}else{url=isMock?'/mock'+baseUrl:devUrl+baseUrl}returnrequest({url,method:'post',data:newdataFactory(serviceAlias,data)})}满足三种场景，生产环境，开发联调，自给自足（mock）相比原来的mock有了很大的改进，发挥能力有限，接口在文件中使用了大量重复代码，参数拼接混乱。组件拆分不合理，导致代码重复很多这么说吧，有几个1000多行的文件，大部分都会在另一个需求中用到。首先找到可以用到的逻辑，用mixin或者extend，而提取组件的方法先把需要用到的大块逻辑拿出来（胖子一口吃不完），只写到这里你知道vue3的新特性CompositionAPI在写组件的时候有多爽吗（组件提取很方便）主要原则是单一职责，props简洁易懂（不懂的可以加注释),child帮parent消化非主线逻辑，只把结果给parent，最重要的是，不能影响原来的功能！！！各种原因就不贴代码了~有些错误控制台因为架构原因报不出来（微前端），有些写法在本地环境下没有问题（自己工程），但是一旦搞定要编译的主工程，他们会在vue-router.这种情况遇到过好几次了，每次都是在摸索，把代码从头刷到尾，看砍掉一部分代码后错误会不会消失。另一个困难是我们每次都必须等待部署才能测试代码。经过逐步探索，我们提高了效率和二分法。...真的没有别的办法。..后来意识到必须要有能力在本地完美复现线上环境（微前端开发模式，我们只负责部分子项目），所以我们使用node启动服务，模拟部署主项目和子项目的代码。最后，提出了实验的效率。.最终查询发现的问题大部分是语法问题。最后的解决办法是优化eslint的配置，避免badcode，CR不能每句话都读一遍。..最后当然不喜欢乱搞，因为同样的难度，很难有产出，但是有困难就有痛点，不然你的价值何在？我希望世界上没有代码。
