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

代码能跑不代表代码容易读。很多代码刚写完的时候觉得没什么问题可过了几个月再回头看就得一行一行去推逻辑。要是当初没留下合适的注释理解起来就更费劲了。这种情况在项目里很常见的功能没有问题可读性却不高。下面以一个用户注册的方法为例。它完成的事情其实比较简单校验输入、检查密码强度、判断邮箱是否已经注册、加密密码然后保存用户。但是如果第一眼看到是下面这段代码我不知道你会作何感想。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()8Arrays.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...每次看到这里都要重新看一遍正则表达式。其实大多数人并不关心密码到底是怎么校验的他们更关心的是这里是不是在校验密码。所以把它抽成一个独立的方法。privatestaticfinalListPatternPASSWORD_RULESList.of(Pattern.compile([a-z]),Pattern.compile([A-Z]),Pattern.compile([0-9]),Pattern.compile([^a-zA-Z0-9]));privatebooleanisPasswordStrong(Stringpassword){returnpassword.length()8PASSWORD_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是什么意思也不用盯着一堆正则表达式研究密码规则因为这些实现细节已经被隐藏到了更合适的地方。提示代码清晰度是控制复杂度其中一种非常好的方式。