遇到前后端半分离老项目的速度解决方法
问题提出：
前段时间一个小白给我看他的毕业设计，是github上拉下来的一个巨老项目，叫美食鉴赏系统，然后她看了老半天找不到改的地方，结果我看了之后才发现这是个半分离前后端，也就是前端前台代码是放在后端代码里面，通过tomcat直接跑的，直接改html代码还改不了，因为Tomcat缓存问题。
其文件结构如下：
back和front：
问题解析：
该项目的前端分为前台后台，然后前端前台代码都写在后端back里面，而且都是写的html、css、js文件，当启动后端代码的时候，这部分代码会被tomcat代理跑起来，然后他前端后台代码却又分离了出来，放在front里面，以vue文件存在
然后我本以为这种结构简直乱来，但是我看了资料说这是有历史渊源的，因为早期项目或者小项目，为了快，就直接把前台代码塞后端里，Tomcat 能直接跑，简单粗暴。后来需求变了，后台功能越来越复杂，就开始用 Vue（或者 React）重新独立一套后台前端出来了。但原本的前台页面因为历史包袱，懒得重构，所以就继续留在后端里跑。
解决问题：
最简单的方法是直接把这部分的前端前台代码，也就是bac/src/resources里的front文件全部迁移到前端前台代码的public文件夹下。
然后改掉前台后台切换时的衔接代码即可。找到前台切后台和后台切前台的方法动作改路径就行。
此后，运行前端前台代码只需要访问public/index.html即可。
疑惑：
为什么不进行反编译？这样的话前台代码不也挺不好改的吗？灵活性很差
-
传统 HTML、CSS、JS 是明文资源，严格来说不存在真正意义上的“反编译”。
-
但如果是被 Webpack/Vue/React 打包过的，那代码通常是压缩混淆（丑化、加密过的）
-
即便“反编译”得到 JS 代码，也极难阅读和二次开发，逻辑混乱、可维护性极差。
-
修改压缩后的代码非常痛苦，每改一点都要担心整个应用出错，特别容易出坑。
-
随着项目更新，只要后端重新发一次版本，你之前辛辛苦苦改的全没了
-
长期看，项目的灵活性、扩展性几乎归零，形同废弃