后端工程圣殿形象的崩塌以及重建

作为一个前端，似乎一直有点抬不起头。总是在圈子里被鄙视，什么：前端也是程序员？什么：JavaScript 工程太乱等等等等。我一直对后端工程心存敬畏，总之后端在我眼中一直是高大上的形象，但是最近我近距离深入接触了某公司的后端 Java 工程，三观彻底被毁了：一直鄙视我们前端的后端工程师们，搭出来的后端工程就这？心中一万匹马奔腾而过。在我原来的观念里，后端工程一直就像是圣殿般的存在，如今真正一看，却如同废墟。

自己一直想往全栈方向发展，于是决定在废墟中重建，虽然不能立即达到圣殿的级别，但是力求达到常见的前端工程水准。

缘起

后端接口一直调不通，后端同学总是说他那里是好的。我说开发环境调不通，他发来一堆 SQL 给我：你得在本地环境建数据呀。为了节省时间，我干脆在本地克隆了后端工程，开始近距离接触。一看，三观尽毁：

项目不能在本地一键启动

我接触过的所有前端项目，都会有一个 README，写清楚如何本地运行，尽管都是差不多的，尽管很简单，但都会注明。一般都会支持 yarn dev 或者 yarn start 等等一键运行命令。但是我打开的 java 工程，什么都没有。当然，能看出是基于 SpringBoot 的一个 maven 工程，于是 Googl 了一下 maven 工程的启动方式，试了一下 mvn bootRun 果然是各种报错。

重建方案

于是我通过各种错误提示，了解到了项目的依赖：mysql、redis 等等，就补充了一个 docker-compose.yaml 文件，在执行 mvn bootRun 之前，docker-compose up -d 一下，启动相关的依赖项。当然没有那么顺利，仍然有很多错误，详细的就不说了，心里窝火。最后的解决办法：

写一个初始数据库的脚本，并配置在 docker-compose.yaml 文件中，使得在 docker-compose up -d 时自动创建好需要的数据库
init.sql

CREATE DATABASE IF NOT EXISTS dbname;

USE dbname;

docker-compose.yaml

version: '3.3'

services:

  adminer:

    image: adminer:4.8.0

    restart: always

    ports:

      - 7777:8080

  db:

    image: mysql:5.7

    restart: always

    environment:

      MYSQL_DATABASE: 'dbname'

      MYSQL_USER: 'root'

      MYSQL_ROOT_PASSWORD: 'password'

    ports:

      - '3306:3306'

    command: --init-file /data/application/init.sql

    expose:

      - '3306'

    volumes:

      - my-db:/var/lib/mysql

      - ./init.sql:/data/application/init.sql

  redis:

    image: redis

    command: redis-server --requirepass 123456

    restart: always

    ports:

      - '6379:6379'

# Names our volume

volumes:

  my-db:

新建一个 local profile 文件，并配置好相关的本地环境变量

对于本地数据库连接配置，新建src/main/resources/db/datasource-local.yml文件，配置如下：

spring:

  datasource:

    driver-class-name: com.mysql.cj.jdbc.Driver

    hikari:

      max-lifetime: 1800000

      maximum-pool-size: 10

    type: com.zaxxer.hikari.HikariDataSource

    url: jdbc:mysql://localhost:3306/dbname?useUnicode=true&rewriteBatchedStatements=true&autoReconnect=true&failOverReadOnly=false&characterEncoding=UTF-8&useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai

    username: root

    password: password

对于本地 Redis 配置，新建 src/main/resources/redis/redis-local.yml 文件，配置如下：

spring:

  redis:

    host: localhost

    lettuce:

      pool:

        max-active: 100

        max-idle: 100

        max-wait: 6000

        min-idle: 50

    lock:

      host: localhost

      password: 123456

      port: 6379

    password: 123456

    port: 6379

    timeout: 5000

在 pom.xml 里新增一个 local profile：

...
<profiles>
        <profile>
            <id>local</id>
            <properties>
                <package.environment>local</package.environment>
            </properties>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
        </profile>
            ...
</profiles>
...

            增加 application-local.properties 文件：

env=local

server.port=8080

server.http2.enabled=true

新建一个 start.sh 文件，无非就是启动相关依赖，再利用 mvn bootRun 启动项目。总之封装成一个脚本文件，方便后续本地一键启动项目。

mvn clean install

docker-compose up -d

mvn bootRun

完全没有任何测试代码

这真是日了狗了。

我所见过的前端工程，测试占比并不多，由于前端 UI 测试代价比较大，变化多，所以很少会去写详细的自动化测试，但是会做好 file watch，一旦代码变化，界面也随之更新，所以也还好。但是对于公共逻辑，或者重要的组件，一般都是一个实现文件对应着一个测试文件，每个文件用来干什么，只要看下对应的测试文件就一目了然，比如：

