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

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

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

高质量原则：1、简单性 2、可读性 3、生产力

注释规范

代码是最好的注释，注释应该提供代码未表达出的上下文信息，公共符号始终要注释

• 注释应该解释代码作用
• 注释应该解释代码如何做的
• 注释应该解释代码实现的原因
• 注释应该解释代码什么情况会出错

命名规范

变量命名

• 包含变量名的信息量
• 有特定的含义
• 避免传入错误的值，造成非预期的错误

函数命名

• 不携带包名的上下文信息

• 尽可能简短

  eg：

  

包名命名

• 只由小写字母组成。不包含大写字母和下划线等字符
• 包含一定上下文信息
• 不与标准库同名。

编码规范

控制流程

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

  

• 优先处理错误和特殊情况，尽早返回或继续循环来减少嵌套

错误和异常处理

简单错误

• 优先使用errors.New来创建匿名变量来直接表示简单错误
• 如果有格式化的需求，使用fmt.Errorf

复杂错误（Wrap和Unwrap）

​ Wrap提供了一个error嵌套另一个error的能力，从而生成一个error的跟踪链

​ 在fmt.Errorf中使用：%w关键字来将一个错误关联至错误链中

错误判定

• 特定错误：使用errors.Is来判断是否为特定错误。不同于使用==，使用该方法可以判定错误链上的所有错误是否含有特定错误

• 特定种类的错误：在错误链上获取特定种类的错误，使用errors.As

panic(注意！我项目里老爱用)

• 只用于真正异常的情况

• 不建议使用（当程序启动阶段发生不可逆转的错误时，可以在init或main函数中使用panic）

recover

• recover生效范围，在当前goroutine的被defer的函数中生效嵌套无法生效

• defer的语句是后进先出

• 常见情况是记录panic的调用栈信息，出现问题时能够方便分析定位。如果需要更多的上下文信息，可以recover后在log中记录当前的调用栈

性能优化（Benchmark工具）

slice使用建议

​ slice预分配内存，预估空间

• 尽可能在使用make()初始化切片时提供容量信息，避免多次拓展（因为要在内存中新开辟一个更大的空间存放并并复制，很浪费）
• 可使用copy代替新建一个slice（避免调用原切片占用的巨大空间，使得原切片的大内存得不到释放）

map使用建议

​ 预分配内存，预估空间，以减少内存拷贝和Rehash消耗

字符串处理

​ 三种字符串拼接方式中，strings.Builder最快，bytes.Buffer其次，+最慢

​ 当使用+拼接2个字符串时，生成一个新的字符串，就需要开辟一段新的空间，新空间的大小是原来两个字符串的大小之和。拼接第三个字符串时，再开辟一段新空间、新空间大小是三个字符串的大小之和，以此类推

​ 而strings.Builder，bytes.Buffer底层都是[]byte 数组内存扩容策略，不需要每次拼接时重新分配内存

空结构体

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

• 实现Set，可以考虑用map来代替
• 对于这个场景，只需要用到map的键，而不需要值
• 即使是将map的值设置为bool类型，也会多占据1个字节空间

atomic包和加锁的区别

• 锁是通过操作系统实现，属于系统调用

• atomic操作是通过硬件实现，效率比锁高

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

• 对于非数值操作，可以使用atomic.Value，能承载一个interface{}

性能调优

原则

• 要依靠数据不是猜测
• 要定位最大瓶颈而不是细枝末节
• 不要过早优化
• 不要过度优化

性能分析工具pprof

作，可以使用atomic.Value，能承载一个interface{}

性能调优

原则

• 要依靠数据不是猜测
• 要定位最大瓶颈而不是细枝末节
• 不要过早优化
• 不要过度优化

性能分析工具pprof

官方文档：https://blog.wolfogre.com/posts/go-ppof-practice/