文章目录使用equals或时常量在前面优点兼容性代码random变量静态化接口路径规范(重)功能位置规范为什么不推荐使用行尾注释如何让代码强大兼容性复杂业务时弄清步骤?代码扫描之前特别讨厌规范类的东西觉得这些东西没用。但是在做过一定项目回过来看发现是有价值的。其实不管是否察觉到日常开发中也一直在使用规范例如controller是应用层service是服务层命名用驼峰等。使用equals或时常量在前面正确示范if(1.equals(string)0.equals(string2)){System.out.println(yes);}错误示范// 错误的示范if(!StringUtils.isEmpty(string)1.equals(string)!StringUtils.isEmpty(string2)0.equals(string2)){System.out.println(yes);}以上2个例子效果一样但是第二个代码更冗杂丑陋。 如果是变量在前那么第二种也没问题但是常量在前有效的避免了null.equals报错的问题。所以不用加isEmpty判断了。优点1、避免了null.equals报错。2、避免了 写成 。(判断符号 错写成 赋值符号)兼容性代码很多代码都是复制的。 由于历史原因对接系统的大小写不一致。例如 对接系统的返回报文有的是success 有的是SUCCESS。如果要求统一改为大写或小写要协调多方系统。所以还是自己改最方便string.equals(success);兼容为:string.equalsIgnoreCase(success);string.contains(success);兼容为 string.toLowerCase().contains(success);random变量静态化random类的创建是比较耗时的可以初始化一次后续只调用方法。效率会高些。直接用publicvoidtest(){newRandom().nextBoolean()}静态化privatestaticRandomrandomnewRandom();publicvoidtest(){random.nextBoolean();}接口路径规范(重)/interface # 对外接口/api # 界面功能/h5 # app端/api/test # 用于自测的功能/test的位置看着来就行能明确区分出来是测试接口即可 重功能位置规范例如接口controller放到interface包下这样一目了然在统计有几个接口时也很方便。建议接口路径和功能位置结合使用这样更清楚。实际确实踩过这个坑一个功能对外接口在用web端在用h5端也在用到时候梳理的时候理都理不清楚。建议接口路径规范和功能位置规范结合使用就比较整齐了。为什么不推荐使用行尾注释1、重构时注释不能同步更新。2、行尾空间太小写不了多少注释要么太少要么换行体验都不好。3、无效注释 # 简单说就是废话注释一眼就看的懂的代码不用加注释如果复杂度不高的代码还要加注释可以考虑优化代码而不是加注释4、代码审查时行尾注释容易被忽略容易只关注到功能代码而忽视注释。如何让代码强大老鸟必备兼容性是很重要的一点。例如比较两个的值是否相等。a 是Longb 是String错误写法(当b为空时报错)if(a.equals(Long.parseLong(b))){}推荐写法(自带判空逻辑)if(Objects.equals(a,b)){}这种写法更可控否则到处埋坑。兼容性复杂业务时弄清步骤?需求很复杂数据多且一堆校验代码写起来乱糟糟。这确实是个问题一堆代码谁看谁复杂。后来解决方案也很简单步骤梳理清楚分为几大块。1、查询基础数据并组装(含校验)2、动态拼接业务数据3、调用第三方接口这样就很清楚了哪一步出了问题都很好排查。这让我想起冷了大模型训练中如何快速定位问题?通过架构和机制来解决是最好的方案。代码扫描以前总认为代码扫描是多余的后来遇到过一些事情看法逐渐有了改观。import导入多余的包# 建议还是去掉好清爽发现逻辑错误# 例如字段赋错值不得不服这还真时个bug扫描的时候还没修复后来我自己发现了修掉了所以印象深刻也就是说代码扫描不但能使代码更规范还兼具发现逻辑错误的能力越来越强了现在的代码扫描可信度超过了90%正向收益还是蛮高的。