Go高质量编程 ｜ 青训营笔记

我不是妖怪a
51 阅读9分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天

此文可接上一篇Go语言编码规范阅读，本文主要总结课程所讲授的高质量编程总结。

控制流程

避免嵌套

从最简单的一个 if else 条件开始，如果两个分支都包含 return 语句，则可以去除冗余的 else，方便后续维护。else 一般是正常流程，不过如果需要在正常流程新增判断逻辑，避免分支嵌套。

 // Bad
 if foo {
     return x
 } else {
     return nil
 }
 // Good
 if foo {
     return x
 }
 return nil

正常代码最小缩进

  • 优先处理错误情况/特殊情况，尽早返回或继续循环来减少嵌套
  • 最常见的正常流程的路径被嵌套在两个 if 条件内
  • 成功的退出条件是 return nil，必须仔细匹配大括号来发现
  • 函数最后一行返回一个错误，需要追溯到匹配的左括号，才能了解何时会触发错误
  • 如果后续正常流程需要增加一步提作，调用新的函数，则又会增加一层嵌套

以下为多层嵌套情况的代码：

 // Bad
 func OneFunc() error {
     err := doSomething()
     if err == nil {
         err := doAnotherThing()
         if err == nil {
             return nil // normal case
         }
         return err
     }
     return err
 }

调整后的代码如下，调整后的代码从上到下就是正常流程的执行过程。初步阅读代码时可以先忽略每一步的 err 情况，对整体流程有更清晰的了解，如果后续想排查问题可以针对具体某一步的错误详细分析。如果后续正常流程新增操作，可以放心地在函数中添加新的代码。

 // Good
 func OneFunc() error {
     err := doSomething(); err != nil {
         return err
     }
     if err := doAnotherThing(); err != nil {
         return err
     }
     return nil // normal case
 }

下面是go仓库中的代码示例，也是优先处理err情况，保持正常流程的统一。

 func (b *Reader) UnreadByte() error {
     if b.lastByte < 0 || b.r == 0 && b.w > 0 {
         return ErrInvalidUnreadByte
     }
     // b.r > 0 || b.w == 0
     if b.r > 0 {
         b.r--
     } else {
         // b.r == 0 && b.w == 0
         b.w = 1
     }
     b.buf[b.r] = byte(b.lastByte)
     b.lastByte = -1
     b.lastRuneSize = -1
     return nil
 }

总结

  • 线性原理，处理逻辑尽量走直线，避免复杂的嵌套分支
  • 正常流程代码沿着屏幕向下移动
  • 提升代码可维护性和可读性
  • 故障问题大多出现在复杂的条件语句和循环语句中

Go 语言代码不是成功的路径越来越深地嵌套到右边，而是随着函数的执行，正常流程代码会沿着屏幕向下移动。一个功能如果可以通过多个功能的线性结合来实现，那它的结构就会非常简单。反过来，用条件分支控制代码、毫无章法地增加状态数等行为会让代码变得难以理解。需要避免这些行为，提高代码的可读性。如果能让正常流程自上而下、简单清晰地进行处理，代码的可读性就会大幅提高，与此同时，可维护性也将提高，添加功能等改良工作将变得更加容易。故障问题大多出现在复杂的条件语句和循环语句中，在维护这种逻辑时，添加功能会变成高风险的操作，很容易遗漏部分条件导致问题。

错误和异常处理

简单错误

  • 简单的错误指的是仅出现一次的错误，且在其他地方不需要捕获该错误
  • 优先使用 errors.New 来创建匿名变量来直接表示简单错误
  • 如果有格式化的需求，使用 fmt.Errorf

示例是 go 仓库中的一段代码，定义了简单错误，描述失败原因：

 func defaultCheckRedirect(req *Request, via []*Request) error {
     if len(via) >= 10 {
         return errors.New("stopped after 10 redirects")
     }
     return nil
 }

错误的 Wrap 和 Unwrap

  • 错误的 Wrap 实际上是提供了一个 error 嵌套另一个 error 的能力，从而生成一个 error 的跟踪链，同时结合错误的判定方法来确认调用链中是否有关注的错误出现。这个能力的好处是每一层调用方可以补充自己对应的上下文，方便跟踪排查问题，确定问题的根本原因在哪里。
  • 在 fmt.Errorf 中使用: %w 关键字来将一个错误关联至错误链中。
 list, _, err := c.GetBytes(cache.Subkey(a.actionID, "srcfiles"))
 if err != nil {
     return fmt.Errorf("reading srcfiles list: %w", err)
 }

Go1.13 在 errors 中新增了三个新 API 和一个新的 format 关键字，分别是 errors.Is errors.As,errors.Unwrap 以及 fmt.Errorf 的%w。如果项目运行在小于 Go1.13 的版本中，导入 golang.org/x/xerrors 来使用。

错误判定

  • 判定一个错误是否为特定错误，使用 errors.Is
  • 不同于使用 ==，使用该方法可以判定错误链上的所有错误是否含有特定的错误
 data, err = lockedfile.Read(targ)
 if errors.Is(err, fs.ErrNotExist) {
     // Treat non-existent as empty, to bootstrap the "latest" file
     // the first time we connect to a given database.
     return []byte{}, nil
 }
 return data, err
  • 在错误链上获取特定种类的错误，使用 errors.As。它和 is 的区别在于 as 会提取出调用链中指定类型的错误，并将错误赋值给定义好的变量，方便后续处理，示例中是把问题的path打印出来了。
 if _, err := os.Open("non-existing"); err != nil {
     var pathError *fs.PathError
     if errors.As(err, &pathError) {
         fmt.Println("Failed at path:", pathError.Path)
     } else {
         fmt.Println(err)
     }
 }

