精华内容
参与话题
问答
  • 阿里开发规范(精简版)

    万次阅读 2018-03-14 10:28:56
    Java开发规范 命名 【规范】类名使用UpperCamelCase 风格,必须遵从驼峰形式,但以下情形例外: ( 领域模型的相关命名 )DO / BO / DTO / VO 等。 正例: MarcoPolo / UserDO / XmlService / TcpUdpDeal / ...

    Java开发规范

    命名

    【规范】类名使用UpperCamelCase 风格,必须遵从驼峰形式,但以下情形例外: ( 领域模型的相关命名 )DO / BO / DTO / VO 等。
    正例: MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
    反例: macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion

    【规范】方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase 风格,必须遵从驼峰形式。
    正例: localValue / getHttpMessage() / inputUserId

    【规范】常量命名全部大写,单词间用下划线隔开,力求语义表达完整清楚,不要嫌名字长。

    【规范】抽象类命名使用 Abstract 或 Base 开头 ; 异常类命名使用 Exception 结尾 ; 测试类命名以它要测试的类的名称开始,以 Test 结尾。枚举类名建议带上 Enum 后缀,枚举成员名称需要全大写,单词间用下划线隔开。

    【规范】POJO 类中布尔类型的变量,都不要加 is ,否则部分框架解析会引起序列化错误。

    【规范】各层命名规约:
    A) Service / DAO 层方法命名规约
    1 ) 获取单个对象的方法用 get 做前缀。
    2 ) 获取多个对象的方法用 list 做前缀(习惯:getXXXList)。
    3 ) 获取统计值的方法用 count 做前缀。
    4 ) 插入的方法用 save( 推荐 ) 或 insert 做前缀。
    5 ) 删除的方法用 remove( 推荐 ) 或 delete 做前缀。
    6 ) 修改的方法用 update 做前缀(或modify)。
    B) 领域模型命名规约
    1 ) 数据对象: xxxDO , xxx 即为数据表名。
    2 ) 数据传输对象: xxxDTO , xxx 为业务领域相关的名称。
    3 ) 展示对象: xxxVO , xxx 一般为网页名称。
    4 ) POJO 是 DO / DTO / BO / VO 的统称,禁止命名成 xxxPOJO 。

    常量

    【规范】不允许任何魔法值( 即未经定义的常量 ) 直接出现在代码中。
    反例: String key =” Id # taobao _”+ tradeId;
    cache . put(key , value);

    格式规约

    【风格】单行太长需换行

    【风格】方法体内的执行语句组、变量的定义语句组、不同的业务逻辑之间或者不同的语义之间插入一个空行。相同业务逻辑和语义之间不需要插入空行。

    OOP规约

    【效率】避免通过一个类的对象引用访问此类的静态变量或静态方法,无谓增加编译器解析成本,直接用类名来访问即可。

    【规范】所有的覆写方法,必须加@ Override 注解。

    【规范】对外暴露的接口签名,原则上不允许修改方法签名,避免对接口调用方产生影响。接口过时必须加@Deprecated 注解,并清晰地说明采用的新接口或者新服务是什么

    【规范】Object 的 equals 方法容易抛空指针异常,应使用常量或确定有值的对象来调用equals
    正例: ” test ” .equals(object);
    反例: object.equals( ” test ” );

    【规范】所有的相同类型的包装类对象之间值的比较,全部使用 equals 方法比较。(注意空指针)
    说明:对于 Integer var =?在-128 至 127 之间的赋值, Integer 对象是在IntegerCache . cache 产生,会复用已有对象,这个区间内的 Integer 值可以直接使用==进行判断,但是这个区间之外的所有数据,都会在堆上产生,并不会复用已有对象,这是一个大坑,推荐使用 equals 方法进行判断。

    【规范】关于基本数据类型与包装数据类型的使用标准如下:
    1 ) 所有的 POJO 类属性必须使用包装数据类型。
    2 ) RPC 方法的返回值和参数必须使用包装数据类型。
    3 ) 所有的局部变量【推荐】使用基本数据类型。

    【强制】序列化类新增属性时,请不要修改 serialVersionUID 字段,避免反序列失败 ; 如果完全不兼容升级,避免反序列化混乱,那么请修改 serialVersionUID 值。

    【规范】构造方法里面禁止加入任何业务逻辑,如果有初始化逻辑,请放在 init 方法中。

    【规范】使用索引访问用 String 的 split 方法得到的数组时,需做最后一个分隔符后有无内容的检查,否则会有抛 IndexOutOfBoundsException 的风险。
    说明:
    String str = “a,b,c,,”;
    String[] ary = str.split(“,”);
    //预期大于 3,结果是 3
    System.out.println(ary.length);

    【规范】当一个类有多个构造方法,或者多个同名方法,这些方法应该按顺序放置在一起,便于阅读。

    【风格】类内方法定义顺序依次是:公有方法或保护方法 > 私有方法 > getter / setter方法。

    【效率】final 可提高程序响应效率,声明成 final 的情况:
    1 ) 不需要重新赋值的变量,包括类属性、局部变量。
    2 ) 对象参数前加 final ,表示不允许修改引用的指向。
    3 ) 类方法确定不允许被重写。
    4 )例子:final boolean existed = (file.open(fileName, “w”) != null) && (…) || (…);

    集合处理

    【强制】关于 hashCode 和 equals 的处理,遵循如下规则
    1) 只要重写 equals ,就必须重写 hashCode 。
    2) 因为 Set 存储的是不重复的对象,依据 hashCode 和 equals 进行判断,所以 Set 存储的对象必须重写这两个方法。
    3) 如果自定义对象做为 Map 的键,那么必须重写 hashCode 和 equals 。

    【强制】不要在 foreach 循环里进行元素的 remove / add 操作。 remove 元素请使用 Iterator方式,如果并发操作,需要对 Iterator 对象加锁。
    反例:
    List<String> a = new ArrayList<String>();
    a.add(“1”);
    a.add(“2”);
    for (String temp : a) {
    if(“1”.equals(temp)){
    a.remove(temp);
    }
    }
    说明:以上代码的执行结果肯定会出乎大家的意料,那么试一下把“1”换成“2”,会是同样的结果吗?(java.util.ConcurrentModificationException)
    正例:
    Iterator<String> it = a.iterator();
    while(it.hasNext()){
    String temp = it.next();
    if(删除元素的条件){
    it.remove();
    }
    }

    【规范】集合初始化时,尽量指定集合初始值大小。
    说明: ArrayList 尽量使用 ArrayList(int initialCapacity) 初始化。

    【规范】使用 entrySet 遍历 Map 类集合 KV,而不是 keySet 方式进行遍历。
    说明:keySet 其实是遍历了 2 次,一次是转为 Iterator 对象,另一次是从 hashMap 中取出 key 所对应的 value。而 entrySet 只是遍历了一次就把 key 和 value 都放到了 entry 中,效 率更高。如果是 JDK8,使用 Map.foreach 方法
    Map<String, String> map = new HashMap<String, String>();
    map.put(“1”, “@@”);
    map.put(“2”, “##”);

    /**
    * JDK8推荐使用
    */
    map.forEach((K, V) -> {
    System.out.println(“Key : ” + K);
    System.out.println(“Value : ” + V);
    });

    /**
    * foreach推荐使用
    */
    for (Map.Entry<String, String> entry : map.entrySet()) {
    System.out.println(“Key : ” + entry.getKey());
    System.out.println(“Value : ” + entry.getValue());
    }

    /**
    * 不推荐使用
    */
    for (String key : map.keySet()) {
    System.out.println(“Key : ” + key);
    System.out.println(“Value : ” + map.get(key));
    }

    【强制】高度注意 Map 类集合 K/V 能不能存储 null 值的情况,如下表格:
    集合类 Key Value Super 说明
    Hashtable 不允许为 null 不允许为 null Dictionary 线程安全
    ConcurrentHashMap 不允许为 null 不允许为 null AbstractMap 分段锁技术
    TreeMap 不允许为 null 允许为 null AbstractMap 线程不安全
    HashMap 允许为 null 允许为 null AbstractMap 线程不安全

    并发处理

    【规范】获取单例对象需要保证线程安全,其中的方法也要保证线程安全。
    说明:资源驱动类、工具类、单例工厂类都需要注意。

    【规范】创建线程或线程池时请指定有意义的线程名称,方便出错时回溯。
    正例:
    public class TimerTaskThread extends Thread { public TimerTaskThread(){
    super.setName(“TimerTaskThread”); … }

    【规范】线程资源必须通过线程池提供,不允许在应用中自行显式创建线程。
    说明:使用线程池的好处是减少在创建和销毁线程上所花的时间以及系统资源的开销,解决资 源不足的问题。如果不使用线程池,有可能造成系统创建大量同类线程而导致消耗完内存或者 “过度切换”的问题。

    【规范】线程池不允许使用 Executors 去创建,而是通过 ThreadPoolExecutor 的方式,这样 的处理方式让写的同学更加明确线程池的运行规则规避资源耗尽的风险。 说明:Executors 返回的线程池对象的弊端如下:
    1)FixedThreadPool 和 SingleThreadPool:
    允许的请求队列长度为 Integer.MAX_VALUE,可能会堆积大量的请求,从而导致 OOM。
    2)CachedThreadPool 和 ScheduledThreadPool:
    允许的创建线程数量为 Integer.MAX_VALUE,可能会创建大量的线程,从而导致 OOM。

    【效率】高并发时,同步调用应该去考量锁的性能损耗。能用无锁数据结构,就不要用锁;能 锁区块,就不要锁整个方法体;能用对象锁,就不要用类锁。

    【强制】对多个资源、数据库表、对象同时加锁时,需要保持一致的加锁顺序,否则可能会造 成死锁。
    说明:线程一需要对表 A、B、C 依次全部加锁后才可以进行更新操作,那么线程二的加锁顺序 也必须是 A、B、C,否则可能出现死锁。

    【规范】并发修改同一记录时,避免更新丢失,要么在应用层加锁,要么在缓存加锁,要么在 数据库层使用乐观锁,使用 version 作为更新依据。
    说明:如果每次访问冲突概率小于 20%,推荐使用乐观锁,否则使用悲观锁。乐观锁的重试次 数不得小于 3 次。

    【规范】多线程并行处理定时任务时,Timer 运行多个 TimeTask 时,只要其中之一没有捕获 抛出的异常,其它任务便会自动终止运行,使用ScheduledExecutorService 则没有这个问题。

    【规范】HashMap 在容量不够进行 resize 时由于高并发可能出现死链,导致 CPU 飙升,在 开发过程中注意规避此风险。

    控制语句

    【规范】在一个 switch 块内,每个 case 要么通过 break/return 等来终止,要么注释说明程 序将继续执行到哪一个 case 为止;在一个 switch 块内,都必须包含一个 default 语句并且 放在最后,即使它什么代码也没有

    【规范】在 if/else/for/while/do 语句中必须使用大括号,即使只有一行代码,避免使用 下面的形式:if (condition) statements;

    【规范】推荐尽量少用 else, if-else 的方式可以改写成:
    if(condition){
    return obj; }
    // 接着写 else 的业务逻辑代码;
    说明:如果非得使用if()…else if()…else…方式表达逻辑,【强制】请勿超过3层,
    超过请使用状态设计模式 或者 卫语句
    卫语句示例:
    1. public void today() { if (isBusy()) {  
    2. System.out.println(“change time.”); return;  
    3. }  
    4. if (isFree()) {  
    5. System.out.println(“go to travel.”);  
    6. return;   
    7. }  
    8. System.out.println(“stay at home to learn Alibaba Java Coding Guidelines.”);  
    9. return;   
    10. }  
    public void today() { if (isBusy()) {
    System.out.println(“change time.”); return;
    }
    if (isFree()) {
    System.out.println(“go to travel.”);
    return; 
    }
    System.out.println(“stay at home to learn Alibaba Java Coding Guidelines.”);
    return; 
    }



    【规范】除常用方法(如 getXxx/isXxx)等外,不要在条件判断中执行其它复杂的语句,将复 杂逻辑判断的结果赋值给一个有意义的布尔变量名,以提高可读性。
    说明:很多 if 语句内的逻辑相当复杂,阅读者需要分析条件表达式的最终结果,才能明确什么 样的条件执行什么样的语句,那么,如果阅读者分析逻辑表达式错误呢?
    正例:
    //伪代码如下
    boolean existed = (file.open(fileName, “w”) != null) && (…) || (…); if (existed) {
    … }
    反例:
    if ((file.open(fileName, “w”) != null) && (…) || (…)) { …
    }

    【规范】方法中需要进行参数校验的场景:
    1) 调用频次低的方法。
    2) 执行时间开销很大的方法,参数校验时间几乎可以忽略不计,但如果因为参数错误导致
    中间执行回退,或者错误,那得不偿失。
    3) 需要极高稳定性和可用性的方法。
    4) 对外提供的开放接口,不管是RPC/API/HTTP接口。
    5) 敏感权限入口。

    【规范】方法中不需要参数校验的场景:
    1) 极有可能被循环调用的方法,不建议对参数进行校验。但在方法说明里必须注明外部参
    数检查。
    2) 底层的方法调用频度都比较高,一般不校验。毕竟是像纯净水过滤的最后一道,参数错误不太可能到底层才会暴露问题。一般 DAO 层与 Service 层都在同一个应用中,部署在同一 台服务器中,所以 DAO 的参数校验,可以省略。
    3) 被声明成private只会被自己代码所调用的方法,如果能够确定调用方法的代码传入参 数已经做过检查或者肯定不会有问题,此时可以不校验参数。

    注释规约

    【规范】类、类属性、类方法的注释必须使用 Javadoc 规范,使用/**内容*/格式,不得使用 //xxx 方式。

    【规范】所有的抽象方法(包括接口中的方法)必须要用 Javadoc 注释、除了返回值、参数、 异常说明外,还必须指出该方法做什么事情,实现什么功能。
    说明:对子类的实现要求,或者调用注意事项,请一并说明。

    【风格】方法内部单行注释,在被注释语句上方另起一行,使用//注释。方法内部多行注释使用/* */注释,注意与代码对齐。

    【规范】所有的枚举类型字段必须要有注释,说明每个数据项的用途。

    【规范】代码修改的同时,注释也要进行相应的修改,尤其是参数、返回值、异常、核心逻辑 等的修改。

    【规范】注释掉的代码尽量要配合说明,而不是简单的注释掉。
    说明:代码被注释掉有两种可能性:
    1)后续会恢复此段代码逻辑。
    2)永久不用。前者如果没 有备注信息,难以知晓注释动机。
    后者建议直接删掉(代码仓库保存了历史代码)。

    【风格】特殊注释标记,请注明标记人与标记时间。注意及时处理这些标记,通过标记扫描, 经常清理此类标记。线上故障有时候就是来源于这些标记处的代码。
    1) 待办事宜(TODO):( 标记人,标记时间,[预计处理时间]) 表示需要实现,但目前还未实现的功能。这实际上是一个 Javadoc 的标签,目前的 Javadoc
    还没有实现,但已经被广泛使用。只能应用于类,接口和方法(因为它是一个 Javadoc 标签)。
    2) 错误,不能工作(FIXME):(标记人,标记时间,[预计处理时间])
    在注释中用 FIXME 标记某代码是错误的,而且不能工作,需要及时纠正的情况。

    异常

    【规范】异常不要用来做流程控制,条件控制,因为异常的处理效率比条件分支低。

    【规范】对大段代码进行 try-catch,这是不负责任的表现。catch 时请分清稳定代码和非稳 定代码,稳定代码指的是无论如何不会出错的代码。对于非稳定代码的 catch 尽可能进行区分 异常类型,再做对应的异常处理。

    【规范】捕获异常是为了处理它,不要捕获了却什么都不处理而抛弃之,如果不想处理它,请 将该异常抛给它的调用者。最外层的业务使用者,必须处理异常,将其转化为用户可以理解的 内容。

    【强制】有 try 块放到了事务代码中,catch 异常后,如果需要回滚事务,一定要注意手动回 滚事务。

    【规范】不能在 finally 块中使用 return,finally 块中的 return 返回后方法结束执行,不 会再执行 try 块中的 return 语句。

    【规范】方法的返回值可以为 null,不强制返回空集合,或者空对象等,必须添加注释充分 说明什么情况下会返回 null 值。调用方需要进行 null 判断防止 NPE 问题。

    【规范】防止 NPE,是程序员的基本修养,注意 NPE 产生的场景:
    1) 返回类型为包装数据类型,有可能是null,返回int值时注意判空。
    反例:public int f(){ return Integer 对象}; 如果为 null,自动解箱抛 NPE。
    2) 数据库的查询结果可能为null。
    3) 集合里的元素即使isNotEmpty,取出的数据元素也可能为null。
    4) 远程调用返回对象,一律要求进行NPE判断。
    5) 对于Session中获取的数据,建议NPE检查,避免空指针。
    6) 级联调用obj.getA().getB().getC();一连串调用,易产生NPE。

    【规范】在代码中使用“抛异常”还是“返回错误码”,对于公司外的 http/api 开放接口必须 使用“错误码”;而应用内部推荐异常抛出;跨应用间 RPC 调用优先考虑使用 Result 方式,封 装 isSuccess、“错误码”、“错误简短信息”。
    说明:关于 RPC 方法返回方式使用 Result 方式的理由:
    1)使用抛异常返回方式,调用方如果没有捕获到就会产生运行时错误。
    2)如果不加栈信息,只是new自定义异常,加入自己的理解的error message,对于调用 端解决问题的帮助不会太多。如果加了栈信息,在频繁调用出错的情况下,数据序列化和传输 的性能损耗也是问题。

    【规范】避免出现重复的代码(Don’t Repeat Yourself),即DRY原则。

    日志

    【规范】应用中不可直接使用日志系统(Log4j、Logback)中的 API,而应依赖使用日志框架
    SLF4J 中的 API,使用门面模式的日志框架,有利于维护和各个类的日志处理方式统一。
    import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;
    private static final Logger logger = LoggerFactory.getLogger(Abc.class);

    【规范】日志文件推荐至少保存 15 天,因为有些异常具备以“周”为频次发生的特点。

    【规范】应用中的扩展日志(如打点、临时监控、访问日志等)命名方式: appName_logType_logName.log。
    logType:日志类型,推荐分类有 stats/desc/monitor/visit 等;
    logName:日志描述。这种命名的好处:通过文件名就可知 道日志文件属于什么应用,什么类型,什么目的,也有利于归类查找。
    正例:mppserver 应用中单独监控时区转换异常,如: mppserver_monitor_timeZoneConvert.log
    说明:推荐对日志进行分类,错误日志和业务日志尽量分开存放,便于开发人员查看,也便于 通过日志对系统进行及时监控。

    【规范】对 trace/debug/info 级别的日志输出,必须使用条件输出形式或者使用占位符的方式
    说明:logger.debug(“Processing trade with id: ” + id + ” symbol: ” + symbol); 如果日志级别是 warn,上述日志不会打印,但是会执行字符串拼接操作,如果 symbol 是对象, 会执行 toString()方法,浪费了系统资源,执行了上述操作,最终日志却没有打印。 正例:(条件)
    if (logger.isDebugEnabled()) {
    logger.debug(“Processing trade with id: ” + id + ” symbol: ” + symbol);
    }
    正例:(占位符)
    logger.debug(“Processing trade with id: {} symbol : {} “, id, symbol);

    * 避免重复打印日志,浪费磁盘空间,务必在 log4j.xml 中设置 additivity=false。
    正例:<logger name=”com.taobao.dubbo.config” additivity=”false”>

    【规范】可以使用warn 日志级别来记录用户输入参数错误的情况,避免用户投诉时,无所适 从。注意日志输出的级别,error 级别只记录系统逻辑出错、异常等重要的错误信息。如非必 要,请不要在此场景打出 error 级别。

    【规范】谨慎地记录日志。生产环境禁止输出 debug 日志;有选择地输出 info 日志;如果使 用 warn 来记录刚上线时的业务行为信息,一定要注意日志输出量的问题,避免把服务器磁盘 撑爆,并记得及时删除这些观察日志。
    说明:大量地输出无效日志,不利于系统性能提升,也不利于快速定位错误点。记录日志时请

    思考:这些日志真的有人看吗?看到这条日志你能做什么?能不能给问题排查带来好处?

    其它

    【效率】在使用正则表达式时,利用好其预编译功能,可以有效加快正则匹配速度。 说明:不要在方法体内定义:Pattern pattern = Pattern.compile(规则);

    【规范】获取当前毫秒数 System.currentTimeMillis(); 而不是 new Date().getTime();
    说明:如果想获取更加精确的纳秒级时间值,用 System.nanoTime()。在 JDK8 中,针对统计 时间等场景,推荐使用Instant 类。

    【规范】对于“明确停止使用的代码和配置”,如方法、变量、类、配置文件、动态配置属性等要坚决从程序中清理出去,避免造成过多垃圾。

    单元测试

    【强制】好的单元测试必须遵守 AIR 原则。

    说明:单元测试在线上运行时,感觉像空气(AIR)一样并不存在,但在测试质量的保障上,却是非常关键的。好的单元测试宏观上来说,具有自动化、独立性、可重复执行的特点。
     A:Automatic(自动化)
     I:Independent(独立性)

     R:Repeatable(可重复) 




    【强制】单元测试应该是全自动执行的,并且非交互式的。测试框架通常是定期执行的,执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测 试中不准使用 System.out 来进行人肉验证,必须使用 assert 来验证。

    【强制】保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护,单元测试用例之间 决不能互相调用,也不能依赖执行的先后次序。
    反例:method2 需要依赖 method1 的执行,将执行结果做为 method2 的输入。

    【强制】对于单元测试,要保证测试粒度足够小,有助于精确定位问题。单测粒度至多是类级别,一般是方法级别。 
    说明:只有测试粒度小才能在出错时尽快定位到出错位置。单测不负责检查跨类或者跨系统的 交互逻辑,那是集成测试的领域。

    【强制】核心业务、核心应用、核心模块的增量代码确保单元测试通过。 
    说明:新增代码及时补充单元测试,如果新增代码影响了原有单元测试,请及时修正。

    【推荐】单元测试的基本目标:语句覆盖率达到 70%;核心模块的语句覆盖率和分支覆盖率都 要达到 100%
    说明:在工程规约的应用分层中提到的 DAO 层,Manager 层,可重用度高的 Service,都应该 进行单元测试。

    【推荐】编写单元测试代码遵守 BCDE 原则,以保证被测试模块的交付质量。
     B:Border,边界值测试,包括循环边界、特殊取值、特殊时间点、数据顺序等。
    C:Correct,正确的输入,并得到预期的结果。
     D:Design,与设计文档相结合,来编写单元测试
     E:Error,强制错误信息输入(如:非法数据、异常流程、非业务允许输入等),并得 到预期的结果。

    【推荐】和数据库相关的单元测试,可以设定自动回滚机制,不给数据库造成脏数据。或者 对单元测试产生的数据有明确的前后缀标识。
    正例:在 RDC 内部单元测试中,使用 RDC_UNIT_TEST_的前缀标识数据。

    【推荐】在设计评审阶段,开发人员需要和测试人员一起确定单元测试范围,单元测试最好 覆盖所有测试用例(UC)。

    【推荐】单元测试作为一种质量保障手段,不建议项目发布后补充单元测试用例,建议在项 目提测前完成单元测试。

    【参考】不要对单元测试存在如下误解:
     那是测试同学干的事情。本文是开发手册,凡是本文内容都是与开发同学强相关的。
    单元测试代码是多余的。汽车的整体功能与各单元部件的测试正常与否是强相关的。 
    单元测试代码不需要维护。一年半载后,那么单元测试几乎处于废弃状态。
     单元测试与线上故障没有辩证关系。好的单元测试能够最大限度地规避线上故障。

    MySQL开发规范

    建表规约

    【规范】表达是与否概念的字段,必须使用 is_xxx 的方式命名,数据类型是 unsigned tinyint ( 1表示是,0表示否),此规则同样适用于odps建表。 说明:任何字段如果为非负数,必须是 unsigned。

    【规范】表名、字段名必须使用小写字母或数字;禁止出现数字开头,禁止两个下划线中间只 出现数字。数据库字段名的修改代价很大,因为无法进行预发布,所以字段名称需要慎重考虑。
    正例:getter_admin,task_config,level3_name
    反例:GetterAdmin,taskConfig,level_3_name

    【规范】唯一索引名为 uk_字段名;普通索引名则为 idx_字段名。

    【规范】小数类型为 decimal,禁止使用 float 和 double。
    说明:float 和 double 在存储的时候,存在精度损失的问题,很可能在值的比较时,得到不 正确的结果。如果存储的数据范围超过 decimal 的范围,建议将数据拆成整数和小数分开存储

    【规范】如果存储的字符串长度几乎相等,使用 char 定长字符串类型。

    【效率】varchar 是可变长字符串,不预先分配存储空间,长度不要超过 5000,如果存储长 度大于此值,定义字段类型为 text,独立出来一张表,用主键来对应,避免影响其它字段索 引效率。

    【规范】表的命名最好是加上“业务名称_表的作用”。
    正例:tiger_task / tiger_reader / mpp_config

    【规范】库名与应用名称尽量一致。

    【规范】如果修改字段含义或对字段表示的状态追加时,需要及时更新字段注释。

    【效率】字段允许适当冗余,以提高性能,但是必须考虑数据同步的情况。冗余字段应遵循:
    1)不是频繁修改的字段。
    2)不是 varchar 超长字段,更不能是 text 字段。 正例:商品类目名称使用频率高,字段长度短,名称基本一成不变,可在相关联的表中冗余存 储类目名称,避免关联查询。

    【效率】单表行数超过 500 万行或者单表容量超过 2GB,才推荐进行分库分表。 说明:如果预计三年后的数据量根本达不到这个级别,请不要在创建表时就分库分表。

    【效率】合适的字符存储长度,不但节约数据库表空间、节约索引存储,更重要的是提升检 索速度
    正例:人的年龄用 unsigned tinyint(表示范围 0-255,人的寿命不会超过 255 岁);海龟 就必须是 smallint,但如果是太阳的年龄,就必须是 int;如果是所有恒星的年龄都加起来, 那么就必须使用 bigint。

    索引规约

    【效率】业务上具有唯一特性的字段,即使是组合字段,也必须建成唯一索引。
    说明:不要以为唯一索引影响了 insert 速度,这个速度损耗可以忽略,但提高查找速度是明 显的;另外,即使在应用层做了非常完善的校验和控制,只要没有唯一索引,根据墨菲定律, 必然有脏数据产生

    【规范】超过三个表禁止 join。需要 join 的字段,数据类型保持绝对一致;多表关联查询 时,保证被关联的字段需要有索引。
    说明:即使双表 join 也要注意表索引、SQL 性能。

    【规范】在 varchar 字段上建立索引时,必须指定索引长度,没必要对全字段建立索引,根据 实际文本区分度决定索引长度。
    说明:索引的长度与区分度是一对矛盾体,一般对字符串类型数据,长度为 20 的索引,区分 度会高达 90%以上,可以使用 count(distinct left(列名, 索引长度))/count(*)的区分度 来确定。

    【规范】页面搜索严禁左模糊或者全模糊,如果需要请走搜索引擎来解决。
    说明:索引文件具有 B-Tree 的最左前缀匹配特性,如果左边的值未确定,那么无法使用此索 引。

    【规范】如果有 order by 的场景,请注意利用索引的有序性。order by 最后的字段是组合 索引的一部分,并且放在索引组合顺序的最后,避免出现 file_sort 的情况,影响查询性能。
    正例:where a=? and b=? order by c; 索引:a_b_c
    反例:索引中有范围查找,那么索引有序性无法利用,如:WHERE a>10 ORDER BY b; 索引 a_b 无法排序。

    【效率】利用覆盖索引来进行查询操作,来避免回表操作。
    说明:如果一本书需要知道第 11 章是什么标题,会翻开第 11 章对应的那一页吗?目录浏览 一下就好,这个目录就是起到覆盖索引的作用。 正例:能够建立索引的种类:主键索引、唯一索引、普通索引,而覆盖索引是一种查询的一种 效果,用explain的结果,extra列会出现:using index。

    【效率】利用延迟关联或者子查询优化超多分页场景
    说明:MySQL 并不是跳过 offset 行,而是取 offset+N 行,然后返回放弃前 offset 行,返回 N 行,那当 offset 特别大的时候,效率就非常的低下,要么控制返回的总页数,要么对超过 特定阈值的页数进行 SQL 改写。
    正例:先快速定位需要获取的 id 段,然后再关联:(优化在可以少查表1的很多字段
    SELECT a.* FROM 表 1 a, (select id from 表 1 where 条件 LIMIT 100000,20 ) b where a.id=b.id

    【效率】SQL 性能优化的目标:至少要达到 range 级别,要求是 ref 级别,如果可以是 consts 最好。
    说明:
    1)consts 单表中最多只有一个匹配行(主键或者唯一索引),在优化阶段即可读取到数据。
    2)ref 指的是使用普通的索引(normal index)。
    3)range 对索引进行范围检索。
    反例:explain 表的结果,type=index,索引物理文件全扫描,速度非常慢,这个 index 级 别比较 range 还低,与全表扫描是小巫见大巫。

    【规范】建组合索引的时候,区分度最高的在最左边
    正例:如果 where a=? and b=? ,a 列的几乎接近于唯一值,那么只需要单建 idx_a 索引即 可。
    说明:存在非等号和等号混合判断条件时,在建索引时,请把等号条件的列前置。如:where a>? and b=? 那么即使 a 的区分度更高,也必须把 b 放在索引的最前列

    【说明】创建索引时避免有如下极端误解:
    1)误认为一个查询就需要建一个索引。
    2)误认为索引会消耗空间、严重拖慢更新和新增速度。
    3)误认为唯一索引一律需要在应用层通过“先查后插”方式解决。

    SQL规约

    【规范】不要使用 count(列名)或 count(常量)来替代 count(*),count(*)就是 SQL92 定义 的标准统计行数的语法,跟数据库无关,跟 NULL 和非 NULL 无关。
    说明:count(*)会统计值为 NULL 的行,而 count(列名)不会统计此列为 NULL 值的行。

    【说明】count(distinct col) 计算该列除 NULL 之外的不重复数量。注意 count(distinct col1, col2) 如果其中一列全为NULL,那么即使另一列有不同的值,也返回为0。

    【说明】当某一列的值全是 NULL 时,count(col)的返回结果为 0,但 sum(col)的返回结果为 NULL,因此使用 sum()时需注意 NPE 问题。
    正例:可以使用如下方式来避免sum的NPE问题:SELECT IF(ISNULL(SUM(g)),0,SUM(g)) FROM table;

    【说明】使用 ISNULL()来判断是否为 NULL 值。注意:NULL 与任何值的直接比较都为 NULL。
    说明:
    1) NULL<>NULL的返回结果是NULL,而不是false。
    2) NULL=NULL的返回结果是NULL,而不是true。
    3) NULL<>1的返回结果是NULL,而不是true。

    【规范】不得使用外键与级联,一切外键概念必须在应用层解决
    说明:(概念解释)学生表中的 student_id 是主键,那么成绩表中的 student_id 则为外键。 如果更新学生表中的 student_id,同时触发成绩表中的 student_id 更新,则为级联更新。外键与级联更新适用于单机低并发,不适合分布式、高并发集群;级联更新是强阻塞,存在数 据库更新风暴的风险;外键影响数据库的插入速度。

    【规范】数据订正时,删除和修改记录时,要先 select,避免出现误删除,确认无误才能执行更新语句。

    【效率】in 操作能避免则避免,若实在避免不了,需要仔细评估 in 后边的集合元素数量,控制在 1000 个之内。(可以用用 EXISTS ,NOT EXISTS 或 JOIN代替)

    【规范】如果有全球化需要,所有的字符存储与表示,均以 utf-8 编码,那么字符计数方法 注意:
    说明:
    SELECT LENGTH(“轻松工作”); 返回为12
    SELECT CHARACTER_LENGTH(“轻松工作”); 返回为4 如果要使用表情,那么使用 utfmb4 来进行存储,注意它与 utf-8 编码的区别。

    【规范】TRUNCATE TABLE 比 DELETE 速度快,且使用的系统和事务日志资源少,但 TRUNCATE无事务且不触发 trigger,有可能造成事故,故不建议在开发代码中使用此语句
    说明:TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同。

    ORM规约

    【规范】POJO 类的 boolean 属性不能加 is,而数据库字段必须加 is_,要求在 resultMap 中 进行字段与属性之间的映射。
    说明:参见定义 POJO 类以及数据库字段定义规定,在 sql.xml 增加映射,是必须的。

    【安全】配置XML文件时注意SQL注入问题。

    【规范】不允许直接拿 HashMap 与 Hashtable 作为查询结果集的输出。

    【强制】更新数据表记录时,必须同时更新记录对应的 gmt_modified 字段值为当前时间。

    【规范】不要写一个大而全的数据更新接口,传入为 POJO 类,不管是不是自己的目标更新字 段,都进行 update table set c1=value1,c2=value2,c3=value3; 这是不对的。执行 SQL 时,尽量不要更新无改动的字段,一是易出错;二是效率低;三是 binlog 增加存储。

    【规范】@Transactional 事务不要滥用。事务会影响数据库的 QPS,另外使用事务的地方需 要考虑各方面的回滚方案,包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。

    工程规约


    【说明】图中默认上层依赖于下层,箭头关系表示可直接依赖,如:开放接口层可以依赖于Web 层,也可以直接依赖于 Service 层,依此类推。
     开放接口层:可直接封装 Service接口暴露成 RPC 接口;通过 Web 封装成 http 接口;网关控 制层等
     终端显示层:各个端的模板渲染并执行显示层。当前主要是 velocity 渲染,JS 渲染,JSP 渲 染,移动端展示层等。
     Web 层:主要是对访问控制进行转发,各类基本参数校验,或者不复用的业务简单处理等。(Controller)
     Service 层:相对具体的业务逻辑服务层。
     Manager 层:通用业务处理层,它有如下特征:
    1) 对第三方平台封装的层,预处理返回结果及转化异常信息;
    2) 对Service层通用能力的下沉,如缓存方案、中间件通用处理;
    3) 与DAO层交互,对DAO的业务通用能力的封装。
     DAO 层:数据访问层,与底层 MySQL、Oracle、Hbase 进行数据交互。
     外部接口或第三方平台:包括其它部门 RPC 开放接口,基础平台,其它公司的 HTTP 接口。

    【规范】(分层异常处理规约)在 DAO 层,产生的异常类型有很多,无法用细粒度的异常进 行catch,使用catch(Exception e)方式,并throw new DAOException(e),不需要打印日志,因为日志在 Manager/Service 层一定需要捕获并打到日志文件中去,如果同台服务器 再打日志,浪费性能和存储。在 Service 层出现异常时,必须记录出错日志到磁盘,尽可能带 上参数信息,相当于保护案发现场。如果 Manager 层与 Service 同机部署,日志方式与 DAO 层处理一致,如果是单独部署,则采用与 Service 一致的处理方式。Web 层绝不应该继续往上抛异常,因为已经处于顶层,如果意识到这个异常将导致页面无法正常渲染,那么就应该直接跳转到友好错误页面,加上用户容易理解的错误提示信息。开放接口层要将异常处理成错误码 和错误信息方式返回。

    【规范】分层领域模型规约:
     DO(Data Object):与数据库表结构一一对应,通过 DAO 层向上传输数据源对象。(Entity)
     DTO(Data Transfer Object):数据传输对象,Service 和 Manager 向外传输的对象。
     BO(Business Object):业务对象。可以由 Service 层输出的封装业务逻辑的对象。
     QUERY:数据查询对象,各层接收上层的查询请求。注:超过 2 个参数的查询封装,禁止 使用 Map 类来传输。
     VO(View Object):显示层对象,通常是 Web 向模板渲染引擎层传输的对象。

    服务器规约

    【效率】高并发服务器建议调小 TCP 协议的 time_wait 超时时间。
    说明:操作系统默认 240 秒后,才会关闭处于 time_wait 状态的连接,在高并发访问下,服务器端会因为处于 time_wait 的连接数太多,可能无法建立新的连接,所以需要在服务器上 调小此等待值。
    正例:在 linux 服务器上请通过变更/etc/sysctl.conf 文件去修改该缺省值(秒):
    net.ipv4.tcp_fin_timeout = 30

    【效率】调大服务器所支持的最大文件句柄数(File Descriptor,简写为fd)。
    说明:主流操作系统的设计是将 TCP/UDP 连接采用与文件一样的方式去管理,即一个连接对 应于一个 fd。主流的 linux 服务器默认所支持最大 fd 数量为 1024,当并发连接数很大时很 容易因为 fd 不足而出现“open too many files”错误,导致新的连接无法建立。 建议将 linux 服务器所支持的最大句柄数调高数倍(与服务器的内存数量相关)。

    【规范】给 JVM 设置-XX:+HeapDumpOnOutOfMemoryError 参数,让 JVM 碰到 OOM 场景时输出 dump 信息。
    说明:OOM 的发生是有概率的,甚至有规律地相隔数月才出现一例,出现时的现场信息对查错 非常有价值。

    【规范】服务器内部重定向使用 forward;外部重定向地址使用 URL 拼装工具类来生成,否则 会带来 URL 维护不一致的问题和潜在的安全风险。

    安全规约

    【安全】隶属于用户个人的页面或者功能必须进行权限控制校验。
    说明:防止没有做水平权限校验就可随意访问、操作别人的数据,比如查看、修改别人的订单。

    【安全】用户敏感数据禁止直接展示,必须对展示数据脱敏。
    说明:查看个人手机号码会显示成:158****9119,隐藏中间 4 位,防止隐私泄露。

    【安全】用户输入的 SQL 参数严格使用参数绑定或者 METADATA 字段值限定,防止 SQL 注入, 禁止字符串拼接 SQL 访问数据库。

    【安全】用户请求传入的任何参数必须做有效性验证。
    说明:忽略参数校验可能导致:
     page size 过大导致内存溢出
     恶意 order by 导致数据库慢查询
     任意重定向
     SQL 注入
     反序列化注入
     正则输入源串拒绝服务 ReDoS
    说明:Java 代码用正则来验证客户端的输入,有些正则写法验证普通用户输入没有问题, 但是如果攻击人员使用的是特殊构造的字符串来验证,有可能导致死循环的效果

    【安全】禁止向 HTML 页面输出未经安全过滤或未正确转义的用户数据。

    【安全】表单、AJAX 提交必须执行 CSRF 安全过滤。
    说明:CSRF(Cross-site request forgery)跨站请求伪造是一类常见编程漏洞。对于存在 CSRF 漏洞的应用/网站,攻击者可以事先构造好 URL,只要受害者用户一访问,后台便在用户 不知情情况下对数据库中用户参数进行相应修改。

    【安全】在使用平台资源,譬如短信、邮件、电话、下单、支付,必须实现正确的防重放限制, 如数量限制、疲劳度控制、验证码校验,避免被滥刷、资损。
    说明:如注册时发送验证码到手机,如果没有限制次数和频率,那么可以利用此功能骚扰到其 它用户,并造成短信平台资源浪费。

    【安全】发贴、评论、发送即时消息等用户生成内容的场景必须实现防刷、文本内容违禁词过 滤等风控策略。
                </div>
                    </div>
    
    展开全文
  • 开发规范与要求

    2019-01-08 22:29:00
    参考网址:https://wenku.baidu.com/view/c05e9188541810a6f524ccbff121dd36a32dc4e2.html 目的 1)养成良好的编程习惯。 2)写出清楚、易懂、易维护的程序代码。 3)提高软件质量与生产率。...1)必须...

    参考网址:https://wenku.baidu.com/view/c05e9188541810a6f524ccbff121dd36a32dc4e2.html

    目的

    1)养成良好的编程习惯。
    
    2)写出清楚、易懂、易维护的程序代码。
    
    3)提高软件质量与生产率。
    
    4)减少软件编码中的不必要的错误。
    
    5)提供完整的软件产品编码和文档。
    

     

    要求

    1)必须严格执行本规范以确保源代码的可读性及可维护性。
    
    2)所有的程序文件都必须有注释文字,并严格按照本规范中的“注释规范” 书写。
    
    3)编码必须使用标准英文单词,不允许使用中文拼音。
    
    4)如果有名词,必须使用单数形式。
    
    5)使用大小写混合格式,将连接的几个单词首字母大写,除常数变量和模块级变量(m_*)外避免使用下划线。
    
    6)命名必须在3至20个字母以内。
    
    7)尽量避免使用缩写,如果必须使用,请参考本规范附录的缩写范例。
    

     具体内容请参考网址:https://wenku.baidu.com/view/c05e9188541810a6f524ccbff121dd36a32dc4e2.html

     

      

     

    转载于:https://www.cnblogs.com/linuxws/p/10241818.html

    展开全文
  • 开发规范

    2018-10-30 11:29:46
    一、背景  随着公司的业务发展,项目越来越多,越来越大,复杂性也越来越高。查找一个BUG变得越发抓狂;新人熟悉一块代码也变得越发困难。有的时候顺手写下的一行充满坏...二、必需要有规范  这是个老生长谈的话...

    一、背景

      随着公司的业务发展,项目越来越多,越来越大,复杂性也越来越高。查找一个BUG变得越发抓狂;新人熟悉一块代码也变得越发困难。有的时候顺手写下的一行充满坏味道的代码,可能当时不会出现什么影响,而且当事人也十分清楚自己写的东西。但是,当日积月累之后,这种坏代码越来越多,整个项目就变得混乱不堪,牵一发而动全身,各种错误,修复了这影响了那。

     

    二、必需要有规范

      这是个老生长谈的话题,要解决前面说的这些情况,必须要有一个规范来进行约束。不以规矩不成方圆,而且,这些规范必须也要有比较持续稳定的代码审核机制来支持。一个公司、团队值不值得去做这些,这是后话,这里不讨论。今天我们只各自阐明一下个人的建议和看法。

     

    三、哪些才是合理的规范

      以下这些是自己从网上和实际开发经历中搜罗的一些开发规范,其中不乏一些已经被说得老掉牙的东西,在这里算是一起重温一下。大家也可以发表一下自己的看法和觉得不合理的地方,一起交流交流。

     

    1.当一个条件判断(if,while)比较复杂,请写好注释。

     

    2.类中的方法放置顺序,按照public,internal,protected,private这样的顺序从上往下放置。并且public中把增删改方法放在最前,查询放在之后。

     

    3.字段的确定性尽可能的明确,且尽量按照如下顺序定义:const > readonly > 无

     

    4.一个方法中尽量只做一件事,并且命名可以知道这个方法做了什么【方法的命名配合类的命名可以尽可能的简洁】

    优点: (1)避免进行重复造轮子,出现一些重复的冗余的代码功能块。

     

    5.如果是一个比较重要或者复杂的方法,需要进行单元测试。

    优点: (1)确保系统中从未加入不正确的。不适合的变更;

                (2)并且在后期的维护中能够随意修改软件的一部分,而不必担心在修改的过程中破坏其他的东西。

                (3)这也是提升我们勇于进行修改优化旧代码的信心(不怕改了这边。那边出现问题的情况)。

     

    6.逻辑判断:一个方法里面不要嵌套太多的逻辑判断(if else或者switch case),嵌套达到三层的判断就可以考虑把其中的一部分独立成新方法调用,或者使用尽快返回的方式。

     

    7.生命周期:尽量缩短变量的存活周期,不是必须使用尽量不要使用全局变量

     

    8.变量跨度:变量声明定义开始到第一次使用该变量的代码行之间的行距尽可能短

     

    9.在操作非托管对象(如流操作)的时候尽量使用using(),这样不论在过程中是否发生异常,对象会在该代码段的最后自动释放占用资源,这样能防止手动漏写相关释放资源的代码,让程序自动回收处理。

     

    10.使用自描述的变量名和方法名(让命名变得有意义)

     

    11.声明方法的参数类型时,应尽量指定最弱的类型,最好是接口而不是基类。例如,如果要写一个方法来处理一组数据项,最好是用接口(比如IEnumerable<T>)来声明方法的参数,而不要用强数据类型(比如List<T>)或者更强的接口类型(比如ICollecion<T>或IList<T>)。

        原因是可传递的参数对象变多。当然,如果方法需要的是一个列表(而非仅仅是可枚举的对象),就应该将参数类型声明为IList<T>。但是,仍然要避免声明为List<T>。声明为IList<T>,调用者可传递实现了IList<T>的其他类型对象。

        同理,有基类的尽量使用基类。除非有特定原因。

        相反,返回的时候返回最强的类型。

     

    12.当一个方法的参数数量大于5个的时候,如果可能,声明一个单独的类进行封装。

     

    12.从数据库获取一个数据集合时,如果未获取到数据,那么返回一个空集合,不要返回null。

     

    13.对于一个方法超出了整个屏幕可以显示的范围,尽量去分割它(这时候屏幕大的优势就体现出来了)。

     

    14.尽可能的考虑到会出现异常的数据情景,多使用条件判断来处理异常,而不是更多的try catch。

     

    15.避免出现上帝类,每个类做其类名该做的事情。

     

    16.代码写完之后要习惯进行统一的格式化

     

    17.添加注释

        ① 类注释
        类的注释,需要描述类的功能、依赖和如何使用
        ②代码注释
        复杂的逻辑应当添加注释
        ③使用Region
        使用关键字region注释使代码更加整洁
        ④全局变量注释
        每个全局变量需要写注释
        ⑤程序流程变化注释
        switch, if, while 等条件判断地方必须写注释
        ⑥public方法注释
        public的方法体中的代码,需要写好详尽的注释

    展开全文
  • NET 开发规范(参考阿里开发规范),
  • 开发规范整理

    千次阅读 2018-08-02 16:09:13
    前端开发规范 编码规范 目录结构示意 开发在各个模块的src目录下进行,以system模块为例: containers 存放前端的页面 stores 存放前端页面所需的数据 assets 存放样式表和图片资源 common 存放...

    前端开发规范

    编码规范

    目录结构示意

    这里写图片描述

    开发在各个模块的src目录下进行,以system模块为例:

    containers 存放前端的页面
    stores 存放前端页面所需的数据
    assets 存放样式表和图片资源
    common 存放公共的配置文件
    components 存放的是公共的组件
    local 存放多语言文件

    命名

    (1)模块命名
    统一小写,比如模块system。

    (2)文件夹命名
    采用小驼峰命名法,第一个单词首字母小写,后续单词首字母大写,例如:文件夹messageTemplate。

    (3)文件命名
    js文件采用大驼峰命名法,单词首字母大写,例如:MessageTemplate.js。

    其它格式的文件采用小驼峰命名法,第一个单词首字母小写,后续单词首字母大写。

    代码注释

    (1)文件注释

        写在每个文件的开头
            /*
              author: xxx@xxx-china.com
              time: 2017-2-17
              feature: 模块功能
             */

    (2)函数功能注释

         写在每个函数的命名的前一行
            // 输出变量的值
            function print(name) {
                 ......
            }

    缩进

    首字母缩进两格

    修改webstorm开发工具的缩进方法

    这里写图片描述

    import文件

    Import 3个或者3个以下的组件可以不需换行,3个以上需换行写在每个文件的开头

    这里写图片描述

    嵌套

    嵌套严格遵循语义,避免非法错误的嵌套。子嵌套换行后,要比父级首字母多两个空格。

    这里写图片描述

    其他

    1)js中函数声明推荐使用箭头函数声明,不推荐使用function声明,箭头函数的 “=>”符号前后两端与字符用空格隔开。

    这里写图片描述
    (2)js变量声明采用const和let,const用于声明常量,let用于声明变量,不允许使用var。

    (3)项目中使用eslint进行js/html代码的自动校验,使用stylelint进行css/less代码的自动检验。

    不符合规范的话,项目编译过程中会自动报错,报错时根据报错提示去修改即可。

    (4)与组件状态无关的变量,不要写在组件的state下。

    (5)组件内部调用定时器(setTimeout/setInterval)后,一定要在组件被卸载时清除。

    可以使用组件的生命周期函数componentWillUnmount

    样式规范

    (1)页面边距

    页面内容内外边距默认制定为:“15px”。

    (2) pageHeader

    pageHeader中button文内容最好控制在两位,例如:创建客户端修改为创建; 存在两个button情况下:“创建”离 “客户端管理”30px,“刷新”离“创建”15px。

    (3)提示

    在需要对内容补充说明时使用“Popover”-气泡卡片组件;对图标icon的解释说明用“Tooltip”-提示组件

    (4)表格相关规范

    “Table”组件默认大小使用size=“middle”

    两张table之间间距“40px”

    table如果可编辑(创建)的字段不超过3个时,使用模态框“Model”组件弹出编辑(创建)页;如果超过三个字段,则新建界面处理

    后端开发规范

    编码规范

    命名规范

    (1)代码中的命名均不能以下划线或美元符号开始,也不能以下划线或美元符号结束

        反例:_name / __name / $name / name_ / name$ / name__ 
    

    (2)代码中的命名严禁使用拼音与英文混合的方式,更不允许直接使用中文的方式。

    说明:正确的英文拼写和语法可以让阅读者易于理解,避免歧义。注意,即使纯拼音命名方式 也要避免采用。

        正例:alibaba / taobao / youku / hangzhou 等国际通用的名称,可视同英文
        反例:DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量 = 3
    

    (3)类名使用 UpperCamelCase 风格,但以下情形例外:DO / BO / DTO / VO / AO / PO / UID 等

        正例: MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion 
        反例: macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion 
    

    (4)方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格,必须遵从驼峰形式。

        正例: localValue / getHttpMessage() / inputUserId 
    

    (5)常量命名全部大写,单词间用下划线隔开,力求语义表达完整清楚,不要嫌名字长。

        正例:MAX_STOCK_COUNT 
        反例:MAX_COUNT
    

    (6)抽象类命名使用 Abstract 或 Base 开头;

    异常类命名使用 Exception 结尾;

    测试类命名以它要测试的类的名称开始,以 Test 结尾。

    (7)类型与中括号紧挨相连来表示数组。

        正例:定义整形数组 int[] arrayDemo
        反例:在 main 参数中,使用 String args[]来定义。 
    

    (8)domain/dto类中布尔类型的变量,都不要加 is 前缀,否则部分框架解析会引起序列化错误。

    反例:定义为基本数据类型 Boolean isDeleted 的属性,它的方法也是 isDeleted(),RPC框架在反向解析的时候,“误以为”对应的属性名称是deleted,导致属性获取不到,进而抛出异常

    (9)包名统一使用小写,点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用 单数形式,但是类名如果有复数含义,类名可以使用复数形式。

    (10)杜绝完全不规范的缩写,避免望文不知义

    反例: AbstractClass“缩写”命名成 AbsClass;condition“缩写”命名成 condi,此类随 意缩写严重降低了代码的可阅读性。

    (11)接口类中的方法和属性不要加任何修饰符号(public 也不要加),保持代码的简洁 性,并加上有效的 Javadoc 注释。尽量不要在接口里定义变量,如果一定要定义变量,肯定是 与接口方法相关,并且是整个应用的基础常量。

        正例:接口方法声明 void commit();       
             接口基础常量 String COMPANY = "alibaba";
        反例:接口方法定义 public abstract void f(); 
    

    说明:JDK8 中接口允许有默认实现,那么这个 default 方法,是对所有实现类都有价值的默认实现。

    (12)如果模块、接口、类、方法使用了设计模式,在命名时需体现出具体模式。 说明:将设计模式体现在名字中,有利于阅读者快速理解架构设计理念。

        正例:public class OrderFactory;
                  public class ResourceObserver; 
    

    (13)枚举成员名称需要全大写,单词间用下划线隔开。

    (14)service/mapper层方法命名时,获取单个对象的方法用get做前缀,获取多个对象的方法用list做前缀。

    常量定义

    (1)不允许任何魔法值(即未经预先定义的常量)直接出现在代码中

        反例:String key = "Id#taobao_" + tradeId; 
                  cache.put(key, value); 
    

    (2)在 long 或者 Long 赋值时,数值后使用大写的 L,不能是小写的 l,小写容易跟数字 1 混淆,造成误解。
    说明:Long a = 2l; 写的是数字的 21,还是 Long 型的 2?

    (3)不要使用一个常量类维护所有常量,要按常量功能进行归类,分开维护。
    说明:大而全的常量类,杂乱无章,使用查找功能才能定位到修改的常量,不利于理解和维护。

    正例:缓存相关常量放在类 CacheConsts 下;系统配置相关常量放在类 ConfigConsts 下。

    (4)如果存在名称之外的延伸属性应使用 enum 类型,下面正例中的数字就是延伸信息,表示一年中的第几个季节。

        正例:public enum SeasonEnum {     
                        SPRING(1), SUMMER(2), AUTUMN(3), WINTER(4);     
                        private int seq;     
                        SeasonEnum(int seq){         
                              this.seq = seq;      
                        } 
                   } 
    

    代码格式

    (1)采用 4 个空格缩进,禁止使用 tab 字符。
    * 说明:如果使用 tab 缩进,必须设置 1 个 tab 为 4 个空格。IDEA 设置 tab 为 4 个空格时, 请勿勾选 Use tab character;(IDEA:File>setting>Editor>Code Style>Java>Tab size)*

    (2)单行字符数限制不超过 120 个,超出需要换行,换行时遵循如下原则:

    1) 第二行相对第一行缩进 4 个空格,从第三行开始,不再继续缩进,参考示例。
    2) 运算符与下文一起换行。
    3) 方法调用的点符号与下文一起换行。
    4) 方法调用中的多个参数需要换行时,在逗号后进行。
    5) 在括号前不要换行,见反例。

        正例: StringBuffer sb = new StringBuffer();  
                   sb.append("zi").append("xin")...      //   3)    
                        .append("huang")...  
                        .append("huang")...  
                        .append("huang"); 
    
         反例:StringBuffer sb = new StringBuffer();  
                   sb.append("zi").append("xin")...append      // 4)
                         ("huang");   
                  method(args1, args2, args3, ...      
                          , argsX);     // 5)
    

    (3)代码格式化,删除多余的import、全局变量、@Autowired注入

    说明:如果使用 tab 缩进,必须设置 1 个 tab 为 4 个空格。IDEA 设置 tab 为 4 个空格时, 请勿勾选 Use tab character;(IDEA:File>setting>Editor>Code Style>Java>Tab size)

    (4)全局常量或变量应全部接在一起,并放在代码的最开头,@Autowired也应紧接在一起,放在它们后面,中间避免无意义的空行影响维护效率,格式如下:

            private static final int A = 1;
            private static final String B = “a”;
            (空一行)
                @Autowired
            private MapperA mapperA;
                @Autowired
            private MapperB mapperB;
            (空一行)
            方法实现放在这里。
    

    OOP规约

    (1)避免通过一个类的对象引用访问此类的静态变量或静态方法,无谓增加编译器解析成本,直接用类名来访问即可。

    (2)所有的覆写方法,必须加@Override 注解。

    说明:getObject()与 get0bject()的问题。一个是字母的 O,一个是数字的 0,加@Override 可以准确判断是否覆盖成功。另外,如果在抽象类中对方法签名进行修改,其实现类会马上编 译报错。

    (3)不能使用过时的类或方法

    说明:java.net.URLDecoder 中的方法 decode(String encodeStr) 这个方法已经过时,应该使用双参数 decode(String source, String encode)。接口提供方既然明确是过时接口, 那么有义务同时提供新的接口;作为调用方来说,有义务去考证过时方法的新实现是什么。

    (4)Object 的 equals 方法容易抛空指针异常,应使用常量或确定有值的对象来调用 equals。

        正例:"test".equals(object); 
    

    (5)所有的相同类型的包装类对象之间值的比较,全部使用 equals 方法比较。

    说明:对于 Integer var = ? 在-128 至 127 范围内的赋值,Integer 对象是在 IntegerCache.cache 产生,会复用已有对象,这个区间内的 Integer 值可以直接使用==进行 判断,但是这个区间之外的所有数据,都会在堆上产生,并不会复用已有对象,这是一个大坑, 推荐使用 equals 方法进行判断。

    (6)关于基本数据类型与包装数据类型的使用标准如下:
    ** ▲所有的实体类(dto/domain)属性必须使用包装数据类型
    ▲所有的局部变量使用基本数据类型 **

    (7)当一个类有多个构造方法,或者多个同名方法,这些方法应该按顺序放置在一起

    (8)类内方法定义的顺序依次是:公有方法或保护方法 > 私有方法 > getter/setter 方法。

    说明:公有方法是类的调用者和维护者最关心的方法,首屏展示最好;保护方法虽然只是子类 关心,也可能是“模板设计模式”下的核心方法;而私有方法外部一般不需要特别关心,是一个 黑盒实现;因为承载的信息价值较低,所有 Service 和 DTO 的 getter/setter 方法放在类体最后。

    (9)使用索引访问用 String 的 split 方法得到的数组时,需做最后一个分隔符后有无内容的检查,否则会有抛 IndexOutOfBoundsException 的风险。

                   String str = "a,b,c,,";  
                   String[] ary = str.split(",");  
                   // 预期大于 3,结果是 3 
                   System.out.println(ary.length); 
    

    (10)循环体内,字符串的连接方式,使用 StringBuilder 的 append 方法进行扩展

    说明:下例中,反编译出的字节码文件显示每次循环都会 new 出一个 StringBuilder 对象, 然后进行 append 操作,最后通过 toString 方法返回 String 对象,造成内存资源浪费。

        反例: String str = “start”;      
                   for (int I = 0; I < 100; i++) {          
                          str = str + “hello”;      
                   } 
    

    (11)类成员与方法访问控制从严,作用域要尽可能小,考虑实际情况选择public、protected和private。

    代码检查

    (1)CheckStyle
    CheckStyle是一个静态分析工具,可以按照预设的规范来检查源代码编写有哪些地方不合乎规范。
    可以从其官网http://checkstyle.sourceforge.net/ 中下载。官网中还提供了Checkstyle的相关文档,如配置文件、代码检查项等,内容比较丰富,覆盖面也较齐全。可依据自身需要,参考官网上的相关资料。

    (2)FindBugs
    FindBugs 是一个静态分析工具,它检查类或者 JAR 文件,将字节码与一组缺陷模式进行对比以发现可能的问题。有了静态分析工具,就可以在不实际运行程序的情况对软件进行分析。FindBugs可以显著的减少代码中潜在的问题。有助于提高最终交付代码的质量。

    (3)SonarQube
    SonarQube是一个用于代码质量管理的开源平台,用于管理源代码的质量,同时SonarQube还对大量的持续集成工具提供了接口支持,可以很方便地在持续集成中使用SonarQube。通过插件形式,可以支持包括java,C#,C/C++,PL/SQL,Cobol,JavaScrip,Groovy等等二十几种编程语言的代码质量管理与检测,针对不同的编程语言其所提供的分析方式也有所不同: 对于所有支持的编程语言,SonarQube 都提供源了代码的静态分析功能; 对于某些特定的编程语言SonarQube 提供了对编译后代码的静态分析功能。
    (IDEA:File->Settings->Plugins)

    其他规范

    (1)List与Map的正确使用方式,都必须指明类型,除非在泛型类中无法确定类型,若不定义类型将导致unchecked警告:

        List<Map<String, Object>> list = new ArrayList<>();
        Map<String, Object> map = new HashMap<>();
        public List<String> methodName() {}
    

    (2)判断List与Map是否为空请使用list.isEmpty() 或 !list.isEmpty(),而不要通过size()判断。

    (3)判断String是否为null或空字符串请使用StringUtils工具类的isEmpty和isNotEmpty,特别注意isNotEmpty不是isNoneEmpty,经常有手误引用了这个完全相反的方法。

    (4)不能在一行内批量定义数据,比如 int a, b=0; 应该换行分别定义。

    (5)所有的异常都不能直接使用Exception或RuntimeException,而应该使用HAP提供的HapException,或自定义异常类再抛出。

    (6)一个if中若只包含一个if,那么两个if应该合在一起,比如
    if (a>0) { if (b<0){}} 应该转为 if (a>0 && b<0) {}

    (7)//TODO 以及对代码块的注释应该在确定不再使用时去掉。

    (8)判断boolean变量时不应使用==true或==false,而是使用if (a) 和if(!a)
    判断Boolean对象时应该使用Boolean.TRUE.equals(a),因为if(a)当a为null会报空指针。

    (9)在Service上所有非@Override方法都必须为private,不应当向外暴露

    (10)在做null判断时它必须作为第一个条件,否则它要么永不触发要么在它之前已经出现空指针。比如if (a!= null && axxx) 时 a!= null 必须在第一个。

    (11)Map的正确遍历方法,不要使用keySet遍历:

    for (Map.Entry<String, Object> entry : map.entrySet()) { 
    String key = entry.getKey(); Object value = entry.getValue(); }
    

    (12)使用indexOf判断字符串是否包含时应当替换为a.contains(“b”) 或 !a.contains(“b”)。

    (13)若一个变量在声明后绝对会被赋值,那么就不需要给它赋初始值,比如:
    int a; if (x>0) { a=1 } else { a=2 } 在这里a绝对会被赋值,所以不需要给a赋null等初始值。

    (14)IP地址等根据环境动态变化的信息不应该出现在代码中,而应该配置在config.properties再在项目中用@Value引用,或从系统配置等地方获取。

    (15)全局变量名尽量避免使用PASSWORD或PWD关键字。

    (16)作为参数的变量名不应当使用无意义的字符串,比如var1或单个字母。

    (17)大量的if (equals)条件判断应当使用switch代替,有更高的效率和查重作用。

    (18)Service层实现类中所有涉及数据库的增删改的方法都必须带上以下注解:

        @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
    

    并且所在的类必须有@Transactional注解,注意千万不能用一个带有该注解的方法去调用另一个带有该注解的方法,会导致内部方法的事务不执行。

    (19)对于List的遍历,在不需要用到下标时,推荐使用for each,更直观且通用性更高。for each本质上就是对Iterator的封装,能用Iterator的尽量用for each,而 for int对于ArrayList来说有很高的效率,但对于LinkedList来说效率很低,通用性不高。

    异常日志

    异常处理

    (1)Java 类库中定义的可以通过预检查方式规避的
    RuntimeException 异常不应该通过 catch 的方式来处理,比如:NullPointerException,IndexOutOfBoundsException 等等。
    说明:无法通过预检查的异常除外,比如在解析字符串形式的数字时,不得不用catch NumberFormatException 来实现。

        正例:if (obj != null) {...} 
        反例:try { obj.method(); } catch (NullPointerException e) {…} 
    

    (2)异常不要用来做流程控制,条件控制。
    * 说明:异常设计的初衷是解决程序运行中的各种意外情况,且异常的处理效率比条件判断方式 要低很多*

    (3)catch 时请分清稳定代码和非稳定代码,稳定代码指的是无论如何不会出错的代码。 对于非稳定代码的 catch 尽可能进行区分异常类型,再做对应的异常处理。

    * 说明:对大段代码进行 try-catch,使程序无法根据不同的异常做出正确的应激反应,也不利于定位问题,这是一种不负责任的表现。 *

    正例:用户注册的场景中,如果用户输入非法字符,或用户名称已存在,或用户输入密码过于简单,在程序上作出分门别类的判断,并提示给用户。

    (4)捕获异常是为了处理它,不要捕获了却什么都不处理而抛弃之,如果不想处理它,请 将该异常抛给它的调用者。最外层的业务使用者,必须处理异常,将其转化为用户可以理解的内容。

    (5)finally 块必须对资源对象、流对象进行关闭,有异常也要做 try-catch.

    * 说明:如果 JDK7 及以上,可以使用 try-with-resources 方式。 *

    (6)不要在 finally 块中使用 return。

    * 说明:finally 块中的 return 返回后方法结束执行,不会再执行 try 块中的 return 语句。 *

    (7)捕获异常与抛异常,必须是完全匹配,或者捕获异常是抛异常的父类。

    * 说明:如果预期对方抛的是绣球,实际接到的是铅球,就会产生意外情况*

    (8)方法的返回值可以为 null,不强制返回空集合,或者空对象等,必须添加注释充分说明什么情况下会返回 null 值。

    * 说明:防止 NPE 是调用者的责任。即使被调用方法返回空集合或者空对象,对调用者来说,也并非高枕无忧,必须考虑到远程调用失败、序列化失败、运行时异常等场景返回 null 的情况。 *

    (9)防止 NPE,是程序员的基本修养,注意 NPE 产生的场景:

    1)返回类型为基本数据类型,return 包装数据类型的对象时,自动拆箱有可能产生 NPE。
    反例:public int f() { return Integer 对象}, 如果为 null,自动解箱抛 NPE。
    2)数据库的查询结果可能为 null。
    3)集合里的元素即使 isNotEmpty,取出的数据元素也可能为 null。
    4)远程调用返回对象时,一律要求进行空指针判断,防止 NPE。
    5)对于 Session 中获取的数据,建议 NPE 检查,避免空指针。
    6)级联调用 obj.getA().getB().getC();一连串调用,易产生 NPE。

    日志规范

    (1)在实际代码的编写中,不应直接使用日志系统输出(Log4j、Logback)中的API,而应依赖日志框架SLF4J中的API,有利于维护和各个类的日志处理方式的统一。

        引包:import org.slf4j.Logger;   import org.slf4j.LoggerFactory; 
        声明:private static final Logger logger = LoggerFactory.getLogger(Abc.class); 
    

    (2)尽量用英文来描述日志错误信息,如果日志中的错误信息用英文描述不清楚的话使用 中文描述即可,否则容易产生歧义。国际化团队或海外部署的服务器由于字符集问题,【强制】 使用全英文来注释和描述日志错误信息。

    (3)在输出日志方面,应遵循以下原则:

    1. 准确区分应该使用的日志级别。系统的日志输出级别会根据需要动态调整。非关键信息应该采用低级别输出,避免输出太多无用信息。关键信息应该高级别输出,确保不会遗漏。建议的级别如下:

      1. info级别,输出普通方法执行细节,接收的参数,返回的数据。
      2. warn级别,输出潜在的问题,但不包括致命错误。例如缺少指定参数,使用了默认参数。
      3. debug级别,输出系统、复杂模块初始化的步骤细节等,关键代码执行明细,也可以输出与业务相关的逻辑执行明细,相关数据等。 debug 级别日志是排查错误的重要依据,应尽可能输出有效的信息。
      4. error级别,只用于输出系统发生的错误。
    2. 记录异常时,不应该只记录 message,还应该记录堆栈详细内容,需要调用合适的方法,传入异常。

    3. 不能在代码中使用 System.out.println() 输出内容替代日志的功能。
    4. 避免无意义的输出,避免遗漏必要的信息。输出日志应考虑实际情况,输出一些有助于帮助系统排查错误,或者分析系统行为的内容。
    5. 禁止在日志中输出敏感信息,如密码,信用卡信息等。

    (4)常规业务逻辑记录日志

    常规业务逻辑通常在Service中完成,Service中的方法将由框架自动拦截,并记录执行概要。但具体的背部细节还需要开发者手动编码指定输出内容。

    目前自动完成的内容有:
    ▲ Service方法接收到的参数
    ▲ Service方法的返回值
    ▲ Service方法执行时间

    这些内容不需要开发者再手动输出,以免重复。

    当在 Service 中去调用其他不能被框架拦截的方法时,如果有必要,可以手动记录类似的执行概要。具体到方法内部的细节,可以自行划分步骤、关键点等,在这样的临界位置输出必要的信息,可以采用INFO或 DEBUG 级别输出。

    对于循环操作,需要特别注意,避免输出大量的日志内容。

    (5)异常记录
    框架有自动异常处理功能,可能以自动、统一的记录日志,保证不会重复、遗漏。当手动 try-catch捕获到异常时,有以下几种情况:
    ▲ 吞没该异常。视情况记录日志。
    ▲ 转换类型后继续抛出异常(或直接抛出)。此时可以只记录错误消息,而不必记录错误堆栈,详细错误将由后续异常捕获者处理。如果后续代码已经脱离框架控制范围,则应当记录堆栈明细。
    ▲ 处理异常,并继续抛出一个新异常(空堆栈)。视情况记录原始异常堆栈。
    ▲ 应当避免将一个异常在不同的地方重复记录。

    (6)日志打印格式:LOG.info(“xxxxx {} xxx {}”, a, b)用占位符代替字符串拼接;

    注释规范

    注释类型

    (1)Javadoc注释
    Javadoc块的基本格式如下所示:

    /**
     * The type Test.
     *
     * @author xxx.xxx @xxx-china.com
     */
    public class Test {
    
    /**
     * Instantiates a new Test.
     *
     * @param param    the param
     * @param username the username
     */
    public Test(String param, String username) {
        System.out.println(username + " is a " + param);
    }
    }
    

    基本格式为类名上标明该类的作用,并且使用@author 标明作者。方法上标注该方法的作用,使用@param 标明每个参数及其意思。
    可以使用javadoc工具生成,在生成的基础上适当的进行修改。

    (2)失效代码不使用注释
    完成后确认已失效的代码直接删除,不要使用//或/**/注释代码。

    (3)代码细节注释
    由//界定,专用于注释代码细节,即使有多行注释也仍然使用//,以便于和/**/区分开来。

    除了私有变量,不推荐使用行末注释。
    对于一些有比较复杂的逻辑,重要的以及难以理解的代码,需要使用注释。

    class MyClass {
        private int myField; //An end-line comment
    public void myMethod {
    //what to do
           if (condition1) {
    //condition commen
         ...
            } else {
        //else condition comment
              ...
            }
        }
    }
    

    注释内容

    (1)对于调用复杂的API尽量提供代码示例,示例代码 < pre >< /pre > 包裹
    (2)对于已知的Bug需要声明
    (3)在本函数中抛出的exception尽量用@throws说明。
    (4)代码质量不好但能正常运行,或者还没有实现的代码用//TODO:声明
    (5)与其“半吊子”英文来注释,不如用中文注释把问题说清楚。专有名词与关键字保持 英文原文即可

    反例:“TCP 连接超时”解释成“传输控制协议连接超时”,理解反而费脑筋

    (6)所有的枚举类型字段必须要有注释,说明每个数据项的用途。
    (7)类、类属性、类方法的注释必须使用 Javadoc 规范,使用/*内容/格式,不得使用 // xxx 方式。
    (8)在 IDE 编辑窗口中,Javadoc 方式会提示相关注释,生成 Javadoc 可以正确输出相应注 释;在 IDE 中,工程调用方法时,不进入方法即可悬浮提示方法、参数、返回值的意义,提高阅读效率

    说明:在 IDE 编辑窗口中,Javadoc 方式会提示相关注释,生成 Javadoc 可以正确输出相应注 释;在 IDE 中,工程调用方法时,不进入方法即可悬浮提示方法、参数、返回值的意义,提高 阅读效率。

    (9)所有的抽象方法(包括接口中的方法)必须要用 Javadoc 注释、除了返回值、参数、 异常说明外,还必须指出该方法做什么事情,实现什么功能

    * 说明:对子类的实现要求,或者调用注意事项,请一并说明*

    (10) 在注释中用 //FIXME 标记某代码是错误的,而且不能工作,需要及时纠正的情况。
    (11)代码修改的同时,注释也要进行相应的修改,尤其是参数、返回值、异常、核心逻辑 等的修改。

    数据库规范

    建表规范

    (1)表达是与否概念的字段,数据类型是 tinyint (1 表示是,0 表示否)。
    注意:domain 类中的任何布尔类型的变量,都不要加 is 前缀,所以,需要在< resultMap >设置 从 is_xxx 到 Xxx 的映射关系。数据库表示是与否的值,使用 tinyint 类型。

    正例:表达逻辑删除的字段名 is_deleted,1 表示删除,0 表示未删除。

    (2)表名、字段名必须使用小写字母或数字,禁止出现数字开头,禁止两个下划线中间只 出现数字。数据库字段名的修改代价很大,所以字段名称需要慎重考虑。

    说明:MySQL 在 Windows 下不区分大小写,但在 Linux 下默认是区分大小写。因此,数据库名、 表名、字段名,都不允许出现任何大写字母,避免节外生枝。

        正例:aliyun_admin,rdc_config,level3_name
        反例:AliyunAdmin,rdcConfig,level_3_name 
    

    (3)表名不使用复数名词

    * 说明:表名应该仅仅表示表里面的实体内容,不应该表示实体数量,对应于 DTO 类名也是单数形式,符合表达习惯。*

    (4)字段名禁用使用保留字,如 desc、range、match、delayed 等,请参考 MySQL 官方保留字。

    (5)主键索引名为 idx_< table name >pk;唯一索引名为 idx< table name >u< index number >;普通索引名则为idx< table name >n< index number >,其中< table name >是指表名去掉t<模块简写>的部分

        正例:idx_account_pk;idx_account_u1;idx_account_n1。 
    

    (6)小数类型为 decimal,禁止使用 float 和 double。

    * 说明:float 和 double 在存储的时候,存在精度损失的问题,很可能在值的比较时,得到不正确的结果。如果存储的数据范围超过 decimal 的范围,建议将数据拆成整数和小数分开存储。*

    (7)varchar 是可变长字符串,不预先分配存储空间,长度不要超过 5000,如果存储长度大于此值,定义字段类型为 text,独立出来一张表,用主键来对应,避免影响其它字段索引效率。

    (8)表的命名采用“t_< module >_< name(plural )>”

    ** 说明:< module >为规定好的模块名称的缩写(一般为两或三个字母的缩写)
    注意:表名应能够明确表达存储数据的含义,不要过于笼统。**

    (9)视图的命名规则:普通视图< module >< name >_v ; 多语言视图< module >< name >_vl

        正例:csh_transaction_account_v 、 gld_account_vl。
    

    (10)如果修改字段含义或对字段表示的状态追加时,需要及时更新字段注释。

    (11)英语是数据库对象命名的缺省语言,不允许在命名中使用拼音(模块名例外);除了模块名之外,命名尽量使用全称,除非长度不够;如果使用简称,也应按照一定的规范进行。

    (12)对于主键字段、who字段、扩展性字段和有效性字段的设计原则:
    ▲ 所有表数据都设计包含主键字段和who字段
    ▲对于业务数据表通常包括扩展性字段
    ▲对于基础设置性数据表通常都包括有效性字段

    (13)所有表数据的设计都包含processing_status(处理状态)和reference_source(数据来源)两个字段。

    processing_status 取值范围:created、updated和deleted。
    reference_source 取值为模块名称的缩写,比如系统管理模块为xt。

    (14)如果存储的字符串长度几乎相等,使用 char 定长字符串类型

    (15)不要使用外键与级联,一切外键概念必须在应用层解决。

    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)一般情况下,不要使用外键

    * 说明:使用外键会使删除和更新操作十分的麻烦。*

    (4)in 操作能避免则避免,若实在避免不了,需要仔细评估 in 后边的集合元素数量,控制在 1000 个之内

    (5)TRUNCATE TABLE 比 DELETE 速度快,且使用的系统和事务日志资源少,但 TRUNCATE 无事务且不触发 trigger,有可能造成事故,故不建议在开发代码中使用此语句

    * 说明:TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同。*

    展开全文
  • 目标: 明确项目组中需求管理人员,交互设计, 美工以及开发之间的工作输入输出产物。明确各岗位职责。 以免造成开发,产品经理以及项目经理之间理解不到位,沟通成本过高,返工造成资源浪费。 所有环节产生的文档都...
  • 开发规范真的很重要

    2020-04-25 18:25:09
    最近阿里巴巴的 Java 开发手册出了新版(可直接到 github alibaba-p3c 上获取相关资源哦),我就跟着这个事情说一下我对开发规范的理解吧。提起开发规范,我印象中最深的就...
  • 开发规范的目的是什么?

    千次阅读 2019-02-20 07:35:55
    Java开发规范中实体类的方法是开头单词小写,属性也是一样,采用的是驼峰命名,严格的来讲,这只是的推荐规范,但问题是这个规范形成的时候还没有目前的这种三层模式,因此这个规范中有些规定是不适合目前开发的,...
  • web前端开发规范文档,大牛级别,适合前端开发人员,非常经典。
  • Web前端开发规范手册 提高团队协作效率  便于前端开发以及后期优化维护  方便新进的成员快速上手  输出高质量的代码
  • web前端开发规范

    千次阅读 2018-05-22 17:49:07
    web前端开发规范麦子学院何虎老师的开发web前端开发规范课程笔记web前端开发规范的意义1、提高团队的协作能力 2、提高代码的复用利用率 3、可以写出质量更高,效率更好的代码 4、为后期维护提供更好的支持规范1、...
  • Web前端开发规范手册

    千次阅读 2019-07-16 14:18:49
    文章目录1 文件命名规则a.... 图片的命名原则c....网页制作细节 ---- head区代码规范2.网页制作细节 ---- 字体3.网页制作细节 ---- 链接4.网页制作细节 ---- 表格5.网页制作细节 ---- 下载速度6.网页制作细节 ---- ...
  • 最详细的WEB前端开发规范手册

    千次阅读 2019-05-09 17:11:39
    本文主要从以下几个方面来概述前端开发规范 1. 目录构建规范 2. 前端命名规范 3. 前端工作规范 4. 开发文档的书写规范 1. 前端目录构建规范 我们从命名原则、根目录、业务逻辑等方面进行目录构建 1.1 命名...
  • WEB前端开发规范

    千次阅读 2012-03-19 11:15:58
    WEB前端开发规范 规范目的  为提高团队协作效率, 便于后台人员添加功能及前端后期优化维护, 输出高质量的文档, 特制订此文档.本文档如有不对或者不合适的地方请及时提出, 经讨论决定后方可更改.   基本准则 ...
  • web前端开发规范,主要是针对css html 编码格式。内容不多,但是文档格式比较规范。
  • Web前端开发规范 : 文件命名规则

    千次阅读 2018-08-31 13:58:57
    转自 : ...   1.文件命名规则 1.1文件名称的命名规则 统一用小写的英文字母,数字和下划线的组合,不得包含汉字空格和特殊字符。 ...原则: 1)方便理解,见名之意 ... ind...
  • Web前端开发标准规范总结

    万次阅读 2018-07-15 07:32:40
    Web前端作为开发团队中不可或缺的一部分,需要按照相关规定进行合理编写(一部分不良习惯可能给自己和他人造成不必要的麻烦)。不同公司不同团队具有不同的规范和文档。下面是根据不同企业和团队的要求进行全面详细...
  • 11个web前端开发实战项目案例+源码!拿走就是了

    万次阅读 多人点赞 2019-07-25 22:11:00
    小白为大家收集了11个web前端开发,大企业实战项目案例+5W行源码!拿走玩去吧! 老规矩:转发+关注并私信小编:“资料”全部打包带走! 下面给大家简单介绍几个: 小米官网: 项目描述 首先选择小米官网为第...
  • web前端开发(一)—HTML基础

    万次阅读 多人点赞 2018-07-31 23:41:15
    web前端简介 什么是HTML? HTML标签 HTML基本结构 HTML 段落标签 HTML 换行标签 HTML标题 HTML 水平线 HTML注释 HTML 标签 HTML 列表标签 HTML表格 HTML超链接 HTML 图片 HTML表单 表单元素-文本、...
  • Web前端开发书籍推荐

    千次阅读 2018-11-02 17:11:14
    如何学习JavaScript,又如何使自己成为一个合格的前端工程师呢? 读书吧~相对于在网上学习,在项目中学习和跟着有经验的同事学习,书中有着相对完整的知识体系,每读一本好书都会带来一次全面的提高。而如果深一脚浅...
  • web 前端入坑第一篇:web前端到底是什么?有前途吗

    万次阅读 多人点赞 2016-08-01 14:49:20
    某货: “前几年前端开发人员鱼目混杂,技术参差不齐,相对学习起来不规范,导致> 前端开发人员聚集,所以现在前端工种和工资还是没得到普遍重视,但近2年来,> > HTML5、JS 的流行,让前端异常火爆,以后...
  • 移动前端开发与web前端开发的区别

    万次阅读 2017-10-11 16:39:26
    用最简单粗暴的方式来讲,就是用html + css + javascript来构建一个供人浏览的网页,其中又包括两个主要的分类:pc端网页开发以及移动端网页开发(很多时候被称为h5开发)。
  • Web前端开发的现状和未来

    热门讨论 2010-08-19 13:57:59
    《编写高质量代码--Web前端开发修炼之道》作者曹刘阳的讲座PPT,主要内容包括:1)前端的发展和现状;2)行业内前端的位置;3)前端的实际工作;4)面临的问题;5)未来的机遇;6)建议的修炼之路
  • Web前端开发环境搭建

    万次阅读 2016-05-22 15:17:56
    最近在学习前端开发,通过网上的查找资料和自身实践;完成了前端开发环境的简单搭建。但发现网上提供的搭建方法总有些不全,因此把自己的搭建过程分享一下,希望能为web开发入门者提供帮助,少走弯路。  搭建的...
  • WEB前端开发学习小结

    千次阅读 热门讨论 2015-08-27 22:18:54
    web开发没有任何基础的小小小菜鸟变为了一个菜鸟,虽然自己现在还是一个菜鸟,但是自己和半年前的自己对比进 步还是巨大的,因为现在的自己至少到了知道“是什么?”的阶段,对已项目中用到的知识还是比较熟悉的...
  • 快速入门Web前端开发

    万次阅读 多人点赞 2018-09-30 09:06:40
    入门标准很简单,就一条:达到能参与 Web 前端实际项目的开发水平。请注意,是实际项目,这就需要了解如今的实际项目开发都用了哪些技术栈。HTML/CSS/JavaScript 这三大基础技术栈肯定是需要掌握的,但要能参与实际...
  • 浅谈web前端开发

    万次阅读 多人点赞 2015-12-19 11:42:33
    第二:web前端开发正在向响应式和移动端方向大步迈进;第三:前端工程师其实就是编程技术人员,用一句话来形容“比UI设计懂技术,比技术人员更懂交互”,当然也有人说前端工程师是工程师中的设计师,是设计师中的...
  • 2019web前端开发视频教程资料(汇总整理)

    万次阅读 多人点赞 2019-08-19 16:27:25
    web前端开发视频教程学习资料,免费领!Web前端开发工程师,是从事Web前端开发工作的工程师。主要进行网站开发,优化,完善的工作。资料分享给自学web前端开发的朋友,坚持下去,一份付出一份收获,加油! 免费...
  • Web前端开发最佳实践

    千次下载 热门讨论 2015-02-27 16:38:35
    本书立足于Web前端开发的基础,介绍如何编写符合W3C规范、可维护性好且高性能的Web前端代码。 本书的主要内容和特色:  以W3C Web规范为基础展开讨论,介绍Web前端开发中的最佳实践方法及编码风格。为Web前端...
  • Web前端开发框架推荐

    万次阅读 2017-05-21 17:00:59
    原本写这篇文章想围绕着 CSS 框架来的,但因为目前界内比较流行并遍地开花的主要还是 JS+CSS 模式的框架,并且自己靠着一点 JS 功底,就想专门针对 CSS,所以最后来个大锅乱炖都大致聊聊。...

空空如也

1 2 3 4 5 ... 20
收藏数 974,892
精华内容 389,956
关键字:

开发规范