这是我参与「第五届青训营 」伴学笔记创作活动的第 4 天
7 高质量编程与性能调优实战
我个人特别推荐有时间的小伙儿可以看看*《设计模式》*这本书，项目颗粒度划分什么的都写的特别的好，可以找比较近的版本查看，这本书的图文解析设计的就非常好。
- 如何编写更简介清晰的代码
- 常用 Go 语言程序优化手段
- 熟悉 Go 语言性能分析工具
- 了解工程中性能优化的原则和流程
7.1 高质量编程
- 高质量编程简介
- 编码规范
- 性能优化建议
7.1.1 简介
什么是高质量
-----我的见解：就是代码的五个特性：便于维护、可复用、可扩展、强灵活性和强健壮性
编程原则
简单性
- 消除“多余的复杂性”，以简单清晰的逻辑编写代码
- 不理解代码无法修复改进
可读性
- 代码是写给人看的，而不是机器（机器就只是负责运行）
- 编写可维护代码的第一步是确保代码可读
生产力
- 整体团队的工作效率非常重要
7.1.2 编写规范
如何编写高质量的 Go 代码
- 代码格式
- 注释
- 命名规范
- 控制流程
- 错误和异常处理
7.1.2.1 编码规范-代码格式
推荐使用 go 的fmt 自动格式化代码
7.1.2.2 编码规范-注释
简介
注释应该做的：
- 解释代码作用
- 解释代码如何做的
- 解释代码实现的原因
- 解释代码什么情况会出错（错误返回）
说白了就是 注释提供的代码要表达出上下文信息
7.1.2.3 编码规范-命名规范
function
- 函数名不携带报包名的上下文信息，因为包名和函数名总是成对出现的
- 函数名尽量简短
package
- 只由小写字母组成。
- 简短并包含一定的上下文信息。
- 不要与标准库同名。
尽量满足以下规则：
- 不用常量作为包名
- 单数而不是复数
- 谨慎的使用缩写
说白了就是简单理解，上下关联，一看就懂
7.1.2.4 编码规范-控制流程
避免嵌套，保持正常流程清晰
循环、条件等在非必要情况下尽量不使用条件判断
尽量保持正常代码路径为最小缩进
- 优先处理错误情况/特殊情况，尽早返回或继续循环来减少嵌套
需要满足多个条件才能正常执行的代码片段，各个满足条件可以分开写，减少循环的嵌套。
说白了就是线性原理、从上到下、可维可读
7.1.2.5 编码规范-错误和异常处理
简单错误
- 出现一次的错误，且在其它地方不需要进行捕获
- 优先使用
errors.New("")来创建匿名变量来直接表示简单错误 - 如果由格式化的需求，使用fmt.Errof
错误的Wrap 和 Unwrap
- 错误的Wrap 实际上是提供了一个error嵌套另一个error的能力，从而生成了一个 error 的跟踪链
- 在fmt.Errorf 中使用: %w 关键字来将一个错误关联至另一个错误链中
错误判定
- 判定一个错误是否为特定错误，使用errors.ls
- 不同于使用 == ，该方法可以判断错误链是否含有特定的错误
- 在错误连上获取特定种类的错误，使用errors.As
panic
我建议就是 panic 和 recover 成对出现避免程序崩溃
只在必要情况下使用panic
recover
- recover 只能在被derfer 的函数中使用
- 嵌套无法生效
- 只在当前 goroutine 生效
- defer 的语句是后进先出
- 如果需要更多的上下文信息，可以在 recover 后在 log中记录当前的调用栈
debug.Stack()
小结
- error 尽可能提供简明的上下文信息链，方便定位问题
- panic 用于真正的异常情况
- recover 生效范围，在当前 goroutine 的被 defer 的函数中生效
