企业官网建设流程全解析

代码能跑，不代表代码容易读。很多代码刚写完的时候觉得没什么问题，可过了几个月，再回头看，就得一行一行去推逻辑。要是当初没留下合适的注释，理解起来就更费劲了。

这种情况在项目里很常见的，功能没有问题，可读性却不高。

下面以一个用户注册的方法为例。它完成的事情其实比较简单：校验输入、检查密码强度、判断邮箱是否已经注册、加密密码，然后保存用户。

但是如果第一眼看到是下面这段代码，我不知道你会作何感想。

publicUserregisterUser(Useruser){if(!validateUserInput(user)){thrownewRuntimeException("u105");}Pattern[]rules={Pattern.compile("[a-z]"),Pattern.compile("[A-Z]"),Pattern.compile("[0-9]"),Pattern.compile("[^a-zA-Z0-9]")};if(user.getPassword().length()>=8&&Arrays.stream(rules).allMatch(r->r.matcher(user.getPassword()).find())){if(userRepository.findByEmail(user.getEmail())!=null){thrownewRuntimeException("u212");}}else{thrownewRuntimeException("u201");}user.setPassword(passwordEncoder.encode(user.getPassword()));returnuserRepository.save(user);}

这段代码问题很多的，比如：

• "u105"、"u212"这些错误码是什么意思，光看代码根本不知道；
• 密码校验逻辑直接写在方法里，一堆正则表达式直接把业务逻辑给扰乱了；
• if-else一层套一层，阅读的时候老是得停顿下来；
• 最后还修改了传进来的user对象，这个是有副作用的。

我们下面一步一步的改进，我用的是java 17。

给错误起一个有意义的名字

代码里最先要处理的，就是这些魔法字符串。

thrownewRuntimeException("u105");

看到"u105"，没人知道发生了什么。

我们可以自定义一个叫BizException的异常类，支持填入错误码和对应的中文描述。

thrownewBizException("InvalidParam","输入不合法");

看到BizException("UserAlreadyExists", "邮箱已被注册")，自然知道是邮箱已经被注册了，这样做不仅更容易读，也更容易维护。

给错误一个有意义的名字，读代码的人就不用去猜了。

把实现细节藏起来

原来的registerUser()方法里，还有一大段密码校验逻辑。

password.length()>=8&&...

每次看到这里，都要重新看一遍正则表达式。

其实，大多数人并不关心密码到底是怎么校验的，他们更关心的是：

这里是不是在校验密码。

所以，把它抽成一个独立的方法。

privatestaticfinalList<Pattern>PASSWORD_RULES=List.of(Pattern.compile("[a-z]"),Pattern.compile("[A-Z]"),Pattern.compile("[0-9]"),Pattern.compile("[^a-zA-Z0-9]"));privatebooleanisPasswordStrong(Stringpassword){returnpassword.length()>=8&&PASSWORD_RULES.stream().allMatch(r->r.matcher(password).find());}

这样以后看到：

isPasswordStrong(password)

就知道这里是在检查密码强度，至于底层到底用了正则、字典还是别的策略，不影响阅读这段业务代码。如果以后密码规则调整，也只需要改一个地方。

让代码按顺序往下读

原来的代码还有一个问题，就是嵌套太深。

密码通过了，再检查邮箱；邮箱没问题，再继续执行。

阅读的时候，思路一直在不同的缩进之间跳来跳去。

Java里比较常见的写法，就是使用「快速失败」，条件不满足，直接返回或者抛异常，不再进入后面的逻辑。

改完之后，整个方法会变成一条直线。

• 先校验输入。
• 再校验密码。
• 然后检查邮箱。
• 最后保存用户。

每一步都是一个独立的业务动作，不需要再跟着if-else一层层往里面看。

不要悄悄修改入参

还有一个容易忽略的问题。

user.setPassword(passwordEncoder.encode(user.getPassword()));

这行代码修改了调用方传进来的对象。调用这个方法的人，很可能并不知道user会在里面被改掉。

Java 17的record比较适合作为这种请求对象。

publicrecordUserRegistrationRequest(Stringusername,Stringemail,Stringpassword){}

record本身就是不可变的，没有setter，也不会在方法里被修改。

这样registerUser()就不用去改请求对象，而是直接创建一个新的User实体。

调用方也不用担心，自己传进去的数据会被悄悄改掉。

小结

改完之后，代码大概是下面这样。

publicUserregisterUser(UserRegistrationRequestrequest){if(!validateUserInput(request)){thrownewBizException("InvalidParam","输入不合法");}if(!isPasswordStrong(request.password())){thrownewBizException("InvalidPassword","需包含大小写字母、数字和特殊字符，且不少于8位");}if(userRepository.findByEmail(request.email())!=null){thrownewBizException("UserAlreadyExists","邮箱已被注册");}returnuserRepository.save(newUser(request.username(),request.email(),passwordEncoder.encode(request.password())));}

代码改造完毕后，就清晰很多了：校验输入、校验密码、检查邮箱、保存用户。阅读的人不需要去猜"u105"是什么意思，也不用盯着一堆正则表达式研究密码规则，因为这些实现细节已经被隐藏到了更合适的地方。

提示代码清晰度，是控制复杂度其中一种非常好的方式。