java开发手册 v1.6.0

阿里巴巴技术团队于2020年04月22日发布《Java开发手册v1.6.0-泰山版》。这套Java统一规范标准将有助于提高行业编码规范化水平，帮助行业人员提高开发质量和效率、大大降低代码维护成本。

java开发手册 v1.6.0

• 编程规约
  • 命名风格
    • 强制
      • 1.【强制】代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
        • 反例：_name/__name/$name/name_/name$/name__
      • 2.【强制】所有编程相关的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。
        • 说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，纯拼音命名方式更要避免采用。 正例：ali/alibaba /taobao / cainiao/ aliyun/ youku / hangzhou 等国际通用的名称，可视同英文。 反例：DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量= 3
      • 3.【强制】类名使用UpperCamelCase风格，但以下情形例外：DO / BO / DTO / VO/ AO/ PO/ UID等。
        • 正例：ForceCode / UserDO / HtmlDTO / XmlService / TcpUdpDeal / TaPromotion 反例：forcecode / UserDo / HTMLDto / XMLService / TCPUDPDeal / TAPromotion
      • 4.【强制】方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格。
        • 正例：localValue / getHttpMessage() / inputUserId
      • 5.【强制】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
        • 正例：MAX_STOCK_COUNT/ CACHE_EXPIRED_TIME 反例：MAX_COUNT/ EXPIRED_TIME
      • 6.【强制】抽象类命名使用Abstract或Base开头；异常类命名使用Exception结尾；测试类命名以它要测试的类的名称开始，以Test结尾。
      • 7.【强制】类型与中括号紧挨相连来表示数组。
        • 正例：定义整形数组int[] arrayDemo; 反例：在main参数中，使用String args[]来定义。
      • 8.【强制】POJO类中的任何布尔类型的变量，都不要加is前缀，否则部分框架解析会引起序列化错误。
        • 说明：在本文MySQL规约中的建表约定第一条，表达是与否的值采用is_xxx的命名方式，所以，需要在<resultMap>设置从is_xxx到xxx的映射关系。 反例：定义为基本数据类型Boolean isDeleted的属性，它的方法也是isDeleted()，框架在反向解析的时候，“误以为”对应的属性名称是deleted，导致属性获取不到，进而抛出异常。
      • 9.【强制】包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
        • 正例：应用工具类包名为com.alibaba.ei.kunlun.aap.util、类名为MessageUtils（此规则参考spring的框架结构）
      • 10.【强制】避免在子父类的成员变量之间、或者不同代码块的局部变量之间采用完全相同的命名，使可读性降低。
        • 说明：子类、父类成员变量名相同，即使是public类型的变量也是能够通过编译，而局部变量在同一方法内的不同代码块中同名也是合法的，但是要避免使用。对于非setter/getter的参数名称也要避免与成员变量名称相同。 反例： 
      • 11.【强制】杜绝完全不规范的缩写，避免望文不知义。
        • 反例：AbstractClass“缩写”命名成AbsClass；condition“缩写”命名成condi，此类随意缩写严重降低了代码的可阅读性
    • 推荐
      • 12.【推荐】为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽量完整的单词组合来表达
        • 正例：在JDK中，对某个对象引用的volatile字段进行原子更新的类名为：AtomicReferenceFieldUpdater。反例：常见的方法内变量为int a;的定义方式。
      • 13.【推荐】在常量与变量的命名时，表示类型的名词放在词尾，以提升辨识度。
      • 14.【推荐】如果模块、接口、类、方法使用了设计模式，在命名时需体现出具体模式。说明：将设计模式体现在名字中，有利于阅读者快速理解架构设计理念。
        • 正例： public class OrderFactory; public class LoginProxy; public class ResourceObserver;
      • 15.【推荐】接口类中的方法和属性不要加任何修饰符号（public 也不要加），保持代码的简洁性，并加上有效的Javadoc注释。尽量不要在接口里定义变量，如果一定要定义变量，确定与接口方法相关，并且是整个应用的基础常量。
        • 正例：接口方法签名void commit(); 接口基础常量String COMPANY = "alibaba"; 反例：接口方法定义public abstract void f(); 说明：JDK8中接口允许有默认实现，那么这个default方法，是对所有实现类都有价值的默认实现。
      • 16.接口和实现类的命名有两套规则：
        • 1）【强制】对于Service和DAO类，基于SOA的理念，暴露出来的服务一定是接口，内部的实现类用Impl的后缀与接口区别。
          • 正例：CacheServiceImpl实现CacheService接口。
        • 2）【推荐】如果是形容能力的接口名称，取对应的形容词为接口名（通常是–able的形容词）。
          • 正例：AbstractTranslator实现Translatable接口。
    • 参考
      • 17.【参考】枚举类名带上Enum后缀，枚举成员名称需要全大写，单词间用下划线隔开。
        • 说明：枚举其实就是特殊的常量类，且构造方法被默认强制是私有。正例：枚举名字为ProcessStatusEnum的成员名称：SUCCESS / UNKNOWN_REASON
      • 18.【参考】各层命名规约：
        • A) Service/DAO层方法命名规约
          • 1）获取单个对象的方法用get做前缀。 2）获取多个对象的方法用list做前缀，复数结尾，如：listObjects。 3）获取统计值的方法用count做前缀。 4）插入的方法用save/insert做前缀。 5）删除的方法用remove/delete做前缀。 6）修改的方法用update做前缀。
        • B) 领域模型命名规约
          • 1）数据对象：xxxDO，xxx即为数据表名。 2）数据传输对象：xxxDTO，xxx为业务领域相关的名称。 3）展示对象：xxxVO，xxx一般为网页名称。 4）POJO是DO/DTO/BO/VO的统称，禁止命名成xxxPOJO。
  • 常量定义
  • 代码格式
  • OOP规约
    • 强制
      • 1.【强制】避免通过一个类的对象引用访问此类的静态变量或静态方法，无谓增加编译器解析成本，直接用类名来访问即可。
      • 2.【强制】所有的覆写方法，必须加@Override注解。
      • 3.【强制】相同参数类型，相同业务含义，才可以使用Java的可变参数，避免使用Object。
      • 4.【强制】外部正在调用或者二方库依赖的接口，不允许修改方法签名，避免对接口调用方产生影响。接口过时必须加@Deprecated注解，并清晰地说明采用的新接口或者新服务是什么。
      • 5.【强制】不能使用过时的类或方法。
        • 说明：java.net.URLDecoder 中的方法decode(String encodeStr) 这个方法已经过时，应该使用双参数decode(String source, String encode)。 接口提供方既然明确是过时接口，那么有义务同时提供新的接口；作为调用方来说，有义务去考证过时方法的新实现是什么。
      • 6.【强制】Object的equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals。
        • 正例："test".equals(object); 反例：object.equals("test"); 说明：推荐使用java.util.Objects#equals（JDK7引入的工具类）。
      • 7.【强制】所有整型包装类对象之间值的比较，全部使用equals方法比较。
        • 说明：对于Integer var=?在-128至127之间的赋值，Integer对象是在IntegerCache.cache产生，会复用已有对象，这个区间内的Integer值可以直接使用==进行判断，但是这个区间之外的所有数据，都会在堆上产生，并不会复用已有对象，这是一个大坑，推荐使用equals方法进行判断。
      • 8.【强制】任何货币金额，均以最小货币单位且整型类型来进行存储。
      • 9.【强制】浮点数之间的等值判断，基本数据类型不能用==来比较，包装数据类型不能用equals来判断。
        • 说明：浮点数采用“尾数+阶码”的编码方式，类似于科学计数法的“有效数字+指数”的表示方式。二进制无法精确表示大部分的十进制小数
      • 10.【强制】定义数据对象DO类时，属性类型要与数据库字段类型相匹配。
        • 正例：数据库字段的bigint必须与类属性的Long类型相对应。 反例：某个案例的数据库表id字段定义类型bigint unsigned，实际类对象属性为Integer，随着id越来越大，超过Integer的表示范围而溢出成为负数。
      • 11.【强制】禁止使用构造方法BigDecimal(double)的方式把double值转化为BigDecimal对象。
        • 说明：BigDecimal(double)存在精度损失风险，在精确计算或值比较的场景中可能会导致业务逻辑异常。 如：BigDecimal g = new BigDecimal(0.1f); 实际的存储值为：0.10000000149 正例：优先推荐入参为String的构造方法，或使用BigDecimal的valueOf方法，此方法内部其实执行了Double的toString，而Double的toString按double的实际能表达的精度对尾数进行了截断。 BigDecimalrecommend1=newBigDecimal("0.1"); BigDecimalrecommend2=BigDecimal.valueOf(0.1)
      • 12.关于基本数据类型与包装数据类型的使用标准如下：
        • 说明：POJO类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何NPE问题，或者入库检查，都由使用者来保证。 正例：数据库的查询结果可能是null，因为自动拆箱，用基本数据类型接收有NPE风险。 反例：某业务的交易报表上显示成交总额涨跌情况，即正负x%，x为基本数据类型，调用的RPC服务，调用不成功时，返回的是默认值，页面显示为0%，这是不合理的，应该显示成中划线-。所以包装数据类型的null值，能够表示额外的信息，如：远程调用失败，异常退出。
        • 1）【强制】所有的POJO类属性必须使用包装数据类型。
        • 2）【强制】RPC方法的返回值和参数必须使用包装数据类型。
        • 3）【推荐】所有的局部变量使用基本数据类型。
      • 13.【强制】定义DO/DTO/VO等POJO类时，不要设定任何属性默认值。
        • 反例：POJO类的createTime默认值为new Date()，但是这个属性在数据提取时并没有置入具体值，在更新其它字段时又附带更新了此字段，导致创建时间被修改成当前时间。
      • 14.【强制】序列化类新增属性时，请不要修改serialVersionUID字段，避免反序列失败；如果完全不兼容升级，避免反序列化混乱，那么请修改serialVersionUID值。
        • 说明：注意serialVersionUID不一致会抛出序列化运行时异常。
      • 15.【强制】构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在init方法中。
      • 16.【强制】POJO类必须写toString方法。使用IDE中的工具：source> generate toString时，如果继承了另一个POJO类，注意在前面加一下super.toString。
        • 说明：在方法执行抛出异常时，可以直接调用POJO的toString()方法打印其属性值，便于排查问题。
      • 17.【强制】禁止在POJO类中，同时存在对应属性xxx的isXxx()和getXxx()方法。
    • 推荐
      • 18.【推荐】使用索引访问用String的split方法得到的数组时，需做最后一个分隔符后有无内容的检查，否则会有抛IndexOutOfBoundsException的风险。
        • 说明： String str ="a,b,c,,"; String[]ary =str.split(","); // 预期大于3，结果是3 System.out.println(ary.length);
      • 19.【推荐】当一个类有多个构造方法，或者多个同名方法，这些方法应该按顺序放置在一起，便于阅读，此条规则优先于下一条。
      • 20.【推荐】类内方法定义的顺序依次是：公有方法或保护方法> 私有方法> getter/setter方法。
        • 说明：公有方法是类的调用者和维护者最关心的方法，首屏展示最好；保护方法虽然只是子类关心，也可能是“模板设计模式”下的核心方法；而私有方法外部一般不需要特别关心，是一个黑盒实现；因为承载的信息价值较低，所有Service和DAO的getter/setter方法放在类体最后。
      • 21.【推荐】setter方法中，参数名称与类成员变量名称一致，this.成员名=参数名。在getter/setter方法中，不要增加业务逻辑，增加排查问题的难度。
        • 反例：publicInteger getData () {if(condition){returnthis.data +100;}else{returnthis.data -100;}}
      • 22.【推荐】循环体内，字符串的连接方式，使用StringBuilder的append方法进行扩展。
        • 说明：下例中，反编译出的字节码文件显示每次循环都会new出一个StringBuilder对象，然后进行append操作，最后通过toString方法返回String对象，造成内存资源浪费。 反例：String str ="start";for(inti =0;i <100;i++){str =str +"hello";}
      • 23.【推荐】final可以声明类、成员变量、方法、以及本地变量，下列情况使用final关键字：
      • 24.【推荐】慎用Object的clone方法来拷贝对象。
        • 说明：对象clone方法默认是浅拷贝，若想实现深拷贝需覆写clone方法实现域对象的深度遍历式拷贝。
      • 25.【推荐】类成员与方法访问控制从严：
        • 说明：任何类、方法、参数、变量，严控访问范围。过于宽泛的访问范围，不利于模块解耦。思考：如果是一个private的方法，想删除就删除，可是一个public的service成员方法或成员变量，删除一下，不得手心冒点汗吗？变量像自己的小孩，尽量在自己的视线内，变量作用域太大，无限制的到处跑，那么你会担心的。
        • 1）如果不允许外部直接通过new来创建对象，那么构造方法必须是private。
        • 2）工具类不允许有public或default构造方法。
        • 3）类非static成员变量并且与子类共享，必须是protected
        • 4）类非static成员变量并且仅在本类使用，必须是private。
        • 5）类static成员变量如果仅在本类使用，必须是private。
        • 6）若是static成员变量，考虑是否为final。
        • 7）类成员方法只供类内部调用，必须是private。
        • 8）类成员方法只对继承类公开，那么限制为protected。
  • 日期时间
  • 集合处理
    • 强制
      • 1.【强制】关于hashCode和equals的处理，遵循如下规则：
        • 1）只要重写equals，就必须重写hashCode。 2）因为Set存储的是不重复的对象，依据hashCode和equals进行判断，所以Set存储的对象必须重写这两个方法。 3）如果自定义对象作为Map的键，那么必须覆写hashCode和equals。说明：String因为重写了hashCode和equals方法，所以我们可以愉快地使用String对象作为key来使用。
      • 2.【强制】判断所有集合内部的元素是否为空，使用isEmpty()方法，而不是size()==0的方式。说明：前者的时间复杂度为O(1)，而且可读性更好。
        • 正例：Map<String,Object>map =newHashMap<>(); if(map.isEmpty()){System.out.println("no element in this map.");}
      • 3.【强制】在使用java.util.stream.Collectors类的toMap()方法转为Map集合时，一定要使用含有参数类型为BinaryOperator，参数名为mergeFunction的方法，否则当出现相同key值时会抛出IllegalStateException异常。
        • 说明：参数mergeFunction的作用是当出现key重复时，自定义对value的处理策略。  
      • 4.【强制】在使用java.util.stream.Collectors类的toMap()方法转为Map集合时，一定要注意当value为null时会抛NPE异常。
        • 说明：在java.util.HashMap的merge方法里会进行如下的判断： 
      • 5.【强制】ArrayList的subList结果不可强转成ArrayList，否则会抛出ClassCastException异常：java.util.RandomAccessSubList cannot be cast to java.util.ArrayList。
        • 说明：subList 返回的是ArrayList的内部类SubList，并不是ArrayList而是ArrayList 的一个视图，对于SubList子列表的所有操作最终会反映到原列表上。
      • 6.【强制】使用Map的方法keySet()/values()/entrySet()返回集合对象时，不可以对其进行添加元素操作，否则会抛出UnsupportedOperationException异常。
      • 7.【强制】Collections类返回的对象，如：emptyList()/singletonList()等都是immutable list，不可对其进行添加或者删除元素的操作。
        • 反例：如果查询无结果，返回Collections.emptyList()空集合对象，调用方一旦进行了添加元素的操作，就会触发UnsupportedOperationException异常。
      • 8.【强制】在subList场景中，高度注意对父集合元素的增加或删除，均会导致子列表的遍历、增加、删除产生ConcurrentModificationException异常。
      • 9.【强制】使用集合转数组的方法，必须使用集合的toArray(T[] array)，传入的是类型完全一致、长度为0的空数组。
        • 反例：直接使用toArray无参方法存在问题，此方法返回值只能是Object[]类，若强转其它类型数组将出现ClassCastException错误。  说明：使用toArray带参方法，数组空间大小的length， 1）等于0，动态创建与size相同的数组，性能最好。 2）大于0但小于size，重新创建大小等于size的数组，增加GC负担。 3）等于size，在高并发情况下，数组创建完成之后，size正在变大的情况下，负面影响与2相同。 4）大于size，空间浪费，且在size处插入null值，存在NPE隐患。
      • 10.【强制】在使用Collection接口任何实现类的addAll()方法时，都要对输入的集合参数进行NPE判断。
        • 说明：在ArrayList#addAll方法的第一行代码即Object[] a = c.toArray();其中c为输入集合参数，如果为null，则直接抛出异常。
      • 11.【强制】使用工具类Arrays.asList()把数组转换成集合时，不能使用其修改集合相关的方法，它的add/remove/clear方法会抛出UnsupportedOperationException异常。
        • 说明：asList的返回对象是一个Arrays内部类，并没有实现集合的修改方法。Arrays.asList体现的是适配器模式，只是转换接口，后台的数据仍是数组。  第一种情况：list.add("yangguanbao"); 运行时异常。 第二种情况：str[0]= "changed"; 也会随之修改，反之亦然。
      • 12.【强制】泛型通配符<? extends T>来接收返回的数据，此写法的泛型集合不能使用add方法，而<? superT>不能使用get方法，两者在接口调用赋值的场景中容易出错。
        • 说明：扩展说一下PECS(Producer Extends Consumer Super)原则：第一、频繁往外读取内容的，适合用<? extends T>。第二、经常往里插入的，适合用<? superT>
      • 13.【强制】在无泛型限制定义的集合赋值给泛型限制的集合时，在使用集合元素时，需要进行instanceof判断，避免抛出ClassCastException异常。
        • 说明：毕竟泛型是在JDK5后才出现，考虑到向前兼容，编译器是允许非泛型集合与泛型集合互相赋值。 
      • 14.【强制】不要在foreach循环里进行元素的remove/add操作。remove元素请使用Iterator方式，如果并发操作，需要对Iterator对象加锁。
        • 建议使用stream表达式中的filter来过滤元素  说明：以上代码的执行结果肯定会出乎大家的意料，那么试一下把“1”换成“2”，会是同样的结果吗？
      • 15.【强制】在JDK7版本及以上，Comparator实现类要满足如下三个条件，不然Arrays.sort，Collections.sort会抛IllegalArgumentException异常。
        • 说明：三个条件如下 1）x，y的比较结果和y，x的比较结果相反。 2）x>y，y>z，则x>z。 3）x=y，则x，z比较结果和y，z比较结果相同。 反例：下例中没有处理相等的情况，交换两个对象判断结果并不互反，不符合第一个条件，在实际使用中可能会出现异常。 
    • 推荐
      • 16.【推荐】集合泛型定义时，在JDK7及以上，使用diamond语法或全省略。
        • 说明：菱形泛型，即diamond，直接使用<>来指代前边已经指定的类型。 
      • 17.【推荐】集合初始化时，指定集合初始值大小。
        • 说明：HashMap使用HashMap(int initialCapacity) 初始化，如果暂时无法确定集合大小，那么指定默认值（16）即可。 正例：initialCapacity= (需要存储的元素个数/负载因子) + 1。注意负载因子（即loader factor）默认为0.75，如果暂时无法确定初始值大小，请设置为16（即默认值）。 反例：HashMap需要放置1024个元素，由于没有设置容量初始大小，随着元素不断增加，容量7次被迫扩大，resize需要重建hash表。当放置的集合元素个数达千万级别时，不断扩容会严重影响性能。
      • 18.【推荐】使用entrySet遍历Map类集合KV，而不是keySet方式进行遍历。
        • 说明：keySet其实是遍历了2次，一次是转为Iterator对象，另一次是从hashMap中取出key所对应的value。而entrySet只是遍历了一次就把key和value都放到了entry中，效率更高。如果是JDK8，使用Map.forEach方法。 正例：values()返回的是V值集合，是一个list集合对象；keySet()返回的是K值集合，是一个Set集合对象；entrySet()返回的是K-V值组合集合。
      • 19.【推荐】高度注意Map类集合K/V能不能存储null值的情况，如下表格：
        •  反例：由于HashMap的干扰，很多人认为ConcurrentHashMap是可以置入null值，而事实上，存储null值时会抛出NPE异常。
    • 参考
      • 20.【参考】合理利用好集合的有序性(sort)和稳定性(order)，避免集合的无序性(unsort)和不稳定性(unorder)带来的负面影响。
        • 说明：有序性是指遍历的结果是按某种比较规则依次排列的。稳定性指集合每次遍历的元素次序是一定的。如：ArrayList是order/unsort；HashMap是unorder/unsort；TreeSet是order/sort。
      • 21.【参考】利用Set元素唯一的特性，可以快速对一个集合进行去重操作，避免使用List的contains()进行遍历去重或者判断包含操作。
  • 并发处理
    • 强制
      • 1.【强制】获取单例对象需要保证线程安全，其中的方法也要保证线程安全。
      • 2.【强制】创建线程或线程池时请指定有意义的线程名称，方便出错时回溯。
      • 3.【强制】线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。
      • 4.【强制】线程池不允许使用Executors去创建，而是通过ThreadPoolExecutor的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。
      • 5.【强制】SimpleDateFormat是线程不安全的类，一般不要定义为static变量，如果定义为static，必须加锁，或者使用DateUtils工具类。
      • 6.【强制】必须回收自定义的ThreadLocal变量，尤其在线程池场景下，线程经常会被复用，如果不清理自定义的ThreadLocal变量，可能会影响后续业务逻辑和造成内存泄露等问题。尽量在代理中使用try-finally块进行回收。
      • 7.【强制】高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。
      • 8.【强制】对多个资源、数据库表、对象同时加锁时，需要保持一致的加锁顺序，否则可能会造成死锁。
      • 9.【强制】在使用阻塞等待获取锁的方式中，必须在try代码块之外，并且在加锁方法与try代码块之间没有任何可能抛出异常的方法调用，避免加锁成功后，在finally中无法解锁
      • 10.【强制】在使用尝试机制来获取锁的方式中，进入业务代码块之前，必须先判断当前线程是否持有锁。锁的释放规则与锁的阻塞等待方式相同。
      • 11.【强制】并发修改同一记录时，避免更新丢失，需要加锁。要么在应用层加锁，要么在缓存加锁，要么在数据库层使用乐观锁，使用version作为更新依据。
      • 12.【强制】多线程并行处理定时任务时，Timer运行多个TimeTask时，只要其中之一没有捕获抛出的异常，其它任务便会自动终止运行，使用ScheduledExecutorService则没有这个问题。
    • 推荐
      • 13.【推荐】资金相关的金融敏感信息，使用悲观锁策略。
      • 4.【推荐】使用CountDownLatch进行异步转同步操作，每个线程退出前必须调用countDown方法，线程执行代码注意catch异常，确保countDown方法被执行到，避免主线程无法执行至await方法，直到超时才返回结果。
      • 15.【推荐】避免Random实例被多线程使用，虽然共享该实例是线程安全的，但会因竞争同一seed导致的性能下降。
      • 16.【推荐】通过双重检查锁（double-checkedlocking）（在并发场景下）实现延迟初始化的优化问题隐患(可参考The"Double-CheckedLockingisBroken" Declaration)，推荐解决方案中较为简单一种（适用于JDK5及以上版本），将目标属性声明为volatile型（比如修改helper的属性声明为`private volatile Helper helper = null;`）。
    • 参考
      • 17.【参考】volatile解决多线程内存不可见问题。对于一写多读，是可以解决变量同步问题，但是如果多写，同样无法解决线程安全问题。
      • 18.【参考】HashMap在容量不够进行resize时由于高并发可能出现死链，导致CPU飙升，在开发过程中注意规避此风险。
      • 19.【参考】ThreadLocal对象使用static修饰，ThreadLocal无法解决共享对象的更新问题。说明：这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享此静态变量，也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只要是这个线程内定义的)都可以操控这个变量。
  • 控制语句
  • 注释规约
  • 其他
    • 强制
      • 1.【强制】在使用正则表达式时，利用好其预编译功能，可以有效加快正则匹配速度。
        • 说明：不要在方法体内定义：Pattern pattern = Pattern.compile(“规则”)
      • 2.【强制】避免用Apache Beanutils进行属性的copy。
        • 说明：Apache BeanUtils性能较差，可以使用其他方案比如Spring BeanUtils, Cglib BeanCopier，注意均是浅拷贝。
      • 3.【强制】velocity调用POJO类的属性时，直接使用属性名取值即可，模板引擎会自动按规范调用POJO的getXxx()，如果是boolean基本数据类型变量（boolean命名不需要加is前缀），会自动调用isXxx()方法。
        • 说明：注意如果是Boolean包装类对象，优先调用getXxx()的方法。
      • 4.【强制】后台输送给页面的变量必须加$!{var}——中间的感叹号。
        • 说明：如果var等于null或者不存在，那么${var}会直接显示在页面上。
      • 5.【强制】注意Math.random()这个方法返回是double类型，注意取值的范围0≤x<1（能够取到零值，注意除零异常），如果想获取整数类型的随机数，不要将x放大10的若干倍然后取整，直接使用Random对象的nextInt或者nextLong方法。
    • 推荐
      • 6.【推荐】不要在视图模板中加入任何复杂的逻辑
        • 说明：根据MVC理论，视图的职责是展示，不要抢模型和控制器的活。
      • 7.【推荐】任何数据结构的构造或初始化，都应指定大小，避免数据结构无限增长吃光内存。
      • 8.【推荐】及时清理不再使用的代码段或配置信息。
        • 说明：对于垃圾代码或过时配置，坚决清理干净，避免程序过度臃肿，代码冗余。 正例：对于暂时被注释掉，后续可能恢复使用的代码片断，在注释代码上方，统一规定使用三个斜杠(///)来说明注释掉代码的理由。如： 
• 异常日志
  • 错误码
    • 1.【强制】错误码的制定原则：快速溯源、简单易记、沟通标准化。
      • 说明：错误码想得过于完美和复杂，就像康熙字典中的生僻字一样，用词似乎精准，但是字典不容易随身携带并且简单易懂。 正例：错误码回答的问题是谁的错？错在哪？ 1）错误码必须能够快速知晓错误来源，可快速判断是谁的问题。 2）错误码易于记忆和比对（代码中容易equals）。 3）错误码能够脱离文档和系统平台达到线下轻量化地自由沟通的目的。
    • 2.【强制】错误码不体现版本号和错误等级信息。
  • 异常处理
  • 日志规约
• 单元测试
  • 强制
    • 1.【强制】好的单元测试必须遵守AIR原则。
      • 说明：单元测试在线上运行时，感觉像空气（AIR）一样并不存在，但在测试质量的保障上，却是非常关键的。好的单元测试宏观上来说，具有自动化、独立性、可重复执行的特点。 ⚫A：Automatic（自动化） ⚫I：Independent（独立性） ⚫R：Repeatable（可重复）
    • 2.【强制】单元测试应该是全自动执行的，并且非交互式的。测试用例通常是被定期执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测试中不准使用System.out来进行人肉验证，必须使用assert来验证。
    • 3.【强制】保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护，单元测试用例之间决不能互相调用，也不能依赖执行的先后次序。
      • 反例：method2需要依赖method1的执行，将执行结果作为method2的输入。
    • 4.【强制】单元测试是可以重复执行的，不能受到外界环境的影响
      • 说明：单元测试通常会被放到持续集成中，每次有代码check in时单元测试都会被执行。如果单测对外部环境（网络、服务、中间件等）有依赖，容易导致持续集成机制的不可用。 正例：为了不受外界环境影响，要求设计代码时就把SUT的依赖改成注入，在测试时用spring 这样的DI框架注入一个本地（内存）实现或者Mock实现。
    • 5.【强制】对于单元测试，要保证测试粒度足够小，有助于精确定位问题。单测粒度至多是类级别，一般是方法级别。
      • 说明：只有测试粒度小才能在出错时尽快定位到出错位置。单测不负责检查跨类或者跨系统的交互逻辑，那是集成测试的领域
    • 6.【强制】核心业务、核心应用、核心模块的增量代码确保单元测试通过。
      • 说明：新增代码及时补充单元测试，如果新增代码影响了原有单元测试，请及时修正。
    • 7.【强制】单元测试代码必须写在如下工程目录：src/test/java，不允许写在业务代码目录下。
      • 说明：源码编译时会跳过此目录，而单元测试框架默认是扫描此目录。
  • 推荐
    • 8.【推荐】单元测试的基本目标：语句覆盖率达到70%；核心模块的语句覆盖率和分支覆盖率都要达到100%
      • 说明：在工程规约的应用分层中提到的DAO层，Manager层，可重用度高的Service，都应该进行单元测试。
    • 9.【推荐】编写单元测试代码遵守BCDE原则，以保证被测试模块的交付质量。
      • ⚫B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。⚫C：Correct，正确的输入，并得到预期的结果。 ⚫D：Design，与设计文档相结合，来编写单元测试。 ⚫E：Error，强制错误信息输入（如：非法数据、异常流程、业务允许外等），并得到预期的结果。
    • 10.【推荐】对于数据库相关的查询，更新，删除等操作，不能假设数据库里的数据是存在的，或者直接操作数据库把数据插入进去，请使用程序插入或者导入数据的方式来准备数据。
      • 反例：删除某一行数据的单元测试，在数据库中，先直接手动增加一行作为删除目标，但是这一行新增数据并不符合业务插入规则，导致测试结果异常。
    • 11.【推荐】和数据库相关的单元测试，可以设定自动回滚机制，不给数据库造成脏数据。或者对单元测试产生的数据有明确的前后缀标识。
      • 正例：在阿里巴巴企业智能事业部的内部单元测试中，使用ENTERPRISE_INTELLIGENCE_UNIT_TEST_的前缀来标识单元测试相关代码。
    • 12.【推荐】对于不可测的代码在适当的时机做必要的重构，使代码变得可测，避免为了达到测试要求而书写不规范测试代码。
    • 13.【推荐】在设计评审阶段，开发人员需要和测试人员一起确定单元测试范围，单元测试最好覆盖所有测试用例（UC）。
    • 14.【推荐】单元测试作为一种质量保障手段，在项目提测前完成单元测试，不建议项目发布后补充单元测试用例。
  • 参考
    • 15.【参考】为了更方便地进行单元测试，业务代码应避免以下情况：
      • ⚫构造方法中做的事情过多。 ⚫存在过多的全局变量和静态方法。 ⚫存在过多的外部依赖。 ⚫存在过多的条件语句。说明：多层条件语句建议使用卫语句、策略模式、状态模式等方式重构。
    • 16.【参考】不要对单元测试存在如下误解：
      • ⚫那是测试同学干的事情。本文是开发手册，凡是本文内容都是与开发同学强相关的。⚫单元测试代码是多余的。系统的整体功能与各单元部件的测试正常与否是强相关的。⚫单元测试代码不需要维护。一年半载后，那么单元测试几乎处于废弃状态。 ⚫单元测试与线上故障没有辩证关系。好的单元测试能够最大限度地规避线上故障。
• 安全规约
  • 强制
    • 1.【强制】隶属于用户个人的页面或者功能必须进行权限控制校验。
      • 说明：防止没有做水平权限校验就可随意访问、修改、删除别人的数据，比如查看他人的私信内容。
    • 2.【强制】用户敏感数据禁止直接展示，必须对展示数据进行脱敏。
      • 说明：中国大陆个人手机号码显示为:137****0969，隐藏中间4位，防止隐私泄露
    • 3.【强制】用户输入的SQL参数严格使用参数绑定或者METADATA字段值限定，防止SQL注入，禁止字符串拼接SQL访问数据库。
      • 反例：某系统签名大量被恶意修改，即是因为对于危险字符# --没有进行转义，导致数据库更新时，where后边的信息被注释掉，对全库进行更新。
    • 4.【强制】用户请求传入的任何参数必须做有效性验证。
      • 说明：忽略参数校验可能导致： ⚫page size过大导致内存溢出 ⚫恶意order by导致数据库慢查询 ⚫缓存击穿 ⚫SSRF ⚫任意重定向 ⚫SQL注入，Shell注入，反序列化注入 ⚫正则输入源串拒绝服务ReDoS Java代码用正则来验证客户端的输入，有些正则写法验证普通用户输入没有问题，但是如果攻击人员使用的是特殊构造的字符串来验证，有可能导致死循环的结果。
    • 5.【强制】禁止向HTML页面输出未经安全过滤或未正确转义的用户数据。
    • 6.【强制】表单、AJAX提交必须执行CSRF安全验证。
      • 说明：CSRF(Cross-site request forgery)跨站请求伪造是一类常见编程漏洞。对于存在CSRF漏洞的应用/网站，攻击者可以事先构造好URL，只要受害者用户一访问，后台便在用户不知情的情况下对数据库中用户参数进行相应修改。
    • 7.【强制】URL外部重定向传入的目标地址必须执行白名单过滤。
    • 8.【强制】在使用平台资源，譬如短信、邮件、电话、下单、支付，必须实现正确的防重放的机制，如数量限制、疲劳度控制、验证码校验，避免被滥刷而导致资损。
      • 说明：如注册时发送验证码到手机，如果没有限制次数和频率，那么可以利用此功能骚扰到其它用户，并造成短信平台资源浪费
  • 推荐
    • 9.【推荐】发贴、评论、发送即时消息等用户生成内容的场景必须实现防刷、文本内容违禁词过滤等风控策略。
• MySql数据库
  • 建表规约
    • 强制
      • 1.【强制】表达是与否概念的字段，必须使用is_xxx的方式命名，数据类型是unsigned tinyint（1表示是，0表示否）。
        • 说明：任何字段如果为非负数，必须是unsigned。 注意：POJO类中的任何布尔类型的变量，都不要加is前缀，所以，需要在<resultMap>设置从is_xxx到Xxx的映射关系。数据库表示是与否的值，使用tinyint类型，坚持is_xxx的命名方式是为了明确其取值含义与取值范围。 正例：表达逻辑删除的字段名is_deleted，1表示删除，0表示未删除。
      • 2.【强制】表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。
        • 2.【强制】表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。说明：MySQL在Windows下不区分大小写，但在Linux下默认是区分大小写。因此，数据库名、表名、字段名，都不允许出现任何大写字母，避免节外生枝。 正例：aliyun_admin，rdc_config，level3_name 反例：AliyunAdmin，rdcConfig，level_3_name
      • 3.【强制】表名不使用复数名词。
        • 说明：表名应该仅仅表示表里面的实体内容，不应该表示实体数量，对应于DO类名也是单数形式，符合表达习惯。
      • 4.强制】禁用保留字，如desc、range、match、delayed等，请参考MySQL官方保留字。
      • 5.【强制】主键索引名为pk_字段名；唯一索引名为uk_字段名；普通索引名则为idx_字段名。
        • 说明：pk_ 即primary key；uk_ 即unique key；idx_ 即index的简称
      • 6.【强制】小数类型为decimal，禁止使用float和double。
        • 说明：在存储的时候，float 和double 都存在精度损失的问题，很可能在比较值的时候，得到不正确的结果。如果存储的数据范围超过decimal 的范围，建议将数据拆成整数和小数并分开存储。
      • 7.【强制】如果存储的字符串长度几乎相等，使用char定长字符串类型。
      • 8.【强制】varchar是可变长字符串，不预先分配存储空间，长度不要超过5000，如果存储长度大于此值，定义字段类型为text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。
      • 9.【强制】表必备三字段：id, gmt_create, gmt_modified。
        • 说明：其中id必为主键，类型为bigint unsigned、单表时自增、步长为1。gmt_create, gmt_modified的类型均为datetime类型，前者现在时表示主动式创建，后者过去分词表示被动式更新。
    • 推荐
      • 10.【推荐】表的命名最好是遵循“业务名称_表的作用”。
        • 正例：alipay_task / force_project / trade_config
      • 11.【推荐】库名与应用名称尽量一致。
      • 12.【推荐】如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释。
      • 13.【推荐】字段允许适当冗余，以提高查询性能，但必须考虑数据一致。冗余字段应遵循：
        • 正例：各业务线经常冗余存储商品名称，避免查询时需要调用IC服务获取。
        • 1）不是频繁修改的字段。
        • 2）不是唯一索引的字段
        • 3）不是varchar超长字段，更不能是text字段
      • 14.【推荐】单表行数超过500万行或者单表容量超过2GB，才推荐进行分库分表。
        • 说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。
    • 参考
      • 15.【参考】合适的字符存储长度，不但节约数据库表空间、节约索引存储，更重要的是提升检索速度。
        •  正例：无符号值可以避免误存负数，且扩大了表示范围。
  • 索引规约
    • 强制
      • 1.【强制】业务上具有唯一特性的字段，即使是组合字段，也必须建成唯一索引。
        • 说明：不要以为唯一索引影响了insert速度，这个速度损耗可以忽略，但提高查找速度是明显的；另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生。
      • 2.【强制】超过三个表禁止join。需要join的字段，数据类型保持绝对一致；多表关联查询时，保证被关联的字段需要有索引。
        • 说明：即使双表join也要注意表索引、SQL性能。
      • 3.【强制】在varchar字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度。
        • 说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为20的索引，区分度会高达90%以上，可以使用count(distinct left(列名, 索引长度))/count(*)的区分度来确定。
      • 4.【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。
        • 说明：索引文件具有B-Tree的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。
    • 推荐
      • 5.【推荐】如果有order by的场景，请注意利用索引的有序性。order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现file_sort的情况，影响查询性能。
        • 正例：where a=? and b=? order by c; 索引：a_b_c 反例：索引如果存在范围查询，那么索引有序性无法利用，如：WHERE a>10 ORDERBY b; 索引a_b无法排序。
      • 6.【推荐】利用覆盖索引来进行查询操作，避免回表。
        • 说明：如果一本书需要知道第11章是什么标题，会翻开第11章对应的那一页吗？目录浏览一下就好，这个目录就是起到覆盖索引的作用。 正例：能够建立索引的种类分为主键索引、唯一索引、普通索引三种，而覆盖索引只是一种查询的一种效果，用explain的结果，extra列会出现：using index。
      • 7.【推荐】利用延迟关联或者子查询优化超多分页场景。
        • 说明：MySQL并不是跳过offset行，而是取offset+N行，然后返回放弃前offset行，返回N行，那当offset特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行SQL改写。 正例：先快速定位需要获取的id段，然后再关联： SELECT a.* FROM 表1 a, (select id from 表1 where 条件LIMIT 100000,20 ) b where a.id=b.id
      • 8.【推荐】SQL性能优化的目标：至少要达到range级别，要求是ref级别，如果可以是consts最好。
        • 说明： 1）consts 单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据。 2）ref 指的是使用普通的索引（normal index）。 3）range 对索引进行范围检索。 反例：explain表的结果，type=index，索引物理文件全扫描，速度非常慢，这个index级别比较range还低，与全表扫描是小巫见大巫。
      • 9.【推荐】建组合索引的时候，区分度最高的在最左边。
        • 正例：如果where a=? and b=?，a列的几乎接近于唯一值，那么只需要单建idx_a索引即可。 说明：存在非等号和等号混合判断条件时，在建索引时，请把等号条件的列前置。如：where c>? and d=? 那么即使c的区分度更高，也必须把d放在索引的最前列，即建立组合索引idx_d_c。
      • 10.【推荐】防止因字段类型不同造成的隐式转换，导致索引失效。
    • 参考
      • 11.【参考】创建索引时避免有如下极端误解：
        • 1）索引宁滥勿缺。认为一个查询就需要建一个索引。 2）吝啬索引的创建。认为索引会消耗空间、严重拖慢记录的更新以及行的新增速度。 3）抵制惟一索引。认为惟一索引一律需要在应用层通过“先查后插”方式解决。
  • SQL语句
    • 强制
      • 1.【强制】不要使用count(列名)或count(常量)来替代count(*)，count(*)是SQL92定义的标准统计行数的语法，跟数据库无关，跟NULL和非NULL无关。
        • 说明：count(*)会统计值为NULL的行，而count(列名)不会统计此列为NULL值的行。
      • 2.【强制】count(distinct col) 计算该列除NULL之外的不重复行数，注意count(distinct col1, col2) 如果其中一列全为NULL，那么即使另一列有不同的值，也返回为0。
      • 3.【强制】当某一列的值全是NULL时，count(col)的返回结果为0，但sum(col)的返回结果为NULL，因此使用sum()时需注意NPE问题。
        • 正例：可以使用如下方式来避免sum的NPE问题：SELECT IFNULL(SUM(column), 0) FROM table;
      • 4.【强制】使用ISNULL()来判断是否为NULL值。
        • 说明：NULL与任何值的直接比较都为NULL。 1）NULL<>NULL的返回结果是NULL，而不是false。 2）NULL=NULL的返回结果是NULL，而不是true。 3）NULL<>1的返回结果是NULL，而不是true。 反例：在SQL语句中，如果在null前换行，影响可读性。select * from table where column1 is null and column3 is not null; 而`ISNULL(column)`是一个整体，简洁易懂。从性能数据上分析，`ISNULL(column)`执行效率更快一些。
      • 5.【强制】代码中写分页查询逻辑时，若count为0应直接返回，避免执行后面的分页语句。
      • 6.【强制】不得使用外键与级联，一切外键概念必须在应用层解决。
        • 说明：（概念解释）学生表中的student_id是主键，那么成绩表中的student_id则为外键。如果更新学生表中的student_id，同时触发成绩表中的student_id更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群；级联更新是强阻塞，存在数据库更新风暴的风险；外键影响数据库的插入速度。
      • 7.【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。
      • 8.【强制】数据订正（特别是删除或修改记录操作）时，要先select，避免出现误删除，确认无误才能执行更新语句。
      • 9.【强制】对于数据库中表记录的查询和变更，只要涉及多个表，都需要在列名前加表的别名（或表名）进行限定。
        • 说明：对多表进行查询记录、更新记录、删除记录时，如果对操作列没有限定表的别名（或表名），并且操作列在多个表中存在时，就会抛异常。 正例：select t1.name from table_firstas t1, table_secondas t2where t1.id=t2.id; 反例：在某业务中，由于多表关联查询语句没有加表的别名（或表名）的限制，正常运行两年后，最近在某个表中增加一个同名字段，在预发布环境做数据库变更后，线上查询语句出现出1052异常：Column 'name' in field list is ambiguous。
    • 推荐
      • 10.【推荐】SQL语句中表的别名前加as，并且以t1、t2、t3、...的顺序依次命名
        • 说明： 1）别名可以是表的简称，或者是根据表出现的顺序，以t1、t2、t3的方式命名。 2）别名前加as使别名更容易识别。 正例：select t1.name from table_firstas t1, table_second as t2 where t1.id=t2.id;
      • 11.【推荐】in操作能避免则避免，若实在避免不了，需要仔细评估in后边的集合元素数量，控制在1000个之内。
    • 参考
      • 12.【参考】因国际化需要，所有的字符存储与表示，均采用utf8字符集，那么字符计数方法需要注意。
        • 说明：SELECT LENGTH("轻松工作")；返回为12 SELECT CHARACTER_LENGTH("轻松工作")； 返回为4如果需要存储表情，那么选择utf8mb4来进行存储，注意它与utf8编码的区别。
      • 13.【参考】TRUNCATETABLE比DELETE速度快，且使用的系统和事务日志资源少，但TRUNCATE无事务且不触发trigger，有可能造成事故，故不建议在开发代码中使用此语句。
        • 说明：TRUNCATE TABLE 在功能上与不带WHERE 子句的DELETE 语句相同。
  • ORM映射
    • 强制
      • 1.【强制】在表查询中，一律不要使用* 作为查询的字段列表，需要哪些字段必须明确写明。
        • 说明：1）增加查询分析器解析成本。2）增减字段容易与resultMap配置不一致。3）无用字段增加网络消耗，尤其是text类型的字段。
      • 2.【强制】POJO类的布尔属性不能加is，而数据库字段必须加is_，要求在resultMap中进行字段与属性之间的映射。
        • 说明：参见定义POJO类以及数据库字段定义规定，在sql.xml增加映射，是必须的。
      • 3.【强制】不要用resultClass当返回参数，即使所有类属性名与数据库字段一一对应，也需要定义<resultMap>；反过来，每一个表也必然有一个<resultMap>与之对应。
        • 说明：配置映射关系，使字段与DO类解耦，方便维护。
      • 4.【强制】sql.xml配置参数使用：#{}，#param# 不要使用${} 此种方式容易出现SQL注入。
      • 5.【强制】iBATIS自带的queryForList(StringstatementName,intstart,intsize)不推荐使用。
        • 说明：其实现方式是在数据库取到statementName对应的SQL语句的所有记录，再通过subList取start,size的子集合。 正例：Map<String,Object>map =newHashMap<>(); map.put("start",start); map.put("size",size)
      • 6.【强制】不允许直接拿HashMap与Hashtable作为查询结果集的输出。
        • 反例：某同学为避免写一个\<resultMap\>，直接使用HashTable来接收数据库返回结果，结果出现日常是把bigint转成Long值，而线上由于数据库版本不一样，解析成BigInteger，导致线上问题。
      • 7.【强制】更新数据表记录时，必须同时更新记录对应的gmt_modified字段值为当前时间。
    • 推荐
      • 8.【推荐】不要写一个大而全的数据更新接口。传入为POJO类，不管是不是自己的目标更新字段，都进行update table set c1=value1,c2=value2,c3=value3; 这是不对的。执行SQL时，不要更新无改动的字段，一是易出错；二是效率低；三是增加binlog存储。
    • 参考
      • 9.【参考】@Transactional事务不要滥用。事务会影响数据库的QPS，另外使用事务的地方需要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。
      • 10.【参考】<isEqual>中的compareValue是与属性值对比的常量，一般是数字，表示相等时带上此条件；<isNotEmpty>表示不为空且不为null时执行；<isNotNull>表示不为null值时执行。
• 工程结构
  • 应用分层
  • 二方库依赖
  • 服务器
• 设计规约
  • 强制
    • 1.【强制】存储方案和底层数据结构的设计获得评审一致通过，并沉淀成为文档
      • 说明：有缺陷的底层数据结构容易导致系统风险上升，可扩展性下降，重构成本也会因历史数据迁移和系统平滑过渡而陡然增加，所以，存储方案和数据结构需要认真地进行设计和评审，生产环境提交执行后，需要进行double check。 正例：评审内容包括存储介质选型、表结构设计能否满足技术方案、存取性能和存储空间能否满足业务发展、表或字段之间的辩证关系、字段名称、字段类型、索引等；数据结构变更（如在原有表中新增字段）也需要进行评审通过后上线。
    • 2.【强制】在需求分析阶段，如果与系统交互的User超过一类并且相关的User Case超过5个，使用用例图来表达更加清晰的结构化需求。
    • 3.【强制】如果某个业务对象的状态超过3个，使用状态图来表达并且明确状态变化的各个触发条件。
      • 说明：状态图的核心是对象状态，首先明确对象有多少种状态，然后明确两两状态之间是否存在直接转换关系，再明确触发状态转换的条件是什么。 正例：淘宝订单状态有已下单、待付款、已付款、待发货、已发货、已收货等。比如已下单与已收货这两种状态之间是不可能有直接转换关系的。
    • 4.【强制】如果系统中某个功能的调用链路上的涉及对象超过3个，使用时序图来表达并且明确各调用环节的输入与输出。
      • 说明：时序图反映了一系列对象间的交互与协作关系，清晰立体地反映系统的调用纵深链路。
    • 5.【强制】如果系统中模型类超过5个，并且存在复杂的依赖关系，使用类图来表达并且明确类之间的关系。
      • 说明：类图像建筑领域的施工图，如果搭平房，可能不需要，但如果建造蚂蚁Z空间大楼，肯定需要详细的施工图。
    • 6.【强制】如果系统中超过2个对象之间存在协作关系，并且需要表示复杂的处理流程，使用活动图来表示。
      • 说明：活动图是流程图的扩展，增加了能够体现协作关系的对象泳道，支持表示并发等。
  • 推荐
    • 7.【推荐】系统架构设计时明确以下目标
      • 确定系统边界。确定系统在技术层面上的做与不做
      • 确定系统内模块之间的关系。确定模块之间的依赖关系及模块的宏观输入与输出
      • 确定指导后续设计与演化的原则。使后续的子系统或模块设计在一个既定的框架内和技术方向上继续演化。
      • 确定非功能性需求。非功能性需求是指安全性、可用性、可扩展性等。
    • 8.【推荐】需求分析与系统设计在考虑主干功能的同时，需要充分评估异常流程与业务边界。
      • 反例：用户在淘宝付款过程中，银行扣款成功，发送给用户扣款成功短信，但是支付宝入款时由于断网演练产生异常，淘宝订单页面依然显示未付款，导致用户投诉。
    • 9.【推荐】类在设计与实现时要符合单一原则。
      • 说明：单一原则最易理解却是最难实现的一条规则，随着系统演进，很多时候，忘记了类设计的初衷。
    • 10.【推荐】谨慎使用继承的方式来进行扩展，优先使用聚合/组合的方式来实现
      • 说明：不得已使用继承的话，必须符合里氏代换原则，此原则说父类能够出现的地方子类一定能够出现，比如，“把钱交出来”，钱的子类美元、欧元、人民币等都可以出现。
    • 11.【推荐】系统设计阶段，根据依赖倒置原则，尽量依赖抽象类与接口，有利于扩展与维护。
      • 说明：低层次模块依赖于高层次模块的抽象，方便系统间的解耦。
    • 12.【推荐】系统设计阶段，注意对扩展开放，对修改闭合。
      • 说明：极端情况下，交付的代码是不可修改的，同一业务域内的需求变化，通过模块或类的扩展来实现。
    • 13.【推荐】系统设计阶段，共性业务或公共行为抽取出来公共模块、公共配置、公共类、公共方法等，在系统中不出现重复代码的情况。
      • 说明：随着代码的重复次数不断增加，维护成本指数级上升。
    • 4.【推荐】避免如下误解：敏捷开发= 讲故事+ 编码+ 发布。
      • 说明：敏捷开发是快速交付迭代可用的系统，省略多余的设计方案，摒弃传统的审批流程，但核心关键点上的必要设计和文档沉淀是需要的。 反例：某团队为了业务快速发展，敏捷成了产品经理催进度的借口，系统中均是勉强能运行但像面条一样的代码，可维护性和可扩展性极差，一年之后，不得不进行大规模重构，得不偿失。
  • 参考
    • 15.【参考】设计文档的作用是明确需求、理顺逻辑、后期维护，次要目的用于指导编码。
      • 说明：避免为了设计而设计，系统设计文档有助于后期的系统维护和重构，所以设计结果需要进行分类归档保存。
    • 16.【参考】可扩展性的本质是找到系统的变化点，并隔离变化点。
      • 说明：世间众多设计模式其实就是一种设计模式即隔离变化点的模式。 正例：极致扩展性的标志，就是需求的新增，不会在原有代码交付物上进行任何形式的修改。
    • 17.【参考】设计的本质就是识别和表达系统难点。
      • 说明：识别和表达完全是两回事，很多人错误地认为识别到系统难点在哪里，表达只是自然而然的事情，但是大家在设计评审中经常出现语焉不详，甚至是词不达意的情况。准确地表达系统难点需要具备如下能力：表达规则和表达工具的熟练性。抽象思维和总结能力的局限性。基础知识体系的完备性。深入浅出的生动表达力。
    • 18.【参考】代码即文档的观点是错误的，清晰的代码只是文档的某个片断，而不是全部。
      • 说明：代码的深度调用，模块层面上的依赖关系网，业务场景逻辑，非功能性需求等问题是需要相应的文档来完整地呈现的
    • 19.【参考】在做无障碍产品设计时，需要考虑到：
      • 正例：用户登陆场景中，输入框的按钮都需要考虑tab键聚焦，符合自然逻辑的操作顺序如下，“输入用户名，输入密码，输入验证码，点击登录”，其中验证码实现语音验证方式。如果有自定义标签实现的控件设置控件类型可使用role属性。
      • 所有可交互的控件元素必须能被tab键聚焦，并且焦点顺序需符合自然操作逻辑
      • 用于登陆校验和请求拦截的验证码均需提供图形验证以外的其它方式。
      • 自定义的控件类型需明确交互方式。