高质量编程与性能调优实战 | 青训营笔记

mktb
93 阅读7分钟

这是我参与「第三届青训营 -后端场」笔记创作活动的的第2篇笔记

1.高质量编程

1.1 简介

什么是高质量——编写的代码能够达到正确可靠、简洁清晰的目标就可以称为高质量代码。

  • 各种边界条件是否考虑完备
  • 异常情况处理，稳定性保证
  • 易读易维护

编程原则

  • 简单性
    • 消除“多余的复杂性”，以简单清晰的逻辑编写代码
    • 不理解的代码无法修复改进
  • 可读性
    • 代码是写给人看的，而不是机器
    • 编写可维护代码的第一步是确保可读性
  • 生产力
    • 团队整体工作效率非常重要

1.2 编码规范

如何编写高质量的Go代码，从以下几点考虑：

1.2.1 代码格式

  • 推荐使用gofmt自动格式化代码
  • goimports：也是go语言官方提供的工具，实际上等于gofmt加上依赖包管理，自动增删依赖的包引用、将依赖包按字母序排序并分类

1.2.2 注释

注释应该做什么：

  • 注释应该解释代码的作用
    适合注释公共符号
  • 注释应该解释代码如何做的
    适合注释实现过程
  • 注释应该解释代码实习的原因
    • 适合解释代码的外部因素
    • 提供额外的上下文
  • 注释应该解释代码什么情况会出错
    适合解释代码的限制条件 公共符号始终要注释：
  • 包中声明的每个公共的符号：变量、常量、函数以及结构都需要注释
  • 任何既不明显又不简短的公共功能必须注释
  • 无论长度或复杂程度如何，对库中的任何函数都需要注释
  • 不需要注释实现接口的方法

小结

  • Good code has lots of comments, bad code requires lots of comments.
  • 最好的注释是代码
  • 注释应该提供代码未表达出的上下文信息

1.2.3 命名规范

  • variable
    • 简介胜于冗长
    • 所略词全大写，但当其位于变量开头且不需要导出时，使用全小写
      • 例如使用ServerHTTP而不是ServerHttp
      • 使用XMLHTTPRequest或者xmlHTTPRequest
    • 变量距离其被使用的地方哪个越远，则需要携带越多的上下文信息
      • 全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出其含义
  • function
    • 函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的
    • 函数名尽量简短
    • 当名为foo的包某个函数返回类型Foo时，可以省略类型信息而不导致歧义
    • 当名为foo的包某个函数返回类型T时，可以在函数名中加入类型信息(T != Foo)
  • package
    • 只由小写字母组成，不包含大写字母和下划线等字符
    • 简短并包含一定的上下文信息，例如schema、task等
    • 不要与标准库同名，例如不要使用sync或者strings 以下规则尽量满足，以标准库包名为例
    • 不使用常用变量名作为包名。例如使用bufio而不是buf
    • 使用单数而不是复数
    • 谨慎使用缩写。如fmt在不破坏上下文的情况下比format跟加简短

小结

  • 核心目标是降低阅读理解代码的成本
  • 重点考虑上下文信息，设计简单清晰的名称
  • Good naming is like a good joke. If you have to explain it, it's not funny.

1.2.4 控制流程

  • 避免嵌套，保持正常流程清晰
    如果两个分支中都包含return语句，则可以去除冗余的else
  • 尽量保持正常代码路径为最小缩进，快乐路径
    优先处理错误情况/特殊情况，尽早返回或继续循环来减少嵌套

小结

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

1.2.5 错误和异常处理

简单错误

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

错误的Wrap和Unwrap

  • 错误的Wrap实际上是提供了一个error嵌套另一个error的能力，从而生成一个error的跟踪链
  • 在fmt.Error中使用：%w关键字来将一个错误关联至错误链中

错误判定

  • 判定一个错误是否为特定错误，使用errors.Is
  • 不同于使用==，使用该方法可以判定错误链上的所有错误是否含有特定的错误 
    data, err = lockedfile.Read(targ)
if errors.Is(err, fs.ErrNotExist) {
    return []byte{}, nil
}
return data, err
  • 在错误链上获取特定种类的错误，使用errors.As 
    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

  • 不建议在业务代码中使用panic
  • 调用函数不包含recover会造成程序崩溃
  • 若问题可以被屏蔽或解决，建议使用error代替panic
  • 当程序启动阶段发生不可逆转的错误时，可以在init或main函数中使用panic

recover

  • recover只能在被defer的函数中使用
  • 嵌套无法生效
  • 只在当前goroutine生效
  • defer的语句是后进先出
  • 如果需要更多的上下文信息，可以recover后在log中记录当前的调用栈

小结

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

1.3 性能优化建议

简介

  • 性能优化的前提是满足正确可靠、简洁清晰等质量因素
  • 性能优化是综合评估，有时候时间效率和空间效率可能对立
  • 针对Go语言特性，介绍Go相关的性能优化建议

1.3.1 性能优化建议-Benchmark

如何使用

  • 性能表现需要实际数据衡量

  • Go语言提供了支持基准性能测试的benchmark工具

    go test -bench=. -benchmem

    输出解释

    列数解释
    1BenchmarkFib10是测试函数名，-8表示GOMAXPROCS的值为8，即处理器内核数
    2表示执行的次数
    3每次执行花费的时间
    4每次执行申请的内存
    5每次执行申请几次内存

1.3.2 性能优化建议-Slice

slice预分配内存
  • 尽可能在使用make()初始化切片时提供容量信息
陷阱：大内存未释放
  • 在已有切片的基础上创建切片，不会创建新的底层数组
  • 场景：
    • 原有切片较大，代码在原切片基础上新建小切片
    • 原底层数组在内存中有引用，不会释放
  • 可用copy代替re-slice

1.3.3 map 预分配内存

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

1.3.4 使用 strings.Builder

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

1.3.5 使用空结构体节省内存

  • 空结构体不占据内存空间，可作为占位符使用
  • 比如实现简单的 Set
    • Go 语言标准库没有提供 Set 的实现，通常使用 map 来代替。对于集合场景，只需要用到 map 的键而不需要值

1.3.6 使用 atomic 包

  • 原理
    • 锁的实现是通过操作系统来实现，属于系统调用，atomic 操作是通过硬件实现的，效率比锁高很多
    • sync.Mutex 应该用来保护一段逻辑，不仅仅用于保护一个变量
    • 对于非数值系列，可以使用 atomic.Value，atomic.Value 能承载一个 interface{}

1.3.7 总结

  • 避免常见的性能陷阱可以保证大部分程序的性能
  • 针对普通应用代码，不要一味地追求程序的性能，应当在满足正确可靠、简洁清晰等质量要求的前提下提高程序性能
avatar
文章
阅读
粉丝