最近在用AI重构之前的一个开源的vue3的后台管理项目，前端框架大家大概很熟悉，就是Ruoyi版本的Vue3。
这种重构优化，在以前的话，是我一个人想都不敢想的脏活，现在配合AI，在下班时候看着电影就能做完。
真是时代的伟力，AI，太伟大了。
正文
在正式开始之前，我先说一下我为什么要优化这个项目的背景。
项目背景
- 我需要一个后端管理系统来做一些个人性质的项目，预算成本不高
- 我的技术不够硬，不是一个正经的JAVA+WEB性质的全栈工程师，平日主前端开发
- AI发展很迅猛，我需要一个前后端都能搞定的项目
- 技术栈通用，前后端我一个人能排查搞得定，且生态要相对还行的那种
- 项目要足够的轻量，如果项目写的太配置化，太复杂，对大项目确实很友好，但对我这种个人性质的小项目就显得很繁琐。
一，我不是一个正经的全栈工程师。
我的技术栈不够广，在国内现在这个的大背景下，我不是JAVA的WEB的全栈工程师，很尴尬。
关于JAVA，我只能简单的写写接口，深层的内容我是一点也弄不明白，很纯粹的码农。
而且，公司一向都是前后端泾渭分明，职场上，你越界贸然做其他人的活总归是不好的。同时，做的越多，背锅越多。
综上，我对JAVA的学习动力本质上是没那么足的。
二，我个人的预算配置不够
JAVA的项目都很重，部署到服务器上，这项目会很吃服务器资源。
正常来说，为了运行一个常规的SpringBoot的后端（例如若依），4C4G的服务器会比较稳定一些，这个成本不低。
而且，有很多事情上，如果JAVA出问题了，我作为一个技术面不足的人没法顶上，人力成本不够，就算我愿意花时间和精力去学，无法快速迭代出一个可见品，这个收益不如去卷前端技术（虽然现在也没什么必要了）。
但是，我又确实有些东西需要服务端来做，于是经过一段时间选型之后，最终选定了NestJS来作为后端的框架。
三，AI发展迅猛
一年前的时候，我知道有cursor，也体验过各类智能编辑器开发，但实际开发体验中总是差点意思。
而且因为工作原因，加上我工作环境的原因，我在正式环境上使用相关技术用的还是很保守的。
一直到年后，公司提供了免费token之后，不是自己的自行车那我肯定猛猛蹬，现在用起来根本不心疼，库库用。
在这个过程中也逐渐有了些心得，用来干脏活效果好了很多，所以我也有这个精力和时间成本去学习其他的技术，而且干活的时候不耽误我看电影。
在优化这个开源项目的时候，几乎是一边看着电影，一边做优化的，我就只需要确定大概走向之后，点点确认就可以了。
优化路线
目前主要是对前端项目做了优化，主要原因是这个前端用的太Vue2了。
我参考了市面上其他的开源项目，如Vben，之类的，不得不感叹，还是开源社区大佬多。
- 起用vite8对项目构建和打包，优化相关打包配置，更快更稳。
- 引入autoImport来构建项目，让项目引入工具TS更简单。
- 项目使用TS重构，让代码更易读
- 引入zod库来判断，让判断更语义化，更清晰。
- 采用最新版本的Vue3，能用更多的新特性
- 优化数据字典的获取，一次性获取全局的数据字典，避免页面重复调用接口
接下来我会挨个说明为什么要在项目中做这些优化。
Vite8构建与打包
- 项目打包速度从50s提升到15s左右
- 项目本地开发构建，从1s左右的等待时间到几乎秒开
- Vite8统一了打包和开发构建的方式，不会出现前后端在开发和正式环境不一致的情况（虽然原本也极少）
- 配置方式略作修改，和之前的配置会稍微有点不一样，这里需要略作修改
对于没有历史包袱的项目，我个人非常推荐Vite8，这一手打包构建的速度真的很快。
AutoImport自动引入
自动导入这个工具是为了解决vue3的项目中，同文件内需要手动引入，代码书写繁琐的问题。
每次在页面内，你需要手动引入ref，reactive，引入一堆vue的基础函数，同时还得手动引入一堆组合式函数。这样的开发体验，写不了几次页面，相信我，你会变得极为烦躁。
在此之前，若依的前端用的是proxy代理，这种方式还是vue2时代的都挂在this上的思维，虽然也没错，但是用起来真的很丑陋。
用AutoImport之后，就省了太多事了，AutoImport会将那些需要手动引入的东西都自己挂上，不需要你手动引入了。
TypeScript重构
TS在前端的使用，我直到如今也还是有点抵触的，我自己使用过后也是觉得不错，尤其是在Nest后端项目中。
但在前端项目中的使用，我相对的来说较为克制的。
这段我说的会啰嗦一点，因为我得先说明白我具体要用TS在项目中解决的问题，然后是我需要根据我实际遇到的问题来对症下药。
诚然，TS确实有很多优势，我根据自己的开发体验，可以说出最优秀的两点。
- 优秀的代码提示，让开发人员在开发中不用费事去翻查文档和方法源文件，使用的时候节省了很多查看时间
- VITE对TS的支持，让项目更快更方便，通过新版的构建方式，让项目冷启动和打包更快，这个快是肉眼可见的感受到的
但在实际开发过程中，在AI还没有非常盛行的时代，TS引出来的痛点还是有的，我可以结合我实际开发中遇到的体验，简单说一下。
- TS的类型提示书写占用时间，大工程里可以通过人员责任分割来解决，可以刷熟练度来解决，但不能否认的一点，这就是为了省读代码的时间而增加了写代码的时间，客观上还是力大砖飞的加人力来解决的。
- TS如何应对需求变动，频繁变动的项目需求会让你写TS的心力被消磨的一干二净，你想写一套清晰好用的类型检测，让方法调用变得优雅，但频繁变动的需求和工期让你不得不变成AnyScript，最后只是让代码变成了多了很多any的JS，项目代码阅读困难的问题依然没有解决。
在23年，TS还是社区宠儿的时候，所有人针对上边的问题就是一个答案：菜就多练。
所有的回答都指向一点，你没用好那是你的问题，从来不限定边界，不说具体场景，不说在什么时候用，不说怎么用怎么解决，你只要用就会好起来的。怎样的工程化体验会变好？不说，你要怎样在项目中应用TS为工程开发提速？不说，藏着。
反正最后所有的回答都最后转向了一句话：菜就多练，怎么练？不说，就是菜就多练，不会TS就是跟不上时代。
一般遇到这样的回答，那基本上就没法交流了，这明显就是犯了软件开发中银弹理论错误问题，把TS当做能解决一切问题的“银弹”了。
以前我没法回应这种问题，因为我开发的TS项目不多，但是我明显的感觉到TS在公司开发的前端项目中拉屎太多，团队的工程化体验极差。
这种问题在急着赶项目的时候尤为明显，TS不仅没有节约工时，反而增加了审查和排错的工时。
这固然有开发人员开发能力的问题，但作为工程师，你是要解决问题的人，不是制造问题的人。
是否取用TS，一旦确定选型之后，你会遇到如下的一些问题：
- 我写类型检测的意义是为了什么？是为了解决什么痛点？我的项目中真的有这个痛点吗？这个痛点值得我用这个人力成本去覆盖吗？
- 到底要在什么地方使用TS类型检测？hooks？接口？utils工具类？
- 全面TS化，是否意味着项目中的所有方法都要用TS认真写一遍所有的方法，让每个方法的引用都卡的很死？
而在现在这个AI的时代，我通过这两个月的在AI项目中的辅助开发，我想我大概可以回答这个问题。
- 使用TS的意义是为了在方法调用的时候更方便阅读代码，前端代码提示不充分这点，通过使用TS可以解决。
- 使用TS通过现代化的打包工具，能让项目冷启动更快，打包更快
- 项目中真的有代码阅读这个痛点，React项目中的hooks和Vue3项目中组合式函数一旦写多了，都会面临读代码麻烦的问题。
- 人力成本被AI填上了，你只需要简单做做TS的类型体操，了解一下TS是怎么用的，剩下的脏活交给AI去做就可以
- TS类型检测一般用在稳定的工具类方法，比如utils和hooks，如果不涉及需求不稳定的业务，我非常推荐TS。
- 全面TS化之后，不一定要全面强检测，尤其是接口这一类涉及业务的。接口这东西，一般都不会很稳定，如果后端能生成一个不错的文档，那就没必要上强检测，这种上检测无非就是给后端擦屁股。
- NodeJS写的服务端项目，如果你不用TS，我会用拳头打死你，用咏春。
这是我基于个人的小项目的思考，TS不全面铺开检测这点，不适用于大项目，大项目多数是用人力去解决成本问题。
另外，历史包袱很重的项目也不推荐用TS，因为TS重构之后的出现的问题，相对于耗费的人力成本来讲，这不是一笔划算的账目。