在工作中免不了要接手公司一些老项目，这些项目可能是在部门刚成立时维护至今，项目中使用的技术栈可能在前几年看着还行，但现在又有更成熟更优秀的解决方案，再来看之前的代码就有些过时了。老项目承载的业务也很复杂，由于不断更新迭代两三年了，经手的人肯定不少，每个人都有自己的开发习惯，比如相同功能的组件你写一个我又写一个，如果没有人来定时维护整个项目，只是大家各自开发自己负责的功能模块，不断的堆叠，会导致很多冗余的代码和模块。
如果从没有做过优化，这样的结果就是，项目像堆垃圾一样越堆越多，导致页面越来越多，项目也越来越大，打包很慢，发布很慢，页面响应速度也很慢，很影响用户体验，简直到了不能忍受的程度。这才不得不思考优化的事情。
为什么会这样呢？真的到了这种时候，优化成本会几倍的往上涨，越早发现问题，越早解决花费的成本越小，解决的复杂度越小。但大部分人往往会选择忽略，只关注自己的那一小片需求。
可以从几方面来说导致这样的问题吧。一方面是团队leader不重视代码质量，一味的赶业务，这种情况大多出现在初创期，先把业务赶上来，这也情有可原，但有追求的开发人员会尽早优化代码。还有一方面是开发人员自己不重视，做完就完，这也需要团队刻意的引导提高团队的代码质量。当然开发项目时也要给开发人员留出足够的思考时间，如果想都没想清楚就去写，那写出的代码可想而知，这需要在项目排期上有一个共同的认识。
前人挖坑后人填坑，还是那句老话出来混迟早要还的。
那这个坑要怎么填呢？一群人叽叽喳喳的讨论，现在市面上都可以提供一些成熟的解决方案，我们要不要照搬过来用在我们这个项目中？有人说可以用服务端渲染(vue nuxt)提高页面的响应速度，还有人说可以把项目Cli2升级到Cli3优化打包编译速度。
上面说的这两种我都不赞成，稍微有点经验的前端仔细推敲下，都会say No（如果你是Yes，你厉害）
为什么不赞同。先说下vue服务端渲染，Nuxt是Vue服务端渲染成熟的解决方案，基于Vue提供了开箱即用的服务端渲染库。那什么情况下我们需要用到服务端渲染呢？可以看官方解释如下：
- 更好的SEO，可以让搜索引擎爬虫抓取到页面数据；
- 页面更快的加载速度；
再来看看我们的项目真的适合吗？现有大部分项目主要是开放给用户的后台管理系统，主要服务的是和公司有合作的特定人群，项目本身并不需要SEO来搜索。如果说提升页面的响应速度，非要整栈SSR吗，路由懒加载不好用吗？且不说单页面应用改服务端渲染的成本，真的就没有其他更好的解决方案了吗？是否真的清楚导致页面响应慢的原因，图片资源、JS、CSS资源优化了吗？
在制定一项优化措施时，不要片面的想这个方案正好可以解决我们项目的问题，我们就用吧。而是要根据自己项目的真实情况，从实际出发看看适不适用当前项目，不是拿来主义，而是就事论事对症下药。
再说下一个Cli2升级Cli3，真的有必要吗，为什么要升级呢，仅仅是为了提升打包编译速度，Cli3是怎么提升打包速度的，直接将项目webpack3升级webpack4不好吗？webpack4相比于webpack3打包速度也是很明显的，难道不能达到同样的效果吗？
我只想说年轻人不要那么冲动，不要动不动就要对项目换血换肉，也要根据项目优化周期、影响范围、性能提升的程度来做判断。
Cli2升级到Cli3看似只是给项目换了个壳子，但项目的一些内部引用版本都是未知的，因为不是从头搭建一个项目而是在旧项目上改造，就可能出现一些未知的问题，对整个项目都增加了不可控的风险。如果只是单纯的认为Cli2升级到Cli3只是webpack的改变，那我也没什么可说的，这是公司的项目如果你非要这么玩那也没办法，项目的风险评估如果没有考虑周全，到时候出问题只能你自己担着了。
webpack3升级到webpack4，虽然也是一个大版本的升级但相比升级脚手架，webpack的升级只是单纯的影响打包编译我认为风险点还是相对可控。
上面说了两种都是我反对的优化方案，那有没有好的优化方案建议。有是有，但我的优化方案只适用于我的项目，每个公司的项目技术栈和问题各不相同，只能说有一套通用的步骤，先找到问题，然后对症下药解决问题。
项目优化可以从下面的几个步骤开始：
- 首先调研清楚现有项目面临的问题及优化点都列出来；
- 然后根据现有的问题提出解决方案最好多提出几种列出来；
- 评估解决方案的影响范围，开发时长，找出相对来说最优的解决方案；
- 根据项目周期将优化点随项目进度穿插进去，优先解决最紧迫的问题；
- 最后协调开发测试上线时间；
小结：
为什么我不赞成在旧项目上大刀阔斧的改，主要可能会造成不可控的因素，旧项目业务本身就具有复杂性，项目引用的第三方库，以及它的引用依赖，有时升级一个小小的版本就会造成截然不同的写法，如果很隐蔽测试没有发现，发布到线上，影响用户体验就是很严重的问题了。我们都知道获得一个用户是多么不容易，损失一个用户又是这么轻而易举的事情。
So，在做一些优化改造一定要慎重谨慎，充分考虑各种情况，一个项目可能有成千上万的用户，如果由于一个技术优化导致的小小疏漏，影响用户使用那真的得不偿失。
升级优化要明白项目的问题点在哪里，要达到什么什么目标，如果通向一个目标的路径有好几条，有些是捷径比如Cli2升级Cli3，但你不知道会碰到什么问题。有些可能迂回比如webpack3升级webpack4，但每一步都是可控的，清楚明白用了什么配置。我更倾向于可控的选择。
技术填坑升级优化，并不是一劳永逸，业务需求总是在不断迭代，问题也总是一个接一个，应该将优化贯穿始终，从每一个小版本迭代开始，将平时开发中可能遇到的问题和待优化的地方记录下来，在下一次迭代中不断改进。