【每周小结】2023-Week7

junedayday

发布于 2023-02-18 08:42:43

30900

代码可运行

文章被收录于专栏：Go编程点滴Go编程点滴

运行总次数：0

代码可运行

本周的总结发得比较晚，花在打磨编程思考部分的时间比较多。

虽然最终版本也不是很满意，不过也算达到了阶段性交付的水平。

Go技巧 - 并发代码的单元测试

在Go语言开发的过程中，我们或多或少会引入并发模式，常见的如go、channel、sync.WaitGroup等。这些并发原语使用起来很方便，但常常会阻碍相关代码的单元测试，如依赖的channel发生阻塞，mutex被锁等，导致想验证的重要代码根本跑不到。

这里，我介绍一下自己的三个心得，用一句话概括，合理利用分层进行拆分，屏蔽并发逻辑。

没有分层的基础或工具库不在本次的讨论范围内，但也可以借鉴这里的思想。

多协程的逻辑交由上层控制

如下，原先的业务逻辑代码包括了两块处理逻辑：

func Foo(){
  // 逻辑A
  
  go func(){
    // 逻辑B
  }()
}

由于逻辑B相关的代码无法验证，所以这个单元测试能做的很有限。这时，通过分层，我们将代码拆分为两部分：

// 上层代码 - 使用基础的并发特性，没有必要做单元测试
func Foo() {
  FooA()
  
  go FooB()
}

// 下层代码 - 做严格的单元测试
func FooA() {
}

func FooB() {
}

此时的单元测试就变得直观了。

锁类逻辑由下层对象封装

业务代码常常会包含锁，这就导致很多函数中有大量的Lock、UnLock操作，容易在单元测试里验证一些逻辑时发生死锁。

func Foo() {
  // do a
  m.Lock()
  defer m.UnLock()
  // do b
}

从抽象层面来说，业务逻辑的核心代码尽量减少锁这种 底层的并发原语，把它们放在业务逻辑里也很影响阅读体验。这时，将锁划分到下层会让代码逻辑更清晰：

// 下层对象
type FooA struct {
}

type FooB struct {
  // 锁
  sync.Mutex
}

// 业务代码
func Foo() {
  // 这里不包含锁逻辑
  fooA.Do()
  // 这里包含锁逻辑
  fooB.DO()
}

从使用锁的角度来说，Lock与UnLock之间的逻辑应尽量短，所以很适合放在底层对象、交由它自行控制，也能缩短锁的影响范围。

同层抽离出核心控制函数

在Go语言中，有一些并发特性、尤其以channel为代表，很难通过分层解决。例如

func Foo() {
  var c chan int
  // 发送消息
  go func(){
    // send to c
  }()
  
  // 接收消息
  go func(){
    // receive from c
  }()
}

这里的channel更多的是一种具有业务特性的并发控制，单独抽出一个 核心控制函数 就能提升整体的可读性与可测试性：

// 核心控制函数
func Foo() {
  var c chan int
  
  // 发送逻辑
  go func() {
    a := logicA()
    c <- a
  }
  
  // 接收逻辑
  go func() {
    a := <- c
    logicB(a)
  }
}

// 以下逻辑均不包含channel，方便单元测试
func logicA() int {
}

func logicB(a int) {
}