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

高质量编程

一、高质量编程简介

1. 能达到编程代码的目标：正确可靠，简介清晰。

具体而言：

• 正确性：是否考虑各种边界条件，错误的调用是否能够处理
• 可靠性：异常情况或者错误的处理策略是否明确，依赖的服务出现异常是否能够处理
• 简洁：逻辑是否简单，后续调整功能或新增功能是否能够快速支持
• 清晰：其他人在阅读理解代码的时候是否能清楚明白，重构或者修改功能是否不会担心出现无法预料的问题

总结而言：

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

2. 编码原则

• 简单性：代码简单清晰，避免复杂逻辑导致开发者不理解代码无法修复改进
• 可读性：面向人的可读性，减少开发者对代码阅读的时间，提高个人效率
• 生产力：统一代码规范，提高团队工作效率

编码规范

代码格式

• gofmt自动格式化代码（推荐）
• goimports

注释

• 代码作用：始终要注释公共符号（较大方面，变量常量函数结构体，不明显不简短也要注释）
• 实现方法（如何做）：注释实现过程
• 实现原因：注释外部因素和提供的额外上下文
• 预期错误（预期什么时候出错）：注释代码的限制条件 ps：不需要注释实现接口的方法

3. 命名规范

• variable

  • 简洁胜于冗长
  • 缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写：
    • 使用 ServeHTTP 而不是ServeHttp
    • 使用 XMLHTTPRequest 或者 xmlHTTPRequest
  • 变量距离其被使用的地方越远，则需要携带越多的上下文信息
    • 全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出其含义

• function

  • 函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的·函数名尽量简短
  • 当名为foo的包某个函数返回类型Foo时，可以省略类型信息而不导致歧义
  • 当名为foo的包某个函数返回类型T时(T并不是 Foo)，可以在函数名中加入类型信息

• package

  • 只由小写字母组成。不包含大写字母和下划线等字符
  • 简短并包含一定的上下文信息。例如schema、task 等
  • 不要与标准库同名。例如不要使用sync或者strings
  • 尽量满足：谨慎使用缩写，使用单数不用双数，不用常用变量作包名

命名规范的核心：在于降低阅读理解代码的成本，重点考虑上下文信息，设计简洁清晰名称

4. 控制流程

• 避免嵌套，保证正常清晰
• 保持正常代码路径为最小缩进

// good
if err := xxx(); err != nil {
    return err
}
...
return nil

// bad
err := xxx()
if err != nil {
    return err
}
return nil

5. 错误和异常处理

a. 简单错误

• 只出现一次，在其他地方不用捕获
• 优先使用 errors.New 来用常见匿名变量直接打印错误
• 格式化需求：fmt.Errorf

b. 错误的 Wrap 和 Unwrap

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

c. 特定错误判定

• errors.Is，解决==不能判定错误中是否含有特定错误

d. 获取特定种类的错误

• errors.As 错误链上获取特定种类的错误，如取错误路径

panic

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

recover

• recover只能在被defer的函数中使用
• 嵌套无法生效
• 只在当前 goroutine 生效
• defer的语句是后进先出
• 若需要打印上下文信息，可以在 recover 中的log中用 debug.Stack() 记录当前的调用堆栈(记录栈)

二、性能优化建议

简介

高质量的代码能够完成功能，但是在大规模程序部署的场景，仅仅支持正常功能还不够，我们还要尽可能的提升性能，节省资源成本，因此需要性能优化。

建议

1. 如何使用 Benchmark

• 性能表现需要实际数据衡量，而Go语言提供了支持基准性能测试的 benchmark 工具
• 指令：go test bench=. -benchmem

2. slice 预分配内存

• 第一个陷阱：内存拷贝

  • 切片操作并不复制切片指向的元素 创建一个新的切片会复用原来切片的底层数组
  • 为了避免内存发生拷贝，如果能够知道最终的切片的大小，预先设置 cap 的值能够避免额外的内存分配，获得更好的性能

• 尽可能在使用 make() 初始化切片时提供容量信息

• 另一个陷阱:大内存未释放

  • 在已有切片基础上创建切片，不会创建新的底层数组
  • 场景：
    • 原切片较大,代码在原切片基础上新建小切片
    • 原底层数组在内存中有引用,得不到释放
  • 可使用copy替代 re-slice

  // bad
  func GetLastByslice( origin []int) [ ]int {
      return origin[len(origin)-2:]
  }
  
  // good
  func GetLastByCopy ( origin []int) []int {
      result := make([]int，2)
      copy(result，origin[len(origin)-2:])
      return result
  }
  
  // cmd测试：go test -run=. v
  

ps：map类似slice，也可以内存预分配

1.不断向 map 中添加元素的操作会触发

2.map 的扩容提前分配好空间可以减少内存拷贝和 Rehash 的消耗

3.建议根据实际需求提前预估好需要的空间

3.字符串处理（使用strings.Builder）

• 常用字符串处理：使用 + 拼接性能最差，strings.Builder，bytes.Buffer相近，strings.Buffer更快

• 分析：

  • 字符串在Go语言中是不可变类型，占用内存大小是固定的；

  • 使用 + 每次都会重新分配内存；

  • strings.Builder，bytes.Buffer底层都是[]byte 数组；

  • 内存扩容策略，不需要每次拼接重新分配内存

4.空结构体（空间优化）

• 使用空结构体节省内存
  • 空结构体 struct小实例不占据任何的内存空间
  • 可作为各种场景下的占位符使用
    • 节省资源
    • 空结构体本身具备很强的语义，即这里不需要任何值，仅作为占位符
• 最容易想到set实现
  • 实现 Set，可以考虑用 map 来代替
  • 对于这个场景，只需要用到 map 的键，而不需要值
  • 即使是将 map 的值设置为 bool 类型，也会多占据 1个字节空间

5. atomic 包

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

学习心得

课程内容很多，高质量编程课程中有着注释与编码规范，以及空间和时间的性能优化的内容，都是平常在学校学不到的一些东西，要花时间消化，不过获益匪浅，希望共勉努力学习。

引用

ppt：‌‍​⁤⁡​‬⁤‌⁡​‍‍​​‬‌​‬⁣‬⁡‌⁣‍⁢⁣‬‌​⁢⁡‌⁣​‌‍⁣​​⁤​‬⁢高质量编程与性能调优实战 .pptx - 飞书云文档 (feishu.cn)