高质量编程及代码规范|青训营

mchale
67 阅读11分钟

高质量编程简介及代码规范

1.1 简介

高质量：编写的代码能够达到正确可靠、简洁清晰的目标课称之为高质量代码
正确性：边界条件是否考虑完备； 可靠：异常情况处理，稳定性保证； 简洁清晰：代码给别人看，易读易维护，逻辑简单

编程原则

简单性

用简单清晰的逻辑编写代码
不理解的代码无法修复改进

可读性

代码给人看，人要看得懂
编写可维护代码的第一步是确保代码可读

生产力

团队整体工作效率

1.2 编码规范

1.2.1 代码格式

推荐使用gofmt自动格式化代码
gofmt：go语言官方提供的工具，能自动格式化go语言代码为官方统一风格，常见ide都支持方便的配置
goimports：也是go语言官方提供的工具，实际等于gofmt加上依赖包管理，自动增删依赖的包引用、将依赖包按钮字母序排序并分类。

1.2.2 注释

注释应该做的：

  1. 解释代码作用
  2. 解释代码如何做的
  3. 解释代码实现的原因
    提供上下文
  4. 代码什么情况会出错
    代码的限制条件
    公共符号始终要注释
    包中声明的每个公共的符号：变量、常量、函数以及结构都需要添加注释
    描述函数的功能、用途 任何既不明显也不简短的公共功能必须注释
    无论长度或复杂程度如何，对库中的任何函数都必须注释
    注释和代码逻辑可能不一样：一开始是符合的，后来修改的时候改了代码，没改注释

1.2.3 命名规范

变量名

  1. 简洁胜于冗长
  2. 缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写。
  3. 变量距离其被使用的地方越远，需要带更多的上下文信息。
    如全局变量在名字中要更多的上下文信息，使得在不同的地方可以轻易辨认出其含义。

函数名

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

包名

  1. 只由小写字母组成，不包含大写字母和下划线等字符
  2. 简短并包含一定的上下文信息，如schema、task等
  3. 不要与标准库同名。如sync或strings 以下规则尽量满足，以标准库包名为例：
  4. 不使用常用变量名作为包名。如使用bufio而不是buf
  5. 使用单数而不是复数。如encoding而不是encodings
  6. 谨慎地使用缩写。如使用fmt在并不破坏上下文的情况下比format更加简短的。

小结

核心目标是降低阅读理解代码的成本
重点考虑上下文信息，设计简洁清晰的名称

1.2.4 控制流程

避免嵌套，保持正常流程清晰

如if else
若两个分支中都包含return，可以去除冗余的else

尽量保持正常代码路径为最小缩进

优先处理错误情况/特殊情况，尽早返回或继续循环来减少嵌套 对比如下代码：

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

//good 
fun OneFunc() error{
　　if err := doSomeThing(); err != nil{
　　　　return err
　　}
　　if err := doAnotherThing(); err != nil{
　　　　return err
　　}
　　return nil // normal case
}

小结

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

1.2.5 错误和异常处理

简单错误

  1. 简单的错误指的是仅出现一次的错误，且在其他地方不需要捕获该错误
  2. 优先使用errors.New来创建匿名变量来直接表示简单错误
func defaultCheckRedirect(req *Request, via []*Request) error{
　　if len(via) >= 10{
　　　　 return errors.New("stopped after 10 redirects")
　　}
　　return nil
}
  1. 若有格式化的需求，使用fmt.Errorf

复杂的错误：错误的Wrap和Unwrap

  1. 错误的Wrap实际上是提供了一个error嵌套另一个error的能力，从而生成了error的跟踪链
  2. 在fmt.Errorf中使用 %w 关键字来将一个错误关联至错误链中
    结合实际的错误的判定方法，确定错误链中是否有我们关注的错误出现
    每一层的调用方都可以补充错误的上下文信息，方便跟踪排查问题
list, _, err := c.GetBytes(cache.Subkey(a.actionID, "srcfiles"))
if err != nil{
　　return fmt.Errorf("reading srcfiles list: %w", err)
}

错误判定

error.Is

判定一个错误是否为特定错误，使用errors.Is
不同于使用==，使用该方法可以判定错误链上的所有错误是否含有特定的错误
错误链上可能有很多种错误

error.As

在错误链上获取特定种类的错误

panic

比错误更严重，它出现表示程序没办法正常工作

  1. 不建议在业务代码中使用 panic
  2. 调用函数不包含recover会造成程序崩溃
  3. 若问题可以被屏蔽或解决，建议使用error代替panic
  4. 当程序启动阶段发生不可逆转的错误时，可以在init或main函数中使用panic，让问题早点暴露出来。

recover

有panic，就有对应的recover机制来处理
引用其他的库有bug或panic影响到自身逻辑，就使用recover机制

  1. recover只能在被defer的函数中使用
  2. 嵌套无法生效
  3. 只在当前goroutine生效
  4. defer的语句是后进先出
  5. 若需要更多的上下文信息，可以recover后再log中记录当前的调用栈
　　defer func(){
　　　　if e:=recover(); e != nil{
　　　　　　f = nil
　　　　　　err = fmt.Errorf("gitfs panic: %v\n%s", e, debug.Stack())
　　　　}
　　}()
}

1.3 性能优化建议

  1. 性能优化的前提是满足正确可靠、间接清晰等质量因素
  2. 性能优化是综合评估，有时候时间效率和空间效率可能对立

1.3.1 benchmark

