前言
项目进行到一定阶段，项目体积越来越大，某些模块的数据量也越来越大，无论是我们日常跑项目，编译项目，或者对于运行中的项目的一些体验，都感觉到些许慢或者卡了。这时候我们就需要去做一些优化了。今天就谈谈我最近在优化这一块做的一些事情。
做了几件事
- 减少文件数
对于一个庞大的项目来说，有非常多的文件，这样会导致webpack在构建编译的时候速度很慢，这会降低工作效率与开发体验。首先对于一些没有引用的文件应该删掉，你可能会说，这些文件是因为需求变更导致的，不删是担心需求又改回来了，那我还是建议你删了，需求变更你就重新评估你的工时，顺便再把产品经理摁在地上摩擦一下。对于一些重复的逻辑或者布局，我们应该抽成组件，而且差别不大的组件不应该在多个目录中出现。
- 减少代码行数
首先还是得删掉注释代码，代码既然注释了就用不上了，放着只会影响其他同事阅读你的代码。这时候你可能也会说，还不是那叼产品经理天天改需求导致的。确实，作为开发，我们有一些苦衷，但是还是不能因为这个使我们的代码变得不利于阅读，使项目体积过于庞大。然后，就像上面说的，对于重复的东西，我们应该做好封装，我们要做一个有点追求的CV工程师。
- 减少节点数
在我们平时写页面的时候，我们可能觉得多嵌套几个div对于我们的页面性能没有任何影响。确实，数据量小的时候确实没啥影响，但对于一些列表渲染页面，像一些树形菜单阿，多重表格之类的，当数据量很大的时候，你可能在点击展开菜单的时候，要等很久，甚至页面卡死，就是因为数据量大，冗余的HTML节点多，要渲染的节点会多出很多，导致性能下降，这时候，优化我们的组件和页面节点数也是一种有效手段。
- 提升代码质量
我们时不时会听到“屎山”这个词，当我们遇到屎山的时候，我们应该是继续默默地在屎山上拉屎，还是在屎山雕花呢？墙裂建议你，当你入职一个新公司的时候，遇到屎山了，应该试着去优化它，实在优化不了了，做好注释，至少要证明这堆屎不是你拉的。而且你应该指出来，告诉同事怎么优化，优化不了就重构。不过，在项目初期，我们为了交付，我们的目标就只有交付，代码只要能跑就行，可能也没有人去要求你的代码质量。而且，我们的开发周期非常紧张，我们还要去理解业务，我们确实没时间去考虑代码质量，这是我们的借口，也是我们的苦衷，但当你的新同事接手你的代码的时候，人家可不会为你考虑这些，人家只会使劲喷你，站在前人的肩膀上使劲地踩你。代码是我们在同事中的签名，所以无论何时，都请注重代码质量，尝试用设计模式去优化你的代码。要有这样的一个意识，代码是写给别人看的，而不是写给自己看的，所以你在写代码的时候，要秀起来，秀给别人看，让别人看看你的代码有多叼。对于代码质量，我们还可以加入eslint去约束你和其他同事的代码，另外，做好code review也是一种有效手段。
使用工具
对于以上的优化，我们可以借助一些工具来检测你的项目文件和代码，工具会产出数据报告分析，这些数据可以告诉我们优化的方向，也可以通过前后数据对比去衡量我们的优化是否有效。这里推荐一个第三方代码检测工具sonarqube以及一个vscode 插件Code Counter。
最后
这次优化就不去讲那些通用的性能优化手段了，像什么减少HTTP请求数、减少dom操作、图片优化等等。而是根据项目本身的一些实际情况做的一些优化，具体情况具体分析。写的不好的地方，请加以指点，谢谢。
