程序员修炼指北

in Resource

先Mark后吸收

基础篇

《计算机程序结构和解释》

《Redis设计与实现》

《Linux内核学习笔记》

《函数编程指北》

《ETCD源码解析》

《美团技术博客》

《架构风格与基于网络的软件架构设计》

《ElasticSearch源码解读》

前端篇

《前端工程化38讲》

《JavaScript Promise迷你书》

《前端学习博客》

《图解React原理系列》

工具篇

《GIT权威指南》

《如何编写shell脚本》

《python进阶》

Comment and share

如何写好函数

in Clean Code

1. 给函数起个好名字

动词 + 关键词 ： 例如把JUnit中的assertEquals改成 assertExpectedEqualsActual(expected, actual)可能会更好些，大大减轻了记忆参数顺序的负担

2. 函数参数

最理想的参数数量是 0（零参函数）–》其次是1（单参函数）–》 再次是2 （双参函数）–》 应该尽量避免3（三参函数）

如果函数看起来需要2个，3个或者3个以上参数，那说明其中一些需要封装成为类了。

例如：

1
2
Circle makeCircle(double x, double y, double radius);
Circle makeCircle(Point center, double radius);

当一组参数被传递，就像上例中的x和y，往往就是该有自己名称的某个概念的一部分（学会将一组基本变量抽象成为对象）

3. 改变输入参数，从而导致参数成为了输出参数

这一点在java在写业务代码时经常会碰到，改变了输入参数，造成很多迷惑行为

例如：

1
2
//给字符串添加Report添加footer
public void appendFooter(StringBuffer report);

如果不添加注释会产生疑惑：是给report追加东西还是，把report添加到其它东西上？所以写成如下会比较好理解

1
report.appendFooter();

4. 杜绝标识参数

标识参数(True|False)非常丑陋。使用标记参数做了两件事情，则应该拆分它。

1
render(boolean isSuite) => renderForSuite() , renderForSingleTest()

5. 提取try/catch块

try/catch块在函数中很丑陋，将包裹在try/catch中的代码提取出来，减少try/catch的臃肿程度。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
private void writeToClient(HttpServletResponse response, String filePath) {
        try (ServletOutputStream os = response.getOutputStream();
             InputStream stream = new FileInputStream(file)){
             File file = new File(filePath);
             response.setContentLength((int)file.length());
            int length = 0;
            byte[] buff = new byte[1024];
            while ((length = stream.read(buff)) > 0) {
                os.write(buff, 0, length);
            }
        } catch (IOException e) {
            log.error("Download happened error", e);
        } finally {
            if (!file.delete()) {
                log.error("The file {} is failed to be deleted!", filePath);
            }
        }
    }

提取try中的业务代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
private void writeToClient(HttpServletResponse response, String filePath) {
        try (ServletOutputStream os = response.getOutputStream();
             InputStream stream = new FileInputStream(file)){
          
            doWrite(os, stream, reponse, filePath)
        } catch (IOException e) {
            log.error("Download happened error", e);
        } finally {
            if (!file.delete()) {
                log.error("The file {} is failed to be deleted!", filePath);
            }
        }
    }

private void doWrite(ServletOutputStream os, 
                     InputStream stream, 
                     HttpServletResponse response,
                     String filePath){
   File file = new File(filePath);
   response.setContentLength((int)file.length());
   int length = 0;
   byte[] buff = new byte[1024];
   while ((length = stream.read(buff)) > 0) {
     os.write(buff, 0, length);
   }
}

4. 理解OO

面向对象的设计有一个原则（我最初是从 Grady Booch 那里听到的）：“如果觉得设计太复杂，那就生成更多对象。”这种说法既违反直觉，又简单得可笑，但我发现它很有用（“生成更多对象”通常等同于“再增加一层抽象”）。总的来说，如果发现有些地方代码很乱，就要考虑用哪种类可以清理代码。通常清理代码带来的副作用是使系统更灵活并且结构更好。

5. 清理火车代码

杜绝过长的调用链如：

隐藏委托关系（Hide Delegate）

迪米特法则（Law of Demeter），这个原则是这样说的：

  1. 每个单元对其它单元只拥有有限的知识，而且这些单元是与当前单元有紧密联系的；
  2. 每个单元只能与其朋友交谈，不与陌生人交谈；
  3. 只与自己最直接的朋友交谈。
