我司使用 mono repo, 某个服务 ut 失败,导致别人无法构建。查看下源代码以及 ut case, 发现槽点蛮多,讲一下如何修复,展开聊一下写单测要注意的一些点,和设计模式中的概念依赖反转、依赖注入、控制反转

失败 case

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
func toSeconds(in int64) int64 {
if in > time.Now().Unix() {
nanosecondSource := time.Unix(0, in)
if dateIsSane(nanosecondSource) {
return nanosecondSource.Unix()
}

millisecondSource := time.Unix(0, in*int64(time.Millisecond))
if dateIsSane(millisecondSource) {
return millisecondSource.Unix()
}

// default to now rather than sending something stupid
return time.Now().Unix()
}
return in
}

func dateIsSane(in time.Time) bool {
return (in.Year() >= (time.Now().Year()-1) &&
in.Year() <= (time.Now().Year()+1))
}

函数 toSeconds 接收一个时间参数,可能是秒、毫秒和其它时间,经过判断后返回秒值

1
2
3
4
5
6
7
8
9
10
11
12
......
{
desc: "less than now",
args: 1459101327,
expect: 1459101327,
},
{
desc: "great than year",
args: now.UnixNano()/6000*6000 + 7.55424e+17,
expect: now.Unix(),
},
......

上面是 test case table, 最后报错 great than year 断言失败了。简单的看下实现逻辑就能发现,函数是想修正到秒值,但假如刚好 go gc STW 100ms, 就会导致 expect 与实际结果不符

如何从根本上修复问题呢?要么修改函数签名,外层传入 time.Now()

1
2
3
func toSeconds(in int64, now time.Time) int64 {
......
}

要么将 time.Now 函数定义成当前包内变量,写单测时修改 now 变量

1
2
3
4
5
6
var now = time.Now

