（五）改掉这些坏习惯，还怕写不出精简的代码？

鲁迅说：嬉笑怒骂里充满了无奈和妥协。 

小猿说：先生说的不对，在程序员的世界里，编写代码处处充满了无奈和妥协。

Code Review 是一场苦涩但有意思的修行。

（一）改掉这些坏习惯，还怕写不出健壮的代码？

（二）改掉这些坏习惯，还怕写不出优雅的代码？

（三）改掉这些坏习惯，还怕写不出优雅的代码？

（四）改掉这些坏习惯，还怕写不出健壮的代码？

代码修炼的系列分享，书接上篇，本次探讨一下：该如何利用注解写出精简的代码？

1

 编码时：重复的校验，随处可见。 

举个栗子????：

再举个栗子????：

如栗子示意，项目中参数校验随处可见，面对如此简单而又繁琐的工作量，你有何高见？

小猿招式一：七夕，带你生撸一个验证框架

小猿招式二：API参数如何验证？别纠结，拿去用就是

招式一不多说，徒手造轮子而已；重点说说招式二，引用 Hibernate Validator 类库替换参数校验，如下图示意，只需通过注解就轻松实现参数的基本验证。

建议：参数校验直接引用三方的类库实现，例如引用 Hibernate Validator，能让业务代码简化不少，代码 B 格略有提升。

敢问，你会用注解吗？注解还能怎么用？

莫急，容我慢慢讲来。

2

 编码时：注解还可以这么用。  

举个栗子????：

系统要根据上面常量类中的商户号来判断：是否需要进行校验账户信息、是否需要进行通知商户 ... ...

实现方式有很多种，看看项目中采用注解怎么实现的。

首先定义 PayAccInfoValidator 注解，用来标注是否需要校验账户信息。

import java.lang.annotation.*;


@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface PayAccInfoValidator {
    
    boolean verify() default true;
}

然后在商户号属性上加入注解标识。

采用反射+注解，编写验证工具类，主要关注代码中的关注点一、关注点二。

import java.lang.reflect.Field;
import java.util.HashMap;
import java.util.Map;


public class BusinessUtil {


    private static final MerIdConstant MERID_CONSTANT = new MerIdConstant();


    /**
     * 存放要验证支付账户信息的商户号
     */
    public static final Map VERIFY_MERID_MAP = new HashMap();


    static {
        Class clazz = MERID_CONSTANT.getClass();
        for (Field field : clazz.getFields()) {
            // 关注点一
            PayAccInfoValidator validator = field.getAnnotation(PayAccInfoValidator.class);
            if (validator != null) {
                try {
                    // 关注点二
                    VERIFY_MERID_MAP.put(field.get(MERID_CONSTANT).toString(), validator.verify());
                } catch (IllegalAccessException e) {
                }
            }
        }
    }
}

代码不做详细解释，工具类用起来很简单，简易示例如下。

程序输出：

20020：需要进行验证

另外，校验是否需要通知商户该怎么实现呢？其实套路是一样的，照葫芦画瓢而已，拿去先用起来体会体会。

3

寄语写最后

在程序员的世界里，编写代码处处充满了无奈和妥协。不过还是那句话：我等采石之人当心怀大教堂之愿景。

好了，代码修炼的系列分享，本次就谈到这里，一起聊技术、谈业务、喷架构，少走弯路，不踩大坑。会持续输出原创精彩分享，敬请期待！

坚持是一种信仰，在看是一种态度！