前言
你将得到什么？
通过本文，各位将了解（或者学习）到：
- es-module 导入导出
- 可能用的较少但比较好用的正则语法
- vscode 插件从设计到实现
- ...
本文内容较多，希望对你有所启发，如有建议或者纠正，也望不吝赐教。
代码”减肥“的起因
各位好久不见🌺，前两个月的时间经历了一个月的加班以及一个月的居家办公。在疯狂加班的那段时间手里接到了一个时间比较紧急，历史包袱也比较重的项目：
- 产品形态出现多次变更
- 开发人员几经转手
- ...
以及本次迭代版本服务端架构出现了比较大的变更，使得老的前端代码设计难以支撑新架构下服务端 api 的变更，于是催生出我的一个想法：
重构吧！
重构的结果还是好的，既赶上了提测，也在优化项目结构的基础上完成了 50% 代码量的减少，而 50% 对于本项目而言，大抵是相当于 10000 行左右的代码量。
在这次代码“减肥”的过程中我有了一些总结（或者说是一些比较让我揪心的体验），使得我有了后文中的想法。
读到这里可能大家会问：你加班了一个月，那居家办公那段时间下班后都干嘛去了？
我只能说，swicth 真好玩!
揪心体验
不知道各位在职业生涯中有没有遇到过以下体验：
- 一个文件完全没有被使用过，但是在项目目录中恬不知耻的存在着
- 一个方法，一个配置信息或者一个常量早早就已经过时了却依旧存在
若项目历史不久，此类信息倒是影响不大，但是随着版本迭代，他们会越来越多，并好似狗皮膏药一般深入到项目代码的各个角落，难以察觉，又恶心至极！
这种删又删不干净，又没事突然出现恶心你一下的感觉真的难以言表...
💡：无效的文件可能容易发现并且在适当时机进行删除，但是无效的常量或配置类内容就真的难以处理。
于是我在此次重构过程中几乎审查了所有的历史文件，所以我那代码量减少 50% 的壮举不全是我设计的功劳，很大一部分还是由于删除了大量的无效代码...(诶，真的很不想承认，但是做人要诚实🍉)
在删代码的过程中，我产生了如下想法：
这个过程，需要更加智能
做更“懒”的工程师
根据前面的铺垫，我想各位已经知道了我此次的目标：
- 自动识别无效文件
- 自动识别无效常量（配置信息/公共方法等）
然而，我喜欢画饼，在开发之初我就画了以下思维导图，插件命名为 let-s-refactor 也是希望我这个插件所做的事情不止于此，可以为提高代码库质量提供更多能力！
而对于代码的读取分析，最方便的手段也就是：vscode 插件。文章的后续内容便是插件的第一批功能清单以及开发思路的分享。
功能清单 V0.0.1
本次介绍 v0.0.1 版本的三个主要功能：
- 统计代码行数与文件数
显而易见的需求，不计算代码行数与文件数，怎么统计最终的成果（没错，主要工作还没做的我就已经开始思考成果的展示了🍉）
- 列出项目中的无效文件
将项目中无效的文件展示出来，以帮助进行后续的分析删除
- 列出项目中的无效导出
将项目中无效的 export 展示，可能包括常量，配置信息与公共方法。
注意：本插件现仅支持本公司统一框架下的项目，未来想通过配置文件的方式支持所有项目。