1
2
3
4
5
6
7
8
9
10
book.getAuthor().getName();

//重构后：
class Book { 
  ... 
  public String getAuthorName() { 
    return this.author.getName(); 
  } 
  ...}
String name = book.getAuthorName();

要想摆脱初级程序员的水平，就要先从少暴露细节开始。声明完一个类的字段之后，请停下生成 getter 的手，转而让大脑开始工作，思考这个类应该提供的行为。

基本类型偏执

对于返回值，和参数能封装为类就封装为类；

比如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public double getPrice() { ...}

double price = this.getPrice();
if(price <= 0){
  throw new RuntimeException("价格不能为0");
}

//重构：封装为对象后
class Price{
  double price;
  public Price(final double price) { 
    if (price <= 0) { 
      throw new RuntimeException("价格不能为0");
    } 
    this.price = price; 
  }
}

Comment and share

认识JUnit 5

in Unit Test

JUnit 核心组件

JUnit框架主要有三个核心组件：

JUnit Platform

提供在Jvm上启动测试框架的核心基础，是JUnit和客户端（包含构建工具Maven 或者Gradle或者Eclipse和IntelliJ）之间的接口。它采用了一种可以让外部工具发现，过滤和执行测试的称为“Launcher”的概念。

它还提供了用于开发在JUnit平台上运行测试框架的TestEngine API。使用TestEngine API，Spock,Cucumber和FitNesse第三方测试库可以直接植入和提供他们自定义的TestEngine。

JUnit Jupiter

它为在 JUnit 5 中编写测试和扩展提供了新的编程模型和扩展模型。它有一个全新的注解，用于在 JUnit 5 中编写测试用例。其中一些注解是@BeforeEach、@AfterEach、@AfterAll、@BeforeAll 等。它实现了 JUnit Platform 提供的 TestEngine API，以便可以运行 JUnit 5 测试。

JUnit Vintage

“Vintage”一词的基本意思是经典。因此，该子项目为在 JUnit 4 和 JUnit 3 中编写测试用例提供了广泛的支持。因此，该项目提供了向后兼容性。

image-20220411204229226

原文链接： https://www.educative.io/courses/java-unit-testing-with-junit-5/xV9mMjj74gE

Comment and share

DDD 初探之相关概念

in Architecture

DDD是什么

  1. DDD并不是一种技术架构，而是一种划分业务领域范围的方法论。
  2. DDD不是一种架构，而是一种架构方法论，目的就是将复杂问题领域简单化，帮助我们设计出清晰的领域和边界，可以很好的实现技术架构的演进。

DDD 包括战略设计和战术设计两部分。

  1. DDD战略部分：战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。
  2. DDD战术部分：战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。

DDD与微服务

DDD 是一种架构设计方法，微服务是一种架构风格，两者从本质上都是为了追求高响应力，而从 业务视角 去分离应用系统建设复杂度的手段。两者都强调从业务出发，其核心要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构。

  • DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。
  • 微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。

实践步骤：

第一步：在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。

第二步：根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行，这个边界是逻辑边界，所以用虚线表示。

第三步：根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。在这个图里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离，所以是物理边界，边界之间用实线来表示。

image-20220411183114240

总结

DDD可以理解为：ddd 是一个事件风暴 （分类划分），进而知道组织划分（也就是中台）、系统划分（微服务）、代码划分/设计的思想方法

Comment and share

Java如何断言集合结果集

in Unit Test

场景

当被测试方法返回结果是集合，我们应该使用哪个断言，如果一个一个元素比较会比较麻烦。所以使用其他包下的断言。

代码示例

被测试代码如下，是一组经典的合并两个Map<String, List>的代码(可以直接使用当成工具方法，注意引入Guava包)：

1
2
3
4
5
6
7
8
9
10
11
public Map<String, List<Object>> mergeTwoGroupedMapCollection(Map<String, List<Object>> groupedCollectionOne,
                                                     Map<String, List<Object>> groupedCollectionTwo) {
        Map<String, List<Object>> mapGlobal = Maps.newHashMap();
        mapGlobal.putAll(groupedCollectionOne);
        groupedCollectionTwo.forEach((k, v) -> mapGlobal.merge(k, v, (v1, v2) -> {
            List<Object> data = new ArrayList<>(v1);
            data.addAll(v2);
            return new ArrayList<>(data);
        }));
        return mapGlobal;
    }

