现场重构一段代码，展示什么叫「好代码，都在表达自己的意图」

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

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

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

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

Java 复制代码

public User registerUser(User user) {
    if (!validateUserInput(user)) {
        throw new RuntimeException("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) {
            throw new RuntimeException("u212");
        }
    } else {
        throw new RuntimeException("u201");
    }
    user.setPassword(passwordEncoder.encode(user.getPassword()));
    return userRepository.save(user);
}

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

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

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

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

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

Java 复制代码

throw new RuntimeException("u105");

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

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

Java 复制代码

throw new BizException("InvalidParam", "输入不合法");

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

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

把实现细节藏起来

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

Java 复制代码

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

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

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

这里是不是在校验密码。

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

Java 复制代码

private static final List<Pattern> PASSWORD_RULES = List.of(
    Pattern.compile("[a-z]"),
    Pattern.compile("[A-Z]"),
    Pattern.compile("[0-9]"),
    Pattern.compile("[^a-zA-Z0-9]")
);

private boolean isPasswordStrong(String password) {
    return password.length() >= 8
            && PASSWORD_RULES.stream().allMatch(r -> r.matcher(password).find());
}

这样以后看到：

Java 复制代码

isPasswordStrong(password)

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

让代码按顺序往下读

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

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

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

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

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

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

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

不要悄悄修改入参

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

Java 复制代码

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

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

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

Java 复制代码

public record UserRegistrationRequest(
        String username,
        String email,
        String password
) {}

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

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

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

小结

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

Java 复制代码

public User registerUser(UserRegistrationRequest request) {
    if (!validateUserInput(request)) {
        throw new BizException("InvalidParam", "输入不合法");
    }

    if (!isPasswordStrong(request.password())) {
        throw new BizException("InvalidPassword",
                "需包含大小写字母、数字和特殊字符，且不少于8位");
    }

    if (userRepository.findByEmail(request.email()) != null) {
        throw new BizException("UserAlreadyExists", "邮箱已被注册");
    }

    return userRepository.save(
            new User(
                    request.username(),
                    request.email(),
                    passwordEncoder.encode(request.password())));
}

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

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