企业官网建设流程全解析

之前特别讨厌规范类的东西，觉得这些东西没用。但是在做过一定项目回过来看，发现是有价值的。

其实不管是否察觉到，日常开发中也一直在使用规范，例如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()}

静态化：

privatestaticRandomrandom=newRandom();publicvoidtest(){random.nextBoolean();}

接口路径规范(重)

/interface # 对外接口
/api # 界面功能
/h5 # app端
/api/test # 用于自测的功能，/test的位置看着来就行，能明确区分出来是测试接口即可 重

功能位置规范

例如接口controller放到interface包下，这样一目了然，在统计有几个接口时也很方便。

建议：
接口路径和功能位置结合使用，这样更清楚。

实际确实踩过这个坑，一个功能，对外接口在用，web端在用，h5端也在用，到时候梳理的时候理都理不清楚。

建议接口路径规范和功能位置规范结合使用，就比较整齐了。

为什么不推荐使用行尾注释

1、重构时注释不能同步更新。
2、行尾空间太小，写不了多少注释，要么太少，要么换行，体验都不好。
3、无效注释 # 简单说就是废话注释，一眼就看的懂的代码不用加注释，如果复杂度不高的代码还要加注释可以考虑优化代码而不是加注释
4、代码审查时行尾注释容易被忽略，容易只关注到功能代码而忽视注释。

如何让代码强大

老鸟必备，兼容性是很重要的一点。
例如：
比较两个的值是否相等。
a 是Long
b 是String

错误写法(当b为空时报错)；if(a.equals(Long.parseLong(b))){}推荐写法(自带判空逻辑)：if(Objects.equals(a,b)){}

这种写法更可控，否则到处埋坑。

兼容性

复杂业务时弄清步骤?

需求很复杂，数据多且一堆校验，代码写起来乱糟糟。

这确实是个问题，一堆代码谁看谁复杂。后来解决方案也很简单，步骤梳理清楚，分为几大块。

1、查询基础数据并组装(含校验)
2、动态拼接业务数据
3、调用第三方接口

这样就很清楚了，哪一步出了问题都很好排查。

这让我想起冷了大模型训练中，如何快速定位问题?
通过架构和机制来解决是最好的方案。

代码扫描

以前总认为代码扫描是多余的，后来遇到过一些事情，看法逐渐有了改观。

import导入多余的包# 建议还是去掉好，清爽
发现逻辑错误# 例如字段赋错值，不得不服，这还真时个bug，扫描的时候还没修复，后来我自己发现了修掉了，所以印象深刻

也就是说，代码扫描不但能使代码更规范，还兼具发现逻辑错误的能力，越来越强了，现在的代码扫描可信度超过了90%，正向收益还是蛮高的。