但是我打开的 java 工程，看似很专业，分层分得很细，遵照了《领域驱动设计》的层次结构：

但是《领域驱动设计》中引入这个分层架构是为了方便自动化测试，并且让程序本身更加简单明了。显然这个项目工程，只是生硬照搬了分层结构，并没有实现《领域驱动设计》中引入这个结构的目的。

部分重建方案

对于新加的代码，必须添加测试。这对我来说很艰难，不太会用 java 写测试，但最终把测试加入了，每次把改动推到远程仓库前，会自动运行项目中的测试。对于这个我还没有形成一个通用的方案，只能记录一些零碎的心得。

@MockBean 可以解决测试实例的替换

对于一些依赖，在运行测试时需要控制住，这时候可以采用 @MockBean 将实际依赖替换成一个假的对象实例。前提是实现代码做到了依赖一个抽象，而不是具体的实例。

对于没有依赖接口，而是依赖特定实例实现的代码，可以增加一些 setter 以方便测试

比如这样的代码：

显然它对 HttpClient 的依赖没有使用依赖注入。应该有办法改造一下，但我还不会，于是给这个类增加了一个 setter 方法：

    publicvoidsetHttpClient(HttpClient client) {

        this.httpClient = client;

    }

然后在测试代码中，通过 @BeforeEach 对其内部 httpClient 进行替换：

    @BeforeEach

    voidinitialize() {

        mpService.setHttpClient(new MockHttpClient());

    }

当然，还可以在测试中不更改 HttpClient，而是更改对应的 HttpClient 要调用的远程端点，使用 MockServer 的方式，防止在测试中调用真正的远程端点。

@RunWith(SpringRunner.class)

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.None)