func toSeconds(in int64) int64 {
if in > now().Unix() {
......
}

以上两种方式都比较常见,本质在于单测 ut 不应该依赖于当前系统环境,比如 mysql, redis, 时间等等,应该仅依赖于输入参数,同时函数执行多次结果应该一致。去年遇到过 CI 机器换了,新机器没有 redis/mysql, 导致一堆 ut failed, 这就是不合格的写法

如果依赖环境的资源,那么就变成了集成测试。如果进一步再依赖业务的状态机,那么就变成了回归测试,可以说是层层递进的关系。只有做好代码的单测,才能进一步确保其它测试正常。同时也不要神话单测,过份追求 100% 覆盖

依赖注入

刚才我们非常自然的引入了设计模式中,非常重要的 依赖注入 Dependenccy injection 概念

1
func toSeconds(in int64, now time.Time) int64 

简单的讲,toSeconds 函数调用系统时间 time.Now, 我们把依赖以参数的形式传给 toSeconds 就是注入依赖,定义就这么简单

关注 DI, 设计模式中抽像出来四个角色:

  • service 我们所被依赖的对像
  • client 依赖 service 的角色
  • interface 定义 client 如何使用 service 的接口
  • injector 注入器角色,用于构造 service, 并将之传给 client

我们来看一下面像对像的例子,Hero 需要有武器,NewHero 是英雄的构造方法

1
2
3
4
5
6
7
8
9
10
11
type Hero struct {
name string
weapon Weapon
}

func NewHero(name string) *Hero {
return &sHero{
name: name,
weapon: NewGun(),
}
}

这里面问题很多,比如换个武器 AK 可不可以呢?当然行。但是 NewHero 构造时依赖了 NewGun, 我们需要把武器在外层初始化好,然后传入

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
type Hero struct {
name string
weapon Weapon
}

func NewHero(name string, wea Weapon) *Hero {
return &Hero{
name: name,
weapon: wea,
}
}

func main(){
wea:= NewGun();
myhero = NewHero("killer47", wea)
}

在这个 case 里面,Hero 就是上面提到的 client 角色,Weapon 就是 service 角色,injector 是谁呢?是 main 函数,其实也是码农

这个例子还有问题,原因在于武器不应该是具体实例,而应该是接口,即上面提到的 interface 角色

1
2
3
type Weapon interface {
Attack(damage int)
}

也就是说我们的武器要设计成接口 Weapon, 方法只有一个 Attack 攻击并附带伤害。但是到现在还不是理想的,比如说我没有武器的时候,就不能攻击人了嘛?当然能,还有双手啊,所以有时我们要用 Option 实现默认依赖

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
type Weapon interface {
Attack(damage int)
}

type Hero struct {
name string
weapon Weapon
}

func NewHero(name string, opts ...Option) *Hero {
h := &Hero{
name: name,
}

for _, option := range options {
option(i)
}

if h.weapon == nil {
h.weapon = NewFist()
}
return h
}

type Option func(*Hero)

func WithWeapon(w Weapon) Option {
return func(i *Hero) {
i.weapon = w
}
}

func main() {
wea := NewGun()
myhero = NewHero("killer47", WithWeapon(wea))
}

上面就是一个生产环境中,比较理想的方案,看不明白的可以运行代码试着理解下

第三方框架

刚才提到的例子比较简单,injector 由码农自己搞就行了。但是很多时候,依赖的对像不只一个,可能很多,还有交叉依赖,这时候就需要第三方框架来支持了

1
2
3
4
5
6
7
8
9
10
11
12
13
 <?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

<bean id="service" class="ExampleService">
</bean>

<bean id="client" class="Client">
<constructor-arg value="service" />
</bean>
</beans>

Java 党写配置文件,用注解来实现。对于 go 来讲,可以使用 wire, https://github.com/google/wire

1
2
3
4
5
6
7
8
9
10
11
12
13
// +build wireinject

package main

import (
"github.com/google/wire"
"wire-example2/internal/config"
"wire-example2/internal/db"
)

func InitApp() (*App, error) {
panic(wire.Build(config.Provider, db.Provider, NewApp)) // 调用wire.Build方法传入所有的依赖对象以及构建最终对象的函数得到目标对象
}

类似上面一样,定义 wire.go 文件,然后写上 +build wireinject 注释,调用 wire 后会自动生成 injector 代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
//go:generate go run github.com/google/wire/cmd/wire
//+build !wireinject

package main

import (
"wire-example2/internal/config"
"wire-example2/internal/db"
)

// Injectors from wire.go:

func InitApp() (*App, error) {
configConfig, err := config.New()
if err != nil {
return nil, err
}
sqlDB, err := db.New(configConfig)
if err != nil {
return nil, err
}
app := NewApp(sqlDB)
return app, nil
}

我司有项目在用,感兴趣的可以看看官方文档,对于构建大型项目很有帮助

依赖反转 DIP 原则

我们还经常听说一个概念,就是依赖反转 dependency inversion principle, 他有两个最重要的原则:

  • High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces).

  • Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

高层模块不应该依赖低层模块,需要用接口进行抽像。抽像不应该依赖于具体实现,具体实现应该依赖于抽像,结合上面的 Hero&Weapon 案例应该很清楚了

那我们学习 DI、DIP 这些设计模式目的是什么呢?使我们程序各个模块之间变得松耦合,底层实现改动不影响顶层模块代码实现,提高模块化程度,增加括展性

但是也要有个度,服务每个都做个 interface 抽像一个模块是否可行呢?当然不,基于这么多年的工程实践,我这里面有个准则分享给大家:易变的模块需要做出抽像、跨 rpc 调用的需要做出抽像

控制反转 IOC 思想

本质上依赖注入是控制反转 IOC 的具体一个实现。在传统编程中,表达程序目的的代码调用库来处理通用任务,但在控制反转中,是框架调用了自定义或特定任务的代码,Java 党玩的比较多

