代码坏味道：不一致的代码

坏味道呈现形态

• 1.命名中的不一致
• 2.方案中的不一致
• 3.代码中的不一致

应对策略：

1. 团队统一编码方案

方案中的不一致，一方面是由于代码长期演化造成的，另一方面是项目中存在完成同样功能的程序库。无论是哪种原因，都需要团队先统一约定，保证所有人按照同一种方式编写代码。

2. 提取函数，将不同层次的内容放入不同函数中。

代码中的不一致常常是把不同层次的代码写在了一起，最典型的就是把业务层面的代码和实现细节的代码混在一起。

解决这种问题的方式，就是通过提取方法，把不同层次的代码放到不同的函数里，而这一切的前提还是分离关注点，这个代码问题的背后还是设计问题。

记住一句话：

保持代码在各个层面上的一致性。

坏味道示例：

1. 命名中的不一致

enum DistributionChannel {
    WEBSITE,
    KINDLE_ONLY,
    ALL
}

上面类似含义的代码应该有一致的名字，比如，很多团队里都会把业务写到服务层，各种服务的命名也通常都是 XXXService，像 BookService、ChapterService 等等。

而一旦出现了不一致的名字，通常都表示不同的含义，比如，对于那些非业务入口的业务组件，它们的名字就会不一样，会更符合其具体业务行为，像 BookSender ，它表示将作品发送到翻译引擎。

enum DistributionChannel {
    WEBSITE,
    KINDLE,
    ALL
}

2. 方案中的不一致

public String nowTimestamp() {
    DateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
    Date now = new Date();
    return format.format(now);
}

public String nowTimestamp() {
    LocalDateTime now = LocalDateTime.now()
    return now.format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"));
}

3. 代码中的层次不一致

public void createBook(final List bookIds) throws IOException {
    List books = bookService.getApprovedBook(bookIds)
    CreateBookParameter parameter = toCreateBookParameter(books)
    HttpPost post = createBookHttpRequest(parameter)
    httpClient.execute(post)
}

上面这段代码首先是获取审核通过的作品，这是一个业务动作，接下来的三行其实是在做一件事，也就是发送创建作品的请求。具体到代码上，这三行代码分别是创建请求的参数，根据参数创建请求，最后，再把请求发送出去。这三行代码合起来完成了一个发送创建作品请求这么一件事，而这件事才是一个完整的业务动作。

所以，这个函数里的代码并不在一个层次上，有的是业务动作，有的是业务动作的细节。理解了这一点，我们就可以把这些业务细节的代码提取到一个函数里：

public void createBook(final List bookIds) throws IOException {
    List books = bookService.getApprovedBook(bookIds)
    createRemoteBook(books)
}

private void createRemoteBook(List books) throws IOException {
    CreateBookParameter parameter = toCreateBookParameter(books)
    HttpPost post = createBookHttpRequest(parameter)
    httpClient.execute(post)
}

从结果上看，各自的语句都是在一个层次上了，能够分清楚代码处于不同的层次，这基本功还是分离关注点。

一说到分层，大多数人想到的只是模型的分层，很少有人会想到在函数的语句中也要分层。各种层次的代码混在一起，许多问题也就随之而来了，最典型莫过于我们之前讲过的长函数。

从本质上说，我们在做的依然是模型的分层，只不过，这次的出发点是函数的语句。这也是我一直强调的“分离关注点，越小越好”的意义所在。观察代码的粒度足够小，很多问题自然就会暴露出来。