go test -bench=. -benchmem
我的运行结果： image.png 第二个数：一共执行次数，即b.N的值
第三个数：每次执行花费时间

1.3.2 slice

预分配内存

尽可能在使用make()初始化切片时提供容量信息，指定slice的大小，时间会更短，消耗容量也更小。

  1. 切片本质是一个数组片段的描述，包括数组指针、片段的长度、片段的容量（不改变内存分配情况下的最大长度）
  2. 切片操作并不复制切片指向的元素
  3. 创建一个新的切片会复用原来切片的底层数组

大内存未释放

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

//在原数组基础上创建切片
func GetLastBySlice(origin []int)[]int{
　　return origin[len(origin)-2:]
}
//创建新的切片，把数据复制过去
func GetLastByCopy(origin []int) []int{
　　result := make([]int,2)
　　copy(result,origin[len(origin)-2:])
　　return result
}

若数组origin很大，则第一个函数的内存占了很大，而第二个函数内存很小。

1.3.3 map

预分配内存

make(map [int]int) vs make(map[int]int,size)
预分配了性能会更好

  1. 不断向map中添加元素的操作会触发map的扩容
  2. 提前分配好空间可以减少内存拷贝何rehash的消耗
  3. 建议根据实际需求提前预估好需要的空间

1.3.4 字符串处理

使用strings.Builder拼接字符串

  1. s += str
  2. builder.WriteString(str)
  3. buf.WriteString(str) 1时间性能最差，2、3时间差不多，但2 的更短一些
    分析：
  4. 字符串在go语言中是不可变类型，占用内存大小是固定的
  5. 使用+每次都会重新分配内存
  6. 2和3底层都是[]byte数组，它的内存扩容策略，不需要每次拼接重新分配内存
    使用buffer：重新申请空间，创建字符串
    使用builder：将底层数组转成字符串返回，性能更好

strings.builder也可以预分配内存

builder.Grow(len(str)) 性能更好

1.3.5 空结构体

使用空结构体节省内存

空结构体struct{}实例不占据任何内存空间，可作为各种场景下的占位符使用。
节省资源，而且空结构体本身具备很强的语义，不需要任何值，仅作为占位符。

使用场景

实现Set，可以考虑用map代替。
只需要用到map的键，不需要值。 就可以make(map[int]struct{})

1.3.6 atomic包

多线程编程的场景，可以用到atomic包的原子变量或者加锁
但是atomic包的时间性能更好

使用方法

  1. 锁的实现是通过操作系统实现，属于系统调用，调用成本高
  2. atomic操作是通过硬件实现，效率比锁高。
  3. sync.Mutex应该用来保护一段逻辑，不仅仅用于保护一个变量。若是只要保护一个变量的时候，可以考虑atomic包
  4. 对应非数值操作，可以使用atomic.Value，能承载一个interface{}

小结

  1. 避免常见的性能陷阱可以保证大部分程序的性能
  2. 普通应用代码，不要一味地追求程序的性能。
  3. 越高级的性能优化手段越容易出现问题
  4. 在满足正确可靠、简洁清晰的质量要求的前提下提高程序性能

2. 性能调优实战

2.1 性能调优原则

  1. 要依靠数据而不是猜测 实际的运行环境和逻辑可能不一样
  2. 要定位到最大瓶颈，而不是细枝末节，对性能影响不大的那些部分
  3. 不要过早优化 在迭代过程中，逻辑会变化，用户数量变化，等到快出现性能问题的时候再分析
  4. 不要过度优化
    若选定了特定的优化手段，再升级的时候可能难以兼容

2.2 说明

pprof工具可以直到应用再什么地方耗费了多少CPU、memory pprof是用于可视化和分析性能分析数据的工具

2.2.1 功能简介

image.png 四大块：

  1. 提供相关工具
  2. 采样不同类型的数据
  3. 网页端、可视化终端的profile的分析
  4. 支持多种展示类型，根据需要选择类型图

2.3 性能调优案例

2.3.2 业务服务优化

基本概念

示例图：
网端 服务端 调用其他service（依赖）调用链 基础库：监控打点，日志记录

流程

1. 建立服务性能评估手段

对整体分析，单独benchmark不合适，要从更高层面分析

请求流量构造： 不同参数的逻辑不同，对性能的影响不同
要能覆盖线上真实流量

压测范围：
先单机器压测
再集群压测
有压测报告：
接口耗时；平均QPS

性能数据采集：
单机性能数据
集群性能数据

2. 分析性能数据，定位性能瓶颈

pprof工具看哪些部分耗资源，分析瓶颈
使用库不规范
高并发场景优化不足

3. 重点优化项改造（最耗资源的那部分）

正确性是基础：
修改前后的请求和响应 差别应该不大 响应数据diff：
线上请求数据录制回放； 新旧逻辑接口数据diff

4. 优化效果验证

重复压测验证
上限评估优化效果：
关注服务监控；
逐步放量；
收集性能数据；

5. 进一步优化，服务整体链路分析

规范上游服务调用接口，明确场景需求；
分析链路，通过业务流程优化提升服务性能；
若A重复调用B，考虑能否合并；

2.3.2 基础库优化

2.3.3 go语言优化

编译器、运行时优化
优化内存分配策略、优化代码编译流程，生成更高效的程序
内部压测验证
推广业务服务落地验证
优点：
接入简单，只需要调整编译配置
通用性强

avatar
文章
阅读
粉丝