推荐大家看一下 coolshell 分享的 undo 例子。比如我们有一个 set 想实现 undo 撤回功能

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
type IntSet struct {
data map[int]bool
}
func NewIntSet() IntSet {
return IntSet{make(map[int]bool)}
}
func (set *IntSet) Add(x int) {
set.data[x] = true
}
func (set *IntSet) Delete(x int) {
delete(set.data, x)
}
func (set *IntSet) Contains(x int) bool {
return set.data[x]
}

这是一个 IntSet 集合,拥有三个函数 Add, Delete, Contains, 现在需要添加 undo 功能

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
type UndoableIntSet struct { // Poor style
IntSet // Embedding (delegation)
functions []func()
}

func NewUndoableIntSet() UndoableIntSet {
return UndoableIntSet{NewIntSet(), nil}
}

func (set *UndoableIntSet) Add(x int) { // Override
if !set.Contains(x) {
set.data[x] = true
set.functions = append(set.functions, func() { set.Delete(x) })
} else {
set.functions = append(set.functions, nil)
}
}
func (set *UndoableIntSet) Delete(x int) { // Override
if set.Contains(x) {
delete(set.data, x)
set.functions = append(set.functions, func() { set.Add(x) })
} else {
set.functions = append(set.functions, nil)
}
}
func (set *UndoableIntSet) Undo() error {
if len(set.functions) == 0 {
return errors.New("No functions to undo")
}
index := len(set.functions) - 1
if function := set.functions[index]; function != nil {
function()
set.functions[index] = nil // For garbage collection
}
set.functions = set.functions[:index]
return nil
}

上面是具体的实现,有什么问题嘛?有的,undo 理论上只是控制逻辑,但是这里和业务逻辑 IntSet 的具体实现耦合在一起了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
type Undo []func()

func (undo *Undo) Add(function func()) {
*undo = append(*undo, function)
}
func (undo *Undo) Undo() error {
functions := *undo
if len(functions) == 0 {
return errors.New("No functions to undo")
}
index := len(functions) - 1
if function := functions[index]; function != nil {
function()
functions[index] = nil // For garbage collection
}
*undo = functions[:index]
return nil
}

上面就是我们 Undo 的实现,跟本不用关心业务具体的逻辑

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
type IntSet struct {
data map[int]bool
undo Undo
}

func NewIntSet() IntSet {
return IntSet{data: make(map[int]bool)}
}

func (set *IntSet) Undo() error {
return set.undo.Undo()
}

func (set *IntSet) Contains(x int) bool {
return set.data[x]
}

func (set *IntSet) Add(x int) {
if !set.Contains(x) {
set.data[x] = true
set.undo.Add(func() { set.Delete(x) })
} else {
set.undo.Add(nil)
}
}

func (set *IntSet) Delete(x int) {
if set.Contains(x) {
delete(set.data, x)
set.undo.Add(func() { set.Add(x) })
} else {
set.undo.Add(nil)
}
}

这个就是控制反转,不再由控制逻辑 Undo 来依赖业务逻辑 IntSet, 而是由业务逻辑 IntSet 来依赖 Undo. 想看更多的细节可以看 coolshell 的博客

再举两个例子,我们有 lbs 服务,定时更新司机的坐标流,中间需要处理很多业务流程,我们埋了很多 hook 点,业务逻辑只需要对相应的点注册就可以了,新增加业务逻辑无需改动主流程的代码

很多公司在做中台,比如阿里做的大中台,原来各个业务线有自己的业务处理逻辑,每条业务线都有一部份人只写业务相关的代码。中台化会抽像出共有的流程,每个业务只需要配置文件自定义需要的哪些模块即可,这其实也是一种控制反转的思想

小结

上面是我关于 依赖反转依赖注入控制反转 的思考,分享给大家,如果有理解错误,有不到位的请指正

写文章不容易,如果对大家有所帮助和启发,请大家帮忙点击在看点赞分享 三连

关于 控制反转 大家有什么看法,欢迎留言一起讨论,大牛多留言 ^_^