panic

在 Go 中，比错误更严重的就是 panic，它的出现表示程序无法正常工作了，在使用时应该注意：

  • 不建议在业务代码中使用 panic，因为 panic 发生后，会向上传播至调用栈顶，如果当前 goroutine 中所有 deferred 函数都不包含 recover 就会造成整个程序崩溃
  • 若问题可以被屏蔽或解决，建议使用 error 代替 panic
  • 当程序启动阶段发生不可逆转的错误时，可以在 init 或 main 函数中使用 panic，因为在这种情况下，服务启动起来也不会有意义。

以下示例是启动消息队列监听器的逻辑，在创建消费组失败的时候会 Panic，实际打印日志，然后抛出panic。

 func main() {
     // ...
     ctx, cancel := context.WithCancel(context.Background())
     client, err := sarama.NewConsumerGroup(strings.Split(brokers, ","), group, config)
     if err != nil {
         log.Panicf("Error creating consumer group client: %v", err)
     }
     // ...
 }
 ​
 // Panicf is equivalent to Printf() followed by a call to panic().
 func Panicf(format string, v ...interface()){
     s := fmt.Sprintf(format, v...)
     std.Output(2, s)
     panic(s)
 }

recover

  • recover 只能在被 defer 的函数中使用
  • 嵌套无法生效
  • 只在当前 goroutine 生效
  • defer 的语句是后进先出
 func (s *ss) Token(skipSpace bool, f func(rune) bool) (tok []byte, err error) {
     defer func() {
     if e := recover(); e != nil {
             if se, ok := e.(scanError); ok {
         err = se.err
             } else {
         panic(e)
             }
     }
     }()
     // ...
 }

如果需要更多的上下文信息，可以 recover 后在 log 中记录当前的调用栈，出现问题时能够方便分析定位。示例中的 debug.Stack() 包含的调用堆栈信息，方便定位具体问题代码。

 func (t *treeFS) Open(name string) (f fs.File, err error) {
     defer func() {
     if e := recover(); e != nil {
             f = nil
             err = fmt.Errorf("gitfs panic: %v\n%s", e, debug.Stack())
     }
     }()
     // ...
 }

总结

  • error 尽可能提供简明的上下文信息链，方便定位问题
  • panic 用于真正异常的情况
  • recover 生效范围，在当前 goroutine 的被 defer 的函数中生效

因为错误和异常是不正常的情况，除了希望程序能兼容这些场景外，重要的也有记录问题的上下文信息，方便后续定位问题。在明确panic，recover这些功能的作用范围的情况下，编写更可靠的程序。

map 预分配内存

  • 不断向 map 中添加元素的操作会触发 map 的扩容
  • 根据实际需求提前预估好需要的空间
  • 提前分配好空间可以减少内存拷贝和 Rehash 的消耗

使用 strings.Builder

常见的字符串拼接方式

1.+

2.strings.Builder

3.bytes.Buffer

strings.Builder 最快，bytes.Buffer 较快，+ 最慢

字符串在 Go 语言中是不可变类型，占用内存大小是固定的，当使用 + 拼接 2 个字符串时，生成一个新的字符串，那么就需要开辟一段新的空间，新空间的大小是原来两个字符串的大小之和strings.Builder，bytes.Buffer 的内存是以倍数申请的strings.Builder 和 bytes.Buffer 底层都是 []byte 数组，bytes.Buffer 转化为字符串时重新申请了一块空间，存放生成的字符串变量，而 strings.Builder 直接将底层的 []byte 转换成了字符串类型返回

使用空结构体节省内存

1.空结构体不占据内存空间，可作为占位符使用

2.比如实现简单的 Set,Go 语言标准库没有提供 Set 的实现，通常使用 map 来代替。对于集合场景，只需要用到 map 的键而不需要值

使用 atomic 包

1.锁的实现是通过操作系统来实现，属于系统调用，atomic 操作是通过硬件实现的，效率比锁高很多

2.sync.Mutex 应该用来保护一段逻辑，不仅仅用于保护一个变量

3.对于数值系列，可以使用 atomic.Value，atomic.Value 能承载一个 interface{}

slice 预分配内存

在尽可能的情况下，在使用 make( ) 初始化切片时提供容量信息，特别是在追加切片时

原理：

1.ueokande.github.io/go-slice-tr…

2.切片本质是一个数组片段的描述，包括了数组的指针，这个片段的长度和容量(不改变内存分配情况下的最大长度)

3.切片操作并不复制切片指向的元素，创建一个新的切片会复用原来切片的底层数组，因此切片操作是非常高效的

4.切片有三个属性，指针(ptr)、长度(len) 和容量(cap)。append 时有两种场景：

当 append 之后的长度小于等于 cap，将会直接利用原底层数组剩余的空间；

当 append 后的长度大于 cap 时，则会分配一块更大的区域来容纳新的底层数组；

因此，为了避免内存发生拷贝，如果能够知道最终的切片的大小，预先设置 cap 的值能够获得最好的性能

另一个陷阱：大内存得不到释放

1.在已有切片的基础上进行切片，不会创建新的底层数组。因为原来的底层数组没有发生变化，内存会一直占用，直到没有变量引用该数组

2.因此很可能出现这么一种情况，原切片由大量的元素构成，但是我们在原切片的基础上切片，虽然只使用了很小一段，但底层数组在内存中仍然占据了大量空间，得不到释放

3.推荐的做法，使用 copy 替代 re-slice

avatar
文章
阅读
粉丝