阿里Java开发手册

一、编程规约

(一)命名风格

1. 【强制】代码中的命名均不能以下划线或美元符号开始

也不能以下划线或美元符号结束。

反 例 :_name / name / n a m e / n a m e / n a m e name / 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

7. 【强制】类型与中括号紧挨相连来表示数组。

正例:定义整形数组 int[] arrayDemo;

反例:在 main 参数中,使用 String args[]来定义。

11. 【强制】杜绝完全不规范的缩写,避免望文不知义。

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

12.【推荐】为了达到代码自解释的目标,任何自定义编程元素在命名时,使用尽量完整的单词组合来表达。

正例:在 JDK 中,对某个对象引用的 volatile 字段进行原子更新的类名为:AtomicReferenceFieldUpdater。反例:常见的方法内变量为 int a;的定义方式。

13.【推荐】在常量与变量的命名时,表示类型的名词放在词尾,以提升辨识度。

正例:startTime / workQueue / nameList / TERMINATED_THREAD_COUNT

反例:startedAt / QueueOfWork / listName / COUNT_TERMINATED_THREAD

15.【推荐】接口类中的方法和属性不要加任何修饰符号

public 也不要加,保持代码的简洁性,并加上有效的 Javadoc 注释。尽量不要在接口里定义变量,如果一定要定义变量,确定与接口方法相关,并且是整个应用的基础常量。

正例:接口方法签名 void commit();

接口基础常量 String COMPANY = “alibaba”;

反例:接口方法定义 public abstract void f();

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

补充:抽象类和接口

抽象类:
1)抽象类不可以实例化,只能够用来继承
2)抽象类的子类应提供对其所有抽象方法的实现。如果子没有实现它的全部方法 ,可以将子类定义为抽象类
3)抽象类中可以包含非抽象的方法
4)抽象类的引用可指向子类的实例

public class Test {
    @org.junit.Test
    public void test1() {
        animal a = new dog();
        a.eat();
    }
}

abstract class animal {
    public int age;
    public double weight;

    void eat() {
        System.out.println("eat something");
    }
    
    abstract void move();
}

class dog extends animal {

    @Override
    void eat() {
        System.out.println("eat meat");
    }

    @Override
    void move() {
        
    }
}

接口:
1)接口用interface关键修饰。接口中所有的方法为抽象方法 。
2)接口中的变量都为常量,接口当中的常量,可以省略public static final ,注意:不写也照样表达这个意思。
3)接口不能实例化,只被实现,还能被接口继承
4)接口的实现类必须全部实现接口中的方法,如果不实现,可以将子类变成一个抽象类
5)接口可以多实现
6)接口可多继承
7)接口的引用指向实现类的实例

public interface ModelConfigDao {

    String database = Settings.DATABASE_TEST;
    String sql = "select auto_increment from information_schema.tables where table_schema='" + database + "' and table_name='model_config';";

    /**
     * 新建模型
     * @param modelConfig 模型配置信息
     * @return 插入行数
     */
    int insert(ModelConfig modelConfig);

    /**
     * 查询模型表
     * @param modelConfig 模型配置
     * @return 查询结果
     */
    List<ModelConfig> select(ModelConfig modelConfig);

    /**
     * 更新模型
     *
     * @param modelConfig 更新后的配置
     * @return 修改行数
     */
    int update(ModelConfig modelConfig);

    /**
     * 删除模型,实际是更新delete_time,并不是真正删除
     *
     * @param modelConfig 要删除的模型
     * @return 删除行数
     */
    int delete(ModelConfig modelConfig);

    /**
     * 获取下一个主键id
     * @return
     */
    @Select(value = sql)
    int getLastId();
}

(二)常量定义

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

反例:byte[] raw = Arrays.copyOfRange(partialKeyAscii, 0, 32);

正例:public static final int RAW_LENGTH = 32;
byte[] raw = Arrays.copyOfRange(partialKeyAscii, 0, RAW_LENGTH );

2.【推荐】不要使用一个常量类维护所有常量,要按常量功能进行归类,分开维护。

说明:大而全的常量类,杂乱无章,使用查找功能才能定位到修改的常量,不利于理解,也不利于维护。正例:缓存相关常量放在类 CacheConsts 下;系统配置相关常量放在类 ConfigConsts 下。

(三)代码格式

  1. if/for/while/switch/do 等保留字与括号之间都必须加空格。
  2. 任何二目、三目运算符的左右两边都需要加一个空格
  3. 采用 4 个空格缩进,禁止使用 tab 字符。
  4. 注释的双斜线与注释内容之间有且仅有一个空格。

