代码规约

代码规约

命名规约

  1. 禁止拼音与英文混用
  2. 驼峰 DO,BO,DTO,VO,AO,UID等除外
  3. pojo类中的任何布尔类型的变量都不要加is前缀
  4. 不允许任何的魔法值
  5. Long复制用L大写

推荐规约：

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

OOP规约

  1. 覆盖方法@override
  2. 禁止在pojo类中，同时存在对应属性xxx的isXxx()方法和getXxx（）方法
  3. equals方法容易空指针，推荐使用jdk7引入的工具类：
    Object.equals()
  4. 所有整形包装类型对象之间值的比较，全部使用equal方法。-128-127缓存问题
    Long的缓存区间是多少？
  5. 浮点运算用BigDecimal
  6. foreach中对集合不要add，remove，用迭代器《concurrentModificationException异常分析》

并发

  1. 通过线程池使用线程
  2. 不允许使用Executors去创建
  3. 必须回收自定义的ThreadLocal变量，线程池场景下，线程经常被复用

逻辑控制

1.当switch括号内的变量类型为String并且此变量为外部参数时，必须先进行null判断，不会进入default,会抱空指针

日志

  1. 日志文件推荐至少保存15天。
  2. 日志字符串用占位符替换，不要拼接

注释

  1. 类，类属性，类方法的注视必须使用javadoc规范，使用/**内容*/格式，不得使用//xxx方式
  2. 慎注视掉代码，在上方详细说明，而不是简单地注释掉；如果无用，则删除

数据库规约

  1. 强制：表达是否概念的字段，必须使用is_xxx的方式命名，数据类型是unsigined tinyint(1表示是，0表示否)，此规则同样适用于odps建表。
  2. 禁止超过三个表进行join，需要join的字段，数据类型保持绝对一致；多表关联查询时，保证被关联的字段需要有索引
  3. 搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决
  4. 不要使用count(列用)或者count(常量)来替代count(),count()就是sql92定义的标准统计行数的语法，根据书库无关，跟null和非null无关。count(*)会统计值为null的行，而count(列名)不会统计此列卫null值的行
  5. count(distinct col)计算该列除null之外的不重复数量。注意 count(distinct col1,col2)如果其中一列全为null，那么即使另一列有不同的值，也返回为0
  6. 当某一列的值全是null时，count（col）的返回结果为0，但sum(col)的返回结果为null，因此使用sum()时需注意npe问题，解决：select if null(sum(col),0) from table;
  7. 使用ISNULL()来判断是否为null值
  8. 对于数据库中表记录的查询和变更。只要涉及多个表，都需要在列名前加表的别名进行限定。（多表存在同名字段）
  9. 在表查询中，一律不要使用*作为查询的字段列表，需要哪些字段必须明确写明。《B类电商中台交易下跌的故障案例》，增加查询分析器解析成本，增减字段容易与resultMap不一致，多余字段增加网络消耗，尤其是text类型的字段。
  10. Sql.xml配置中参数注意：#{},#param#不要使用${}此种方式容易出现sql注入
  11. 强制：业务上具有唯一特性的字段，即使是组合字段，也必须建成唯一索引，否则必然有脏数据产生
  12. 强制：表名不使用复数名词
  13. 表必备字段：id，gmt_create(date_time),gmt_modified(date_time)

单元测试规约

  1. 好的单元测试原则AIR:
    A:Automatic(自动化)
    I:Independent(独立性)
    R:Repeatable(可重复)

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

  3. 强制：核心业务，核心应用，核心模块的增量代码必须保证单元测试通过

  4. 推荐：单元测试的基本目标是语句覆盖率达到70%，核心及分支语句覆盖率达到100%

  5. 单元测试误解
开发也要写好单元测试
    单元测试也要维护好

设计规约

  1. 不要忽视uml，在需求分析阶段，如果与系统交互的user超过一类，并且相关的use case超过5个，使用用例图来表达更加清晰的结构化需求。参考《如何让你用用例图讲故事》

  2. 状态图：如果某个业务对象的状态超过3个，使用状态图来表达并且明确状态变化的各个触发条件。注意：状态图中的状态在代码中必须集中定义，状态扭转统一控制，环路状态的扭转一定要特殊说明。

  3. 时序图：如果系统中某个功能的调用链路上涉及对象超过3个，使用时序图来表达并明确各调用环节的输入与输出

  4. 类图：如果系统中模型类超过5个，并且存在复杂的依赖关系，使用类图来表达并且明确类之间的关系

  5. 活动图：如果系统中超过2个对象之间存在协作关系，并且需要表示复杂的处理流程，使用活动图来表示

设计模式原则

  1. 单一职则

  2. 里氏替换

  3. 依赖倒置

  4. 开闭原则

posted @ 2021-03-01 20:30  l2c  阅读(186)  评论(0)  编辑  收藏  举报