阿里规约常量定义

【强制】不允许任何魔法值（即未经定义的常量）直接出现在代码中。

反例：String key = "Id#taobao_" + tradeId;       cache.put(key, value);
理解：我们代码中对于一些常量前缀，就要预先在枚举类中定义好再使用，避免出现魔法值。

【强制】long 或者 Long 初始赋值时，使用大写的 L，不能是小写的 l，小写容易跟数字 1 混 淆，造成误解。

说明：Long a = 2l; 写的是数字的 21，还是 Long 型的 2? 
理解：这个道理明显。

【推荐】不要使用一个常量类维护所有常量，按常量功能进行归类，分开维护。 说明：大而全的常量类，非得使用查找功能才能定位到修改的常量，不利于理解和维护。

正例：缓存相关常量放在类 CacheConsts 下；系统配置相关常量放在类 ConfigConsts 下。
理解：可以按功能模块划分常量归类。一个功能模块下一个常量类。尽量让功能自闭包，标准是一个小模块拷贝出去直接就能用，而不是缺这缺那的，是不是很多时候拷贝了一套类，运行时候发现不能用，缺常量，把常量类拷贝过来，发现常量类中有很多不相关的常量，还得清理。
     常量类（final修饰不可被继承，定义一个私有化构造函数避免实例化该类）：
     public final class Constants {
        private Constants(){
        } 
        public static final String URL = "http://baidu.com/";
  }

【推荐】常量的复用层次有五层：跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常量、类内共享常量。

1） 跨应用共享常量：放置在二方库中，通常是 client.jar 中的 constant 目录下。  
2） 应用内共享常量：放置在一方库中，通常是 modules 中的 constant 目录下。   

反例：易懂变量也要统一定义成应用内共享常量，两位工程师在两个类中分别定义了表示 “是”的变量：
      类 A 中：public static final String YES = "yes";   
  类 B 中：public static final String YES = "y";    
  A.YES.equals(B.YES)，预期是 true，但实际返回为 false，导致线上问题
3） 子工程内部共享常量：即在当前子工程的 constant 目录下。  
4） 包内共享常量：即在当前包下单独的 constant 目录下。
5） 类内共享常量：直接在类内部 private static final 定义。 
理解：一方库指的是本项目中的依赖，二方库指的是公司内部其他项目提供的依赖，三方库指的是其他组织、公司等来自第三方的依赖。

【推荐】如果变量值仅在一个范围内变化，且带有名称之外的延伸属性，定义为枚举类。下面正例中的数字就是延伸信息，表示星期几。

正例：public Enum { MONDAY(1), TUESDAY(2), WEDNESDAY(3), THURSDAY(4), FRIDAY(5), SATURDAY(6), SUNDAY(7);}
理解：枚举值需要定义延伸属性的场景通常是要持久数据库，或者显示在界面上。