- 06 3月, 2023 2 次提交
-
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
1.MySQL数据库>建表规约>第9条: 【强制】表必备三字段:id,create_time,update_time。 说明:其中 id 必为主键,类型为 bigint unsigned、单表时自增、步长为 1。create_time,update_time 的类型均为datetime 类型,如果要记录时区信息,那么类型设置为 timestamp。 个人理解:简化列名的目的是为了后续能抽取更多公共能力 2.MySQL数据库>SQL语句>第10条: 【推荐】SQL 语句中表的别名前加 as,并且以 t1、t2、t3、...的顺序依次命名。 说明: 1)别名可以是表的简称,或者是依照表在 SQL 语句中出现的顺序,以 t1、t2、t3 的方式命名。 2)别名前加 as 使别名更容易识别。 正例:select t1.name from first_table as t1 , second_table as t2 where t1.id = t2.id;
-
- 05 3月, 2023 6 次提交
-
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
1.编程规约>前后端规约>第6条: 【强制】对于需要使用超大整数的场景,服务端一律使用 String 字符串类型返回,禁止使用 Long 类型。 说明:Java 服务端如果直接返回 Long 整型数据给前端,Javascript 会自动转换为 Number 类型(注:此类型为双精度浮点数,表示原理与取值范围等同于 Java 中的 Double)。Long 类型能表示的最大值是 263-1,在取值范围之内,超过 253(9007199254740992)的数值转化为Javascript 的 Number 时,有些数值会产生精度损失。 扩展说明,在 Long 取值范围内,任何 2 的指数次的整数都是绝对不会存在精度损失的,所以说精度损失是一个概率问题。若浮点数尾数位与指数位空间不限,则可以精确表示任何整数,但很不幸,双精度浮点数的尾数位只有 52 位。 反例:通常在订单号或交易号大于等于 16 位,大概率会出现前后端订单数据不一致的情况。比如,后端传输的 "orderId":362909601374617692,前端拿到的值却是:362909601374617660
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
成员变量有时候会被称为 Field 有时候会被称为 Property,它们的区别如下: 1.Field:Field 是 Java 反射中描述类的属性信息的类。成员变量(Instance Variable)就是定义的字段(Field),例如 private String name;。Field 可以获取当前对象的成员变量的类型,对成员变量重新设值等。使用 Field 可以直接操作类的属性,不需要通过 getter 和 setter 方法,但是需要了解反射机制。 2.Property:Property 是成员变量的 getter 和 setter 方法。例如,public String getName() { return name; } 和 public void setName(String name) { this.name = name; } 分别是获取和设置 MyField 类中的实例变量 name 的 getter 和 setter 方法。使用 Property 可以在类的外部访问和修改类的属性,但是需要注意访问权限和数据类型的正确性。 综上所述,Field 和 Property 都可以用来表示 Java 类中的成员变量,选择哪种方式取决于具体的应用场景和需求。如果需要直接操作类的属性,可以使用 Field;如果需要在类的外部访问和修改类的属性,可以使用 Property。 个人理解:从 MyBatis 的映射角度来说,column 表示数据库表列/字段,property 表示 Java 对象属性/字段,所以此前在涉及到 MyBatis 操作时,尽可能多的用了 Property 而不是 Field。但除了 MyBatis 之外还有很多地方也需要用到成员变量,与其纠结 Field 还是 Property,那就用 Field,简单粗暴一点。
-
由 查尔斯-BUG万象集 提交于
1.异常日志>日志规约>第2条: 【强制】日志文件至少保存 15 天,因为有些异常具备以“周”为频次发生的特点。对于当天日志,以“应用名.log”来保存,保存在/{统一目录}/{应用名}/logs/目录下,过往日志格式为:{logname}.log.{保存日期},日期格式:yyyy-MM-dd 正例:以 mppserver 应用为例,日志保存/home/admin/mppserver/logs/mppserver.log,历史日志名称为 mppserver.log.2021-11-28 2.异常日志>日志规约>第3条: 【强制】根据国家法律,网络运行状态、网络安全事件、个人敏感信息操作等相关记录,留存的日志不少于六个月,并且进行网络多机备份。 3.异常日志>日志规约>第9条: 【强制】异常信息应该包括两类信息:案发现场信息和异常堆栈信息。如果不处理,那么通过关键字throws 往上抛出。 正例:logger.error("inputParams: {} and errorMessage: {}", 各类参数或者对象 toString(), e.getMessage(), e); 4.异常日志>日志规约>第12条: 【推荐】可以使用 warn 日志级别来记录用户输入参数错误的情况,避免用户投诉时,无所适从。如非必要,请不要在此场景打出 error 级别,避免频繁报警。 说明:注意日志输出的级别,error 级别只记录系统逻辑出错、异常或者重要的错误信息。
-
- 04 3月, 2023 7 次提交
-
-
由 查尔斯-BUG万象集 提交于
1.编程规约>命名风格>第14条: 【推荐】在常量与变量命名时,表示类型的名词放在词尾,以提升辨识度。 正例:startTime / workQueue / nameList / TERMINATED_THREAD_COUNT 反例:startedAt / QueueOfWork / listName / COUNT_TERMINATED_THREAD 2.编程规约>命名风格>第19条: 【参考】各层命名规约: A)Service / DAO 层方法命名规约: 1)获取单个对象的方法用 get 做前缀。 2)获取多个对象的方法用 list 做前缀,复数结尾,如:listObjects 3)获取统计值的方法用 count 做前缀。 4)插入的方法用 save / insert 做前缀。 5)删除的方法用 remove / delete 做前缀。 6)修改的方法用 update 做前缀。 个人理解及应用
🔥 : 1)在变量命名方面: a)方法体内局部变量,命名时表示类型的名词放在词尾,以提升辨识度; 正例:nameList、nameArr。 b)方法声明上参数(局部变量),命名时尽量采用复数形式,以和方法名保持一致; 正例:List<String> listNameByIds(List<Long> ids); c)成员变量,命名时尽量采用复数形式。 2)在方法命名方面: a)CRUD 类方法可以简化命名; 正例:UserService:page、list、add、update、delete...; 说明:UserService 是围绕 User 为核心的业务接口,简化命名的方法也很容易理解操作的是什么。 b)其他方法,查询信息名词采用单数(与其纠结单数、复数,那就用单数,简单粗暴一点),以上述第2条要求为命名前缀。 正例:RoleService:listNameByIds(根据 ID 查询名称列表) RoleService:listRoleCodeByUserId(根据用户 ID 查询角色编码列表) UserRoleService:listRoleIdByUserId(根据用户 ID 查询角色 ID 列表) UserService:getByUsername(根据用户名查询用户) -
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
1.编程规约>常量定义>第1条: 【强制】不允许任何魔法值(即未经预先定义的常量)直接出现在代码中。
-
由 查尔斯-BUG万象集 提交于
1.编程规约>并发处理>第6条: 【强制】必须回收自定义的 ThreadLocal 变量记录的当前线程的值,尤其在线程池场景下,线程经常会 被复用,如果不清理自定义的 ThreadLocal 变量,可能会影响后续业务逻辑和造成内存泄露等问题。 尽量在代码中使用 try-finally 块进行回收。
-
由 查尔斯-BUG万象集 提交于
1.编程规约>OOP规约>第20条: 【推荐】当一个类有多个构造方法,或者多个同名方法,这些方法应该按顺序放置在一起,便于阅读, 此条规则优先于下一条。 2.编程规约>OOP规约>第21条: 【推荐】类内方法定义的顺序依次是:公有方法或保护方法 > 私有方法 > getter / setter 方法。 说明:公有方法是类的调用者和维护者最关心的方法,首屏展示最好;保护方法虽然只是子类关心,也可能是“模板设 计模式”下的核心方法;而私有方法外部一般不需要特别关心,是一个黑盒实现;因为承载的信息价值较低,所有 Service 和 DAO 的 getter / setter 方法放在类体最后。 3.编程规约>OOP规约>第26条: 【推荐】类成员与方法访问控制从严: 1)如果不允许外部直接通过 new 来创建对象,那么构造方法必须是 private。 2)工具类不允许有 public 或 default 构造方法。 3)类非 static 成员变量并且与子类共享,必须是 protected。 4)类非 static 成员变量并且仅在本类使用,必须是 private。 5)类 static 成员变量如果仅在本类使用,必须是 private。 6)若是 static 成员变量,考虑是否为 final。 7)类成员方法只供类内部调用,必须是 private。 8)类成员方法只对继承类公开,那么限制为 protected。 说明:任何类、方法、参数、变量,严控访问范围。过于宽泛的访问范围,不利于模块解耦。思考:如果是一个 private 的方法,想删除就删除,可是一个 public 的 service 成员方法或成员变量,删除一下,不得手心冒点汗吗? 变量像自己的小孩,尽量在自己的视线内,变量作用域太大,无限制的到处跑,那么你会担心的。
-
- 03 3月, 2023 3 次提交
-
-
由 查尔斯-BUG万象集 提交于
1.编程规约>集合处理>第7条:(个人理解:emptyList() 固然可以减少资源浪费,但未来由于不确定的需求变更,一旦增删元素必然会引发异常) 【强制】Collections 类返回的对象,如:emptyList() / singletonList() 等都是 immutable list,不可 对其进行添加或者删除元素的操作。 反例:如果查询无结果,返回 Collections.emptyList() 空集合对象,调用方一旦在返回的集合中进行了添加元素的操 作,就会触发 UnsupportedOperationException 异常。 2.编程规约>集合处理>第17条: 【推荐】集合初始化时,指定集合初始值大小。 说明:HashMap 使用构造方法 HashMap(int initialCapacity) 进行初始化时,如果暂时无法确定集合大小,那么指 定默认值(16)即可。 正例:initialCapacity = (需要存储的元素个数 / 负载因子) + 1。注意负载因子(即 loaderfactor)默认为 0.75,如果 暂时无法确定初始值大小,请设置为 16(即默认值)。 反例:HashMap 需要放置 1024 个元素,由于没有设置容量初始大小,随着元素增加而被迫不断扩容,resize() 方法 总共会调用 8 次,反复重建哈希表和数据迁移。当放置的集合元素个数达千万级时会影响程序性能。
-
由 查尔斯-BUG万象集 提交于
1.编程规约>OOP规约>第12条: 【强制】禁止使用构造方法 BigDecimal(double) 的方式把 double 值转化为 BigDecimal 对象。 说明:BigDecimal(double) 存在精度损失风险,在精确计算或值比较的场景中可能会导致业务逻辑异常。 如:BigDecimal g = new BigDecimal(0.1F);实际的存储值为:0.100000001490116119384765625 正例:优先推荐入参为 String 的构造方法,或使用 BigDecimal 的 valueOf 方法,此方法内部其实执行了 Double 的 toString,而 Double 的 toString 按 double 的实际能表达的精度对尾数进行了截断。 BigDecimal recommend1 = new BigDecimal("0.1"); BigDecimal recommend2 = BigDecimal.valueOf(0.1); 2.编程规约>OOP规约>第19条: 【推荐】使用索引访问用 String 的 split 方法得到的数组时,需做最后一个分隔符后有无内容的检查, 否则会有抛 IndexOutOfBoundsException 的风险。 说明: String str = "a,b,c,,"; String[] ary = str.split(","); // 预期大于 3,结果等于 3 System.out.println(ary.length);
-
由 查尔斯-BUG万象集 提交于
1.编程规约>常量定义>第4条: 【推荐】不要使用一个常量类维护所有常量,要按常量功能进行归类,分开维护。 说明:大而全的常量类,杂乱无章,使用查找功能才能定位到要修改的常量,不利于理解,也不利于维护。 正例:缓存相关常量放在类 CacheConsts 下;系统配置相关常量放在类 SystemConfigConsts 下。 2.编程规约>常量定义>第5条: 【推荐】常量的复用层次有五层:跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常 量、类内共享常量。 1)跨应用共享常量:放置在二方库中,通常是 client.jar 中的 constant 目录下。 2)应用内共享常量:放置在一方库中,通常是子模块中的 constant 目录下。 反例:易懂常量也要统一定义成应用内共享常量,两个程序员在两个类中分别定义了表示“是”的常量: 类 A 中:public static final String YES = "yes"; 类 B 中:public static final String YES = "y"; A.YES.equals(B.YES),预期是 true,但实际返回为 false,导致线上问题。 3)子工程内部共享常量:即在当前子工程的 constant 目录下。 4)包内共享常量:即在当前包下单独的 constant 目录下。 5)类内共享常量:直接在类内部 private static final 定义。
-
- 02 3月, 2023 1 次提交
-
-
由 查尔斯-BUG万象集 提交于
1.后端 API 注解鉴权使用方式:@SaCheckPermission("system:user:add") 2.前端全局指令函数使用方式:v-permission="['system:user:add']" 3.前端权限判断函数使用方式:checkPermission(['system:user:add'])
-
- 01 3月, 2023 2 次提交
-
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
-
- 27 2月, 2023 3 次提交
-
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
1.基于 Hutool TreeUtil 重构查询树列表相关 API 2.抽取查询树列表 API 到后端 CRUD 公共组件中,大大简化部门管理和菜单管理部分代码
-
- 26 2月, 2023 4 次提交
-
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
-
- 25 2月, 2023 2 次提交
-
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
-
- 24 2月, 2023 1 次提交
-
-
由 查尔斯-BUG万象集 提交于
1.新增 LabelValueVO 通用字典数据结构
-
- 23 2月, 2023 1 次提交
-
-
由 查尔斯-BUG万象集 提交于
-
- 22 2月, 2023 1 次提交
-
-
由 查尔斯-BUG万象集 提交于
-
- 20 2月, 2023 1 次提交
-
-
由 查尔斯-BUG万象集 提交于
1. 使用抽屉代替对话框 2. 优化数据权限权限范围存储,新增角色和部门关联表 3. 新增角色和菜单关联表 4. 部分细节优化
-
- 16 2月, 2023 4 次提交
-
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
-
由 查尔斯-BUG万象集 提交于
-
- 15 2月, 2023 1 次提交
-
-
由 查尔斯-BUG万象集 提交于
-
- 14 2月, 2023 1 次提交
-
-
由 查尔斯-BUG万象集 提交于
1. 调整菜单排序 2. 优化部分菜单图标 3. 新增菜单栏手风琴配置,默认生效
-