回味下自己几年前写的 “酱香代码”
大家好，我是鲏。
从酱香拿铁、酱香巧克力、再到酱香大床，最近茅台真的是一步步刷新了大家的认知。
但我若掏出自己几年前的 “酱香代码”，阁下如何应对？！
还记得我在几年前直播带大家开发过一个表情包网站，网站名叫 “爸爸”、域名是 father.cool：
当时这个网站用户未万，就中道崩殂了，主要的原因是流量费、以及图片内容安全问题，后面我也就不再维护了，但是把代码完全开源给了大家。
开源地址：https://github.com/liyupi/father
最近是在整理自己的原创文章时，又发现了这个项目，所以决定再翻出来看看代码。
俗话说，检验一个程序员进步的最好方式，就是让他去评价自己之前写过的代码。
如果想吐槽 “这烂代码谁写的？！” 那么恭喜你，有进步了！??
那接下来跟着鱼皮一起来看看，当年直播的时候写的烂代码吧，相信很多同学也都写过。
前端
先把前端项目运行起来，给大家看看效果。
打开依赖文件，发现这个项目我竟然用的是 Vue 3！
几年前做这个项目的时候，应该是 Vue 3 刚开始流行，所以我用了 Vue 3 来尝个鲜：
接下来试着运行下前端项目。但很不幸的是，代码保质期有限，用 npm 运行的时候失败了，换了 yarn 依赖管理才成功运行。不得不感慨（吐槽），前端依赖升级的实在是太快了！
项目运行后，长下面这个 ? 样子：
左上角的裂图是由于当时项目 Logo 用的是网络图片，而不是放在本地的，后面这张图片失效了所以无法显示。
像 Logo 这种重要的图片，还是老老实实放在 public 目录下吧。
点击图片后，可以对图片进行编辑，比如添加文字等，制作自己的表情包：
不运行后端也能使用，效果还是不错的：
后端
重点看下后端的代码。
先看 pom.xml 依赖文件，几年前项目用的就已经是 Spring Boot 2.5 了，到现在 Spring Boot 2 还是主流，而且会持续很长一段时间。
依赖文件中引入了 Apache 的 httpclient，用来发送 Http 请求的工具包。但是这个库其实是有坑的，所以后面我很少用这个包了，基本上会用 Hutool 工具库来代替。
来看看项目结构，大多数类名还是比较规范的，见名知意。除了那个 MyConstant 常量类。。。
当时估计是偷懒了，就随便起了个名字。定义常量时最好还是分个类，比如把用户相关的常量放在 UserConstant 下。
打开一个 Controller，在类名上有一行长长的 @CrossOrigin 注解，用来定义允许哪些域名跨域：
其实不太推荐使用这种在每个类上打注解的方式实现跨域，虽然方便，但是不利于后期的修改和维护，因为每次要改很多类。
大多数情况下，对于同一个后端服务提供的接口，应用的跨域规则是一致的。
所以后面很多项目我都采用统一的配置类来实现全局的跨域配置了：
再看 Controller 文件内新增表情功能的实现代码，非常的简短，非常的朴实无华。
但其实问题也很大，当时肯定是出于直播、为了快速实现功能才这么写了，上述代码存在至少 3 个问题：
1）直接用了实体类接收请求参数，可能会导致调用方传了一些不允许传递的参数，比如传递 reviewStatus = 1 直接让表情过审
2）未对字段做任何的校验，直接插入到数据库中了
3）没有指定上传用户的 id。即使有些系统不要求登录，也建议传个能够标识用户（或机器）的字段，比如 IP 地址，防止有小人恶意插入大量数据
其实判断对象是否为 null 这行代码也是可以优化的：
可以自己封装一个断言工具类来抛异常，比如下列示例代码：
AssertUtil.assertNotNull(emoji);
再接着看 Controller，在搜索表情接口中，竟然写了老长一段封装 SQL 查询对象的代码：
其实根据对象封装查询对象是一个通用逻辑，可以把它单独提取出来作为一个方法，而不是写在接口类中。Controller 层的代码尽量保证精简，尽量不要写业务逻辑。
再看文件上传功能，到第二行就绷不住了：
上面的代码中，我用当前时间 + 用户上传的原始文件名来拼接新的文件名，当时应该是图省事儿，用这种方式保证文件名不重复。
但其实，这种命名规则，是非常不利于文件维护的！最好使用 业务前缀 + 用户标识 + 日期 等维度来拼接完整的文件路径，便于检索和迁移文件。
再往下看，当时自己还手写了很多工具类，比如下载图片：
现在想想，挺天真的，明明用个工具类（比如 Hutool）一行代码就搞定了。
再往下看，在 resources 目录中有一个 banner.txt 文件，这东西很有意思，可以允许你自定义启动项目时控制台的输出信息。
像我当时用了个字符画生成网站，生成了 Father 单词对应的字符画，这就是属于程序员的浪漫吧