publicclassXXXTest {

    publicstatic MockWebServer mockBackEnd;

    @BeforeAll

    staticvoid setUp() throws IOException {

        mockBackEnd =new MockWebServer();

        mockBackEnd.start();

    }

    @AfterAll

    staticvoid tearDown() throws IOException {

        mockBackEnd.shutdown();

    }

    @BeforeEach

    void initialize() {

        String baseUrl =String.format("http://localhost:%s",

                mockBackEnd.getPort());

        mpService.setQrCodeCreateUrl(baseUrl +"/test");

    }

    @Autowired

    private MpService mpService;

    @Test

    void XXXTest() {

        MockResponse mockResponse =new MockResponse();

        mockResponse.setBody("{\"ticket\":\"gQH47joAAAAAAAAAASxodHRwOi8vd2VpeGluLnFxLmNvbS9xL2taZ2Z3TVRtNzJXV1Brb3ZhYmJJAAIEZ23sUwMEmm\n"+

                "3sUw==\",\"expire_seconds\":60,\"url\":\"http://weixin.qq.com/q/kZgfwMTm72WWPkovabbI\"}");

        mockResponse.addHeader("Content-Type", "application/json");

        mockBackEnd.enqueue(mockResponse);

        ...

        assertThat(...);

    }

总之，不要让测试产生真正的远程调用，要么 mock 自己使用的 HttpClient，对 sendRequest 方法进行打桩；要么 mock 这个远程 server，固定返回期待的 Response。

设计瑕疵

后端系统中所有的日期字段类型，全部设置成为了 Long 型，存储一个时间的秒数。这个让我非常不解，问下来的原因是时间的时区会带来问题……

我想不出日期时间格式会带来什么时区问题，就算有，采用 UTC 时间会怎样呢？总之目前的设计，导致编码不便，数据库查询不便，以及造测试数据时非常不方便（比如 Adminer 界面不会弹出日期时间选择框，而是一个数字输入框……）。

更加讽刺的是，这个设计号称能避免时区问题，结果偏偏带来了不应该有的时区问题：比如，我在调用后端接口创建某些资源时，由于业务逻辑限制开始时间和结束时间必须在同一天，我的前端明明传了同一天的时间给到后端，但后端就是一直报开始时间和结束时间不在同一天的错误！

最后查看后端代码，是这样写的：

LocalDate eventStartDate = eventStartTime ==null?null : Instant.ofEpochSecond(eventStartTime).atZone(ZoneId.systemDefault()).toLocalDate();

            LocalDate eventEndDate = eventEndTime ==null?null : Instant.ofEpochSecond(eventEndTime).atZone(ZoneId.systemDefault()).toLocalDate();

显然当前的 BUG 证明了系统的默认时区和用户真正使用的时区并不相同。为什么我倾向于直接采用日期时间类型，是因为日期时间类型在序列化时可以带上时区信息，比如 2021-05-31 00:00:00+8 代表了在东八区下 5 月 31 日的最开始时刻，但是它在 UTC 时间下，就是 5 月 30 日。

暂时的解决方案

由于直接将整个系统的时间设计从长整型改成日期时间型，工作量较大，我只能先修复了这个问题。修复可以通过把服务器的时区设置改成和用户的时区（东八区）相同，但是由于服务器的配置并没有代码化，我没有采用修改服务器设置。理想情况是一切基础设施也代码化，将一切系统知识采用文本记录并由 git 跟踪。

由于现在增加时区信息让前端传递不太合适（而且后期如果改成日期时间格式，并不需要前端单独传递时区信息），以及考虑到产品只面向中国用户，因此暂时在代码中将时区从默认改成了东八区, 不过，任何代码的改动，都添加了测试代码，以保证重构的安全。

-            LocalDate eventStartDate = eventStartTime == null ? null : Instant.ofEpochSecond(eventStartTime).atZone(ZoneId.systemDefault()).toLocalDate();

-            LocalDate eventEndDate = eventEndTime == null ? null : Instant.ofEpochSecond(eventEndTime).atZone(ZoneId.systemDefault()).toLocalDate();

+            LocalDate eventStartDate = eventStartTime == null ? null : Instant.ofEpochSecond(eventStartTime).atZone(ZoneId.of("Asia/Shanghai")).toLocalDate();

+            LocalDate eventEndDate = eventEndTime == null ? null : Instant.ofEpochSecond(eventEndTime).atZone(ZoneId.of("Asia/Shanghai")).toLocalDate();

                        if (eventEndDate != null && eventStartDate != null && !eventStartDate.equals(eventEndDate)) {

                return "场次开始时间和结束时间需要在同一天！";

            }

// 测试文件

import org.junit.jupiter.api.BeforeAll;

import org.junit.jupiter.api.BeforeEach;

import org.junit.jupiter.api.Test;

import java.time.ZoneId;

import java.util.TimeZone;

importstatic org.assertj.core.api.Assertions.assertThat;

importstatic org.junit.jupiter.api.Assertions.*;

classCampaignEventValidationUseCaseImplTest {

    private CampaignEventValidationUseCaseImpl sut;

    @BeforeEach

    void setUp() {

        sut =new CampaignEventValidationUseCaseImpl();

    }

    /**

     * BUG：开始时间选择 2021-05-20 00:05，结束时间选择 2021-05-20 23:55，校验报错说：场次开始时间和结束时间需要在同一天

     */

    @Test

    void validate场次开始时间和结束时间需要在同一天() {

        TimeZone.setDefault(TimeZone.getTimeZone("Europe/Kiev")); // 模拟服务器时区没有设置在东八区

        sut =new CampaignEventValidationUseCaseImpl();

        EventTime4Check event =new EventTime4Check();

        event.setEventEndTime(1621526100L);

        event.setEventStartTime(1621440300L);

        CampaignDto campaignDto =new CampaignDto();

        campaignDto.setCampaignId("12345");

        campaignDto.setStartTime(1621483200L);

        campaignDto.setEndTime(1622188000L);

        assertNotNull(sut);

        assertThat(sut.validate(event, campaignDto)).isNotEqualTo("场次开始时间和结束时间需要在同一天！");

    }

}

长篇没有测试又满是 BUG 的函数

这个工程里充斥着长篇函数，状态变量特别多，而且往往在函数开头就定义一堆。如前所述，有没有测试，而且实际联调下来又有 BUG。

部分重建方案

内联只被用到一次的变量，对于被引用多次的变量，将其定义挪到第一次引用之前；

对于已知有 BUG 的分支，使用提前退出，并在单独的小函数中进行自动化测试并修复：

@Override

    publicBooleanqueryCampaignHasReservableEvent(String campaignId, CampaignType campaignType) throws Exception {

        // 新增代码

        if (campaignType == CampaignType.CAMPAIGN) {

            // 联调发现这个分支有 BUG，提前返回新的函数，并对其进行充分的自动化测试

            return queryCampaignHasReservableEventForCampaign(campaignId);

        }

        // 原有代码

        EventQueryCondition queryCondition =new EventQueryCondition();

        queryCondition.setCampaignId(campaignId);

        // 此处省略原有的几十行漏洞代码

        ...

        PageInfo <EventDto> pageInfo = getOnlyEvents(queryCondition);

        return pageInfo.getTotal() !=0;

    }

其他重复代码等等问题

项目中居然有很多整段整段的代码重复，以及格式不规整的问题，这些问题都可以被自动扫描出来，于是搭建一个 SonarQube，以方便快速定位这些问题（扫描结果不堪入目🙈，这还只是新建没多久的项目啊……）：

可以看出，重建很艰难，也是个长期工程，今天就记录到这里。