测试如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
import static org.junit.jupiter.api.Assertions.assertAll;
import static org.junit.jupiter.api.Assertions.assertIterableEquals;

    @Test
    @DisplayName("should merge multiple map when given two map has grouped by")
    void mergeTwoGroupedMapCollection() {
        MergedCollection mergedCollection = MergedCollection.builder().build();
        Map<String, List<Object>> groupedOne = Maps.newHashMap();
        groupedOne.put("a", Lists.newArrayList("a1", "a2", "a3"));
        groupedOne.put("b", Lists.newArrayList("b1", "b2", "b3"));
        groupedOne.put("c", Lists.newArrayList("c1", "c2", "c3"));

        Map<String, List<Object>> groupedTwo = Maps.newHashMap();
        groupedTwo.put("c", Lists.newArrayList("c3", "c4", "c5", "c6", "c7"));

        Map<String, List<Object>> newGrouped = mergedCollection.mergeTwoGroupedMapCollection(groupedOne, groupedTwo);
        List<Object> except_a = ImmutableList.of("a1", "a2", "a3");
        List<Object> except_b = ImmutableList.of("b1", "b2", "b3");
        List<Object> except_c = ImmutableList.of("c1", "c2", "c3", "c3", "c4", "c5", "c6", "c7");
        assertAll("all elements",
                ()->assertIterableEquals(except_a, newGrouped.get("a")),
                ()->assertIterableEquals(except_b, newGrouped.get("b")),
                ()->assertIterableEquals(except_c, newGrouped.get("c"))
        );

总结

对于这种工具性的方法，必须添加更小粒度的测试。以便于在重构的时候能够保证代码正确性，和理解上下文逻辑。哪如果是私有方法呢？测试大于封装

Comment and share

java如何利用Mockito写好单元测试

in Unit Test

老生常谈之什么是单元测试

  1. 单元测试是低级的，专注于软件系统的最小部分。
  2. 单元测试是程序员自己使用某种测试框架来编写的。
  3. 对于单元测试的期望是运行速度比其它的测试要更快。
    原文参照Martin Fowler博文

Unit Test和TDD的关系

  1. TDD中的T到底是不是Unit Test 存争议，有的人说也可以是集成测试。以下是google测试经理的一段话：

    段念：把 TDD 等同于单元测试，认为 TDD 只是“提前写单元测试”这种想法应该是很多不太了解 TDD 的人容易犯的错误吧。如果把 TDD 放到敏捷开发的大背景下，我倒不觉得 TDD 有什么明显的不足，但如果单独考量 TDD 在企业中的实践，TDD 技术本身不关注代码的质量应该是一个明显的问题。应用 TDD 的企业通常需要采用持续的 Code Review 和 Refactory 方法保证通过 TDD 产生的代码的质量。

原文链接：https://www.infoq.cn/article/virtual-panel-tdd/

  1. 还有一段话我觉得比较好，下来总结下。
    • TDD 并不是石头里蹦出来的孙悟空，DBC（Design By Contract）可以看作是 TDD 的前身。在 DBC 的观点里，设计应该以规约（Contract）的形势体现，规约定义了被开发对象的行为。
    • TDD 中的 T，在表现形式上是“测试”，但其实，它更应该被理解为“对被实现对象”的行为限定，也就是 DBC 中的规约。
    • “测试”只是用来体现规约的形式。 单元测试通常被定义为“对应用最小组成单位的测试”，它的测试对象通常是函数或是类，在对类的设计和实现应用 TDD 时，为类建立的测试通常与类的单元测试相当类似，因此 TDD 中的 T 往往被误认为是单元测试本身。
    • TDD 中的 T 描述的是规约，是设计的一部分；
    • 其次，TDD 中的 T 并不明确要求 T 对实现代码的覆盖率；
    • 第三，TDD 的 T 的侧重点是“描述被实现对象应该具有的行为”，而不仅仅是“验证该类的行为是否正确”。
    • 第三，TDD 的 T 的侧重点是“描述被实现对象应该具有的行为”，而不仅仅是“验证该类的行为是否正确”。当然，TDD 中的 T 在形式上是测试，在重构中也可以作为被实现对象的行为验证框架。
    • 单元测试、集成测试、系统测试、用户验收测试是基于传统软件开发过程的划分，在传统软件开发观点中，这几类测试不仅意味这测试对象的不同，同样也以为着不同的测试在开发周期中处于不同的位置。但在敏捷开发中，如果继续使用这几个名词，最多也只能保留它们在测试对象方面的含义。对于 TDD 来说（ATDD 和 BDD 可以认为是 TDD 的变体），在不同的测试类别中都可以应用之，唯一的区别在于 T 面向的对象不同。

测试框架Mockito 和 PowerMock介绍

  1. Mockito可以让你写出优雅、简洁的单元测试代码。Mockito采用了模拟技术，模拟了一些在应用中依赖的复杂对象，从而把测试对象和依赖对象隔离开来。
  2. PowerMock是在其他单元测试框架的基础上做了增强。PowerMock实现了对静态方法、构造方法、私有方法以及final方法的模拟支持等强大功能。 但是实现方式是通过提供定制的类加载器以及一些字节码篡改技术，会导致部分单元测试用例不会被覆盖率检测工具检测到，所以迫不得已不推荐使用。

利用Spring 搭配 Mockito 编写单元测试

  1. 如下一个典型的用户service服务。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    @Service
    public class UserService {
        @Autowired
        private UserDao userDao;

        /*Id 生成器*/
        @Autowired
        private IdGenerator idGenerator;

        /**
         * 配置参数
         */
        @Value("${userService.canModify}")
        private Boolean canModify;

        /**
         * 创建用户
         *
         * @param userCreate 用户创建
         * @return 用户标识
         */
        public Long createUser(UserVO userCreate) {
            // 获取用户标识
            Long userId = userDAO.getIdByName(userCreate.getName());

            // 根据存在处理
            // 根据存在处理: 不存在则创建
            if (Objects.isNull(userId)) {
                userId = idGenerator.next();
                UserDO create = new UserDO();
                create.setId(userId);
                create.setName(userCreate.getName());
                userDAO.create(create);
            }
            // 根据存在处理: 已存在可修改
            else if (Boolean.TRUE.equals(canModify)) {
                UserDO modify = new UserDO();
                modify.setId(userId);
                modify.setName(userCreate.getName());
                userDAO.modify(modify);
            }
            // 根据存在处理: 已存在禁修改
            else {
                throw new UnsupportedOperationException("不支持修改");
            }

            // 返回用户标识
            return userId;
        }
    }

  2. 针对以上service服务在编写单元测试时，针对它的依赖userDao, idGenerator, canModify我们采用stub来预设存根。这样可以保证我们service只测试自己的逻辑。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
@ExtendWith(MockitoExtension.class)
class UserServiceTest {
     /** 模拟依赖对象 */
    /** 用户DAO */
    @Mock
    private UserDAO userDAO;
    /** 标识生成器 */
    @Mock
    private IdGenerator idGenerator;

    /** 定义被测对象 */
    /** 用户服务 */
    @InjectMocks
    private UserService userService;
  
  /**
     * 在测试之前
     */
    @Before
    public void beforeTest() {
        // 注入依赖对象
        ReflectionTestUtils.setField(Boolean.class, "canModify", false);
    }
  
  /**
  *测试方法
  *也可以使用 @Display 来标注测试方法名称。保证从测试方法名称中能读懂测试的目的，和简单的上下文。
  * 注意此处的Test引用jupiter提供的注解。不然会有注入的空指针
  */
  @Test  
  void should_createUserWithNew_givenInfo_WhenNotExisted(){
    //given data; stub
    when(userDAO).getIdByName(any()).thenReturn(null);
    Long userId = 1L;
    when(idGenerator).next().thenReturn(userId);
    UserVO userCreate = new UserVo(***,***,***);
    
    //when
    Long acturalUserId = userService.createUser(userCreate);
    
    //then
    assertEquals(userId, acturalUserId);
    // 验证依赖方法
    // 验证依赖方法: userDAO.getByName
   Mockito.verify(userDAO).getIdByName(userCreate.getName());
   // 验证依赖方法: idGenerator.next
   Mockito.verify(idGenerator).next();
   // 验证依赖方法: userDAO.create
   ArgumentCaptor <UserDO> userCreateCaptor = ArgumentCaptor.forClass(UserDO.class);
   Mockito.verify(userDAO).create(userCreateCaptor.capture());
   // 验证依赖对象
   Mockito.verifyNoMoreInteractions(idGenerator, userDAO);
  }
}

@Test
void should_updateUser_givenUser_whenHasExisted(){
  //只需要stub此处修改，然后进行已存在断言
  Long userId = 1L;
  when(userDAO).getIdByName(any()).thenReturn(userId);
  
  //then
  ....
}

@Test
void should_exception_givenInvalid(){
  //then 断言采用Junit 5提供的
  Assert.assertThrows("返回异常不一致",
            UnsupportedOperationException.class, () -> userService.createUser(userCreate))
}

如何测试Controller

  1. 保证Api层的访问状态是成功的
  2. 保证入参校验逻辑是可通过的。
  3. 与Service测试不同的是我们要启动web服务，所以必须启动spring容器。但是为了可测service服务我们还是利用Stub技术给出预期返回值。
  4. 利用Spring 提供的@Import({*****.class}}指定我们容器中需要的类，可以方便的避免容器需要加载所有bean很慢的尴尬。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
@WebMvcTest(controllers = UserController.class, useDefaultFilters = false)
@Import({UserController.class,
        AopAutoConfiguration.class,
        DependenceService.class})
@ActiveProfiles("test")
class UserControllerTest extends ControllerBaseTest {
  
  /**
  *利用Import和Autowired可以将真是的bean在运行测试的时候注入进来。会调用真是的方法。
  */
    @Autowired 
    private MockMvc mvc;
  
    @Autowired
    private DependenceService service;
  
    @MockBean
    private UserService service;
  
    @Test
    void should_200_when_create() {
      Long userId = 1L;
      when(service.createUser(any())).thenReturn(userId);
      
      //when
      mvc.perform(MockMvcRequestBuilders.post("/user")
                        .content(jsonString) //given data
                        .header("X-TIME-ZONE", "Asia/Shanghai")
                        .with(csrf())
                        .contentType(MediaType.APPLICATION_JSON))
                .andExpect(status().isOk());//then
    }
  
}

  1. 使用ArgumentCaptor验证代码中间被stub掉方法的参数.

    存在一种情况我们给serviceA中的methodA写单元测试的过程中，发现调用了serviceB的methodB方法，并且为serviceB方法new 了一个ObjectA对象作为调用serviceB.methodB的参数，如下：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    public class ServiceA {
      @Autowired
      public ServiceB serviceB
      
      public void methodA() {
        /*
        * 其它业务代码 
        */
        for (i = 0; i < 3; i++ ){
        	ObjectA objA = new ObjectA();
          ObjcetB objB = serviceB.methodB("hello", objA);  
        }
        /*
        * 其它业务代码 
        */
        
      }
    }

    此时在测试 methodA的时候，需要使用测试替身代替真实的serviceB.methodB(objA);调用，这个时候我们不能使用 Mockito.when(serviceB.methodB(eq(“hello”), eq(new ObjectA())))来进行替换，因为new出来的对象是不同的对象所以stub不住。这个时候应该使用使用ArgumentCaptor进行捕获后验证，如下：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    ArgumentCaptor<ObjectA> objACaptor = ArgumentCaptor.forClass(ObjectA.class);
    //利用mockito.when().thenReturn()返回多个对象来stub循环中的三方调用
    Mockito.when(serviceB.methodB(eq("hello"), objACaptor.caputre())).thenReturn(objB1, obj2, obj3);
    //然后获取三次captor捕获的三个参数进行验证。
    List<ObjectA> objAs = objACaptor.getValues();
    //验证三次参数
    Assertions.assertEquals(objAs(0), objB1);
    Assertions.assertEquals(objAs(1), objB2);
    Assertions.assertEquals(objAs(2), objB2);

相关链接

Java编程技巧之单元测试用例编写流程：https://zhuanlan.zhihu.com/p/371759603

谈一谈单元测试：https://mp.weixin.qq.com/s/ioya1kzdTGPB0oOZ3DUmig

Comment and share

  • page 1 of 1
Copyrights © 2025 Topsion. All Rights Reserved.
Author's picture

Topsion

Fullstack Developer


Coder


Xi'an China