总结:尽量消除所有黄色下划线提示。尽量消除所有 编码规约扫描 出的问题。

(四)OOP规约

三、单元测试

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

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

  • A:Automatic(自动化)
  • I:Independent(独立性)
  • R:Repeatable(可重复)

补充:junit使用

@BeforeClass:修饰的方法会在所有方法被调用前执行,且该方法时静态的,所以当测试类被加载后就接着运行它,而且在内存中他只会存在一份实例,他比较适合加载配置文件(针对所有测试,只执行一次 )

@AfterClass:所修饰的方法通常用来对资源管理,如关闭数据库连接(针对所有测试,只执行一次 )

@Before和@After 会在每个测试方法前后各执行一次

@Test:测试方法,在这里可以测试期望异常和超时时间

@Ignore:忽略的测试方法

import static org.junit.Assert.*;
 
import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
 
public class JunitFlowText {
 
	@BeforeClass
	public static void setUpBeforeClass() throws Exception {
	System.out.println("this is beforeClasss....");
	}
 
	@AfterClass
	public static void tearDownAfterClass() throws Exception {
		System.out.println("this is afterClasss....");
	}
 
	@Before
	public void setUp() throws Exception {
		System.out.println("this is brfore....");
	}
 
	@After
	public void tearDown() throws Exception {
		System.out.println("this is after....");
	}
 
	@Test
	public void test1() {
		System.out.println("this is test1....");
	}
	@Test
	public void test2() {
		System.out.println("this is test2....");
	}
}

补充:springboot单元测试

@Transactional
@RunWith(SpringRunner.class)
@SpringBootTest
// @Rollback(false)
public class UserDaoTest {

    @Autowired
    UserDao dao;

    @Test
    public void select() {
        User u = new User();
        u.setId(1);
        List<Map<String, Object>> res = dao.select(u);
        System.out.println(res);
    }
}

2.【强制】单元测试应该是全自动执行的,并且非交互式的。

测试用例通常是被定期执行的,执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测试中不准使用 System.out 来进行人肉验证,必须使用 assert 来验证。

补充:Java异常处理

在这里插入图片描述

Error:是程序中无法处理的错误,表示运行应用程序中出现了严重的错误。此类错误一般表示代码运行时JVM出现问题。通常有Virtual MachineError(虚拟机运行错误)、NoClassDefFoundError(类定义错误)等。比如说当jvm耗完可用内存时,将出现OutOfMemoryError。此类错误发生时,JVM将终止线程。非代码性错误。因此,当此类错误发生时,应用不应该去处理此类错误。

Exception::程序本身可以捕获并且可以处理的异常。

运行时异常(不受检异常):RuntimeException类极其子类表示JVM在运行期间可能出现的错误。编译器不会检查此类异常,并且不要求处理异常,比如用空值对象的引用(NullPointerException)、数组下标越界(ArrayIndexOutBoundException)。此类异常属于不可查异常,一般是由程序逻辑错误引起的,在程序中可以选择捕获处理,也可以不处理。

非运行时异常(受检异常):Exception中除RuntimeException极其子类之外的异常。编译器会检查此类异常,如果程序中出现此类异常,比如说IOException,必须对该异常进行处理,要么使用try-catch捕获,要么使用throws语句抛出,否则编译不通过。

public class NotebookNoteFoundExcepotion extends RuntimeException {
	private static final long serialVersionUID = 8307029916454948448L;

	public NotebookNoteFoundExcepotion() {
		super();
	}

	public NotebookNoteFoundExcepotion(String message, Throwable cause, boolean enableSuppression,
			boolean writableStackTrace) {
		super(message, cause, enableSuppression, writableStackTrace);
	}

	public NotebookNoteFoundExcepotion(String message, Throwable cause) {
		super(message, cause);
	}

	public NotebookNoteFoundExcepotion(String message) {
		super(message);
	}

	public NotebookNoteFoundExcepotion(Throwable cause) {
		super(cause);
	}
	
}

补充:Java断言 assert

断言是java的一种语句,它允许对程序提出一个判断(假设)。断言包含一个布尔表达式,在程序运行中它应该是真。断言用于确保程序的正确性,避免逻辑错误 。

import static org.hamcrest.Matchers.greaterThan;
import static org.junit.Assert.*;
import org.junit.*;

public class AssertTest {
    @Test
    public void test1() {
        Assert.assertTrue("我对了吗", 1 > 5);
        int[] a = new int[]{1, 2, 3};
        int[] b = new int[]{2, 3, 4};
        Assert.assertArrayEquals(a, b);
        Assert.assertThat("10大于5吗?", 10, greaterThan(5));
    }
}

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.【推荐】和数据库相关的单元测试,可以设定自动回滚机制

不给数据库造成脏数据。或者对单元测试产生的数据有明确的前后缀标识。

注:springboot会自动回滚,若不想回滚则添加 @Rollback(false) 注解

正例:在阿里巴巴企业智能事业部的内部单元测试中,使用 ENTERPRISE_INTELLIGENCE UNIT_TEST 的前缀来标识单元测试相关代码。

12.【推荐】对于不可测的代码在适当的时机做必要的重构

使代码变得可测,避免为了达到测试要求而书写不规范测试代码。

13.【推荐】在设计评审阶段

开发人员需要和测试人员一起确定单元测试范围,单元测试最好覆盖所有测试用例(UC)。

14.【推荐】单元测试作为一种质量保障手段

在项目提测前完成单元测试,不建议项目发布后补充单元测试用例。

15.【参考】为了更方便地进行单元测试,业务代码应避免以下情况

  • 构造方法中做的事情过多。
  • 存在过多的全局变量和静态方法。
  • 存在过多的外部依赖。
  • 存在过多的条件语句。

说明:多层条件语句建议使用卫语句、策略模式、状态模式等方式重构。

补充:卫语句

if(it == 活的){
    if(it == 人){
        if(it != 女人){
            return 不喜欢;
        } else {
            return 喜欢;
        }
    } else {
        return 不喜欢;
    }
} else {
    return 不喜欢;
}
// 改成卫语句
if (it != 活的){return 不喜欢}
if(it!=人){return 不喜欢}
if(it!=女人){return 不喜欢}
if(it == 女人 && it == 活的) {return 喜欢}
if(其他任何情况){return 不喜欢}

16.【参考】不要对单元测试存在如下误解

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

八、上线规约

1.git管理

  1. 合并分支时提交merge request。
  2. 开发前先拉取master分支,不支持从非master分支拉取代码。
    A提交merge request到master,B再拉取master,禁止B直接拉取A的代码。
  3. 周四集中统一代码,保持各分支代码一致性。
  4. 单元测试代码也需上传。
  5. 分支管理?功能分支
  6. master测试分支

补充:git常用命令

git add .
git commit -m 'xxx'
git push origin xxx分支
git checkout -b xxx
git reset --hard origin/master

2.代码review

定期代码review(两周/一个月一次),各自代码宣讲。

3.上线前功能测试

上线前进行集中功能测试,测试通过后发布。

九、常见问题

1.单元测试用main方法完成

2.命名下划线和驼峰混用

# Java中的驼峰命名映射为数据库中的下划线命名
mybatis.configuration.map-underscore-to-camel-case=true
<select id="getStudent" resultMap="getStudentRM">
  SELECT ID, Name, Age
    FROM TStudent
</select>
<resultMap id="getStudentRM" type="EStudnet">
  <id property="id" column="ID"/>
  <result property="studentName" column="Name"/>
  <result property="studentAge" column="Age"/>
</resultMap>

3.变量类型尽量用父类/接口类型

Map<String, String> map = new HashMap<>();
List<String> list = new LinkedList<>(); // ArrayList
Set<String> set = new HashSet<>();

4.equals()方法的使用

String name = "tom";
if ("tom".equals(name)) {
	System.out.println("hello");
}
public boolean equals(Object o) {
        if (this == o) {
            return true;
        }
        if (o == null || getClass() != o.getClass()) {
            return false;
        }

        User user = (User)o;

        if (!id.equals(user.id)) {
            return false;
        }
        if (!userName.equals(user.userName)) {
            return false;
        }
        return passWord.equals(user.passWord);
    }

5.包装类型相等判断用equals

补充:Java拆箱与装箱

public class Test {
    int a = 1;
    int b = 1;

    Integer c = 1; // 自动装箱
    Integer d = 1;

    Integer e = 200;
    Integer f = 200;
    int g = 200;
    
    @org.junit.Test
    public void test1() {
        System.out.println(a == b); // true
        System.out.println(c == d); // true
        System.out.println(e == f); // false
        System.out.println(e.equals(f)); // true
        System.out.println(a == c); // true
        System.out.println(e == g); // true,自动拆箱
        System.out.println(e.equals(g)); // true 自动装箱
    }
}
  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值