【项目中常见的问题及代码优化】长期更新

1：多重IF嵌套

解决方案：
1：分组拆分
2：策略模式
3：优化逻辑（备选）

2：SQL语句常见误区

绝对不能SELECT * ！
绝对不能SELECT * ！
绝对不能SELECT * ！
重要的话说三遍！！！
SELECT相当于执行了全表扫描！！！
效率极差！！！

解决方案：
具体到需要返回的字段

2024/2/2 14/12加更一个

不得不说，我们项目里真的好喜欢用select *

3：配置误区（个人的见解）

解决方案：
仔细阅读nacos

我个人以为：
nacos的作用不是为了这里一套配置那里一套配置
也不是为了弥补，覆盖本地配置的错误
而是：
因为本地配置繁杂冗余
简化本地配置，也为了界面清爽干净
从而将部分配置放置到远程
即实现了服务之间的注册发现，也保持了本地配置的优雅

本地配置nacos，
繁杂的放置到远程，
本地远程是一个和谐统一的整体

4：for循环查询

典型：

1：一个for循环，里面包裹一个查询语句。

问题：

多次建立连接，增加不必要的性能开销。

看起来不优雅，（数据量大）用起来不舒服

解决：

1：基于SQL语句完成整套查询

2：基于Mybaties resultMap 的一对一，一对多完成查询

5：魔法变量

魔法变量的体现（什么是魔法变量？）：
代码中直接以数字，文字等形式出现的"代码"

模范变量的危害：
1：不易阅读。
作者及业务熟悉的人，可能看到之后容易理解，但如果是新人，就需要大量查询数据库等资料，不够友好。
2：不易修改。
魔法变量，是定义好的一个个"1,2,3",当我们需要修改代码时，就需要手动一个个去寻找，修改。而且容易留下隐患。

魔法变量的解决（常量）：
1：常量类
定义常量类，对常用的内容进行封装
2：实体类
需要定义“1，2”的字段下，定义常量。需要使用时，该字段的常量
3：实现类
实现类上开辟一块空间用于存放常量，当需要大量修改时，统一修改这一块空间的内容

6：虚假配置

弊端：容易导致新人出现问题

优化方案：改正确

7：建表不建ID（主键）

弊端：如果出现重复数据不易辨别。就比如我，一度以为是代码出现了bug

优化方案：自己建表一定要加，别人得就别管了，牵扯太多，还又不是自己写的