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

74 阅读6分钟

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

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

一、本堂课重点内容:

本节主要介绍了高质量编程的定义和原则,分享了代码格式、注释、命名规范、控制流程、错误和异常处理五方面的常见编码规范。

二、详细知识点介绍:

高质量编程

简介

  • 什么是高质量——编写的代码能够达到正确可靠、简洁清晰的目标可称之为高质量代码,包括各种边界条件是否考虑完备,异常情况处理,稳定性保证易读易维护等
  • 编程原则——实际应用场景千变万化,各种语言的特性和语法各不相同但是高质量编程遵循的原则是相通的。
    简单性:消除"多余的复杂性”,以简单清晰的逻辑编写代码,不理解的代码无法修复改进。
    可读性:代码是写给人看的,而不是机器,编写可维护代码的第一步是确保代码可读。
    生产力:团队整体工作效率非常重要。

编码规范——如何编写高质量的Go代码

  • 代码格式:推荐使用gofmt自动格式化代码。
  • 注释:注释应该解释代码的作用,代码如何做的,代码实现的原因,代码什么情况会出错,公共符号(包中声明的变量、常量、函数以及结构)始终要注释。In fact,代码是最好的注释,注释应该提供代码未表达出的上下文信息。
  • 命名规范:
    1. 变量(variable)
      简洁胜于冗长;缩略词全大写,但当其位干变量开头且不需要导出时,使用全小写,例如使用ServeHTTP而不是ServeHttp,使用XMLHTTPRequest或者xmlHTTPRequest;变量距离其被使用的地方越远,则需要携带越多的上下文信息;全局变量在其名字中需要更多的上下文信息,使得在不同地方可以轻易辨认出其含义。
    2. 函数(function)
      函数名不携带包名的上下文信息,因为包名和函数名总是成对出现的; 函数名尽量简短; 当名为foo 的包某个函数返回类型Foo时,可以省略类型信息而不导致歧义; 当名为foo的包某个函数返回类型T时(T并不是Foo),可以在函数名中加入类型信息。
    3. 包(package)
      只由小写字母组成。不包含大写字母和下划线等字符;简短并包含一定的上下文信息。例如schema、task 等;不要与标准库同名。例如不要使用sync 或者strings;
      以下规则尽量满足,以标准库包名为例:不使用常用变量名作为包名,例如使用bufio 而不是buf;使用单数而不是复数例如使用encoding而不是encodings;谨慎地使用缩写。例如使用fmt在不破坏上下文的情况下比 format更加简短。
      核心目标是降低阅读理解代码的成本,重点考虑上下文信息,设计简洁清晰的名称
    4. 控制流程
      避免嵌套,保持正常流程清晰;尽量保持正常代码路径为最小缩进;线性原理,处理逻辑尽量走直线,避免复杂的嵌套分支;正常流程代码沿着屏幕向下移动;提升代码可维护性和可读性;故障问题大多出现在复杂的条件语句和循环语句中。 5.错误和异常处理 error:尽可能提供简明的上下文信息链,方便定位问题;
      panic:用于真正异常的情况;
      recover:生效范围,在当前goroutine的被defer的函数中生效;

性能优化指南

  • 性能优化的前提是满足正确可靠、简洁清晰等质量因素;性能优化是综合评估,有时候时间效率和空间效率可能对立;针对Go语言特性,介绍Go相关的性能优化建议
  • 使用方法:性能表现需要实际数据衡量,Go语言提供了支持基准性能测试的benchmark工具go test -bench=. -benchmem
  • 对Slice、map,预分配内存,尽可能在使用make()初始化切片时提供容量信息。
  • 对字符串拼接,使用+拼接性能最差,strings.Builder,bytes.Buffer相近,strings.Buffer更快
  • 使用空结构体节省内存,空结构体struct{} 实例不占据任何的内存空间,可作为各种场景下的占位符使用,节省资源
  • 使用atomic包:锁的实现是通过操作系统来实现,属于系统调用,atomic操作是通过硬件实现,效率比锁高,sync.Mutex应该用来保护一段逻辑,不仅仅用于保护一个变量,对于非数值操作,可以使用atomic.Value,能承载一个interface{}

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

性能优化分析工具

  • 性能调优原则——要依靠数据不是猜测,要定位最大瓶颈而不是细枝末节,不要过早优化,不要过度优化。
  • 性能分析工具pprof——

image.png

性能调优案例——业务服务优化

  • 服务:能单独部署,承载一定功能的程序
    依赖: Service A的功能实现依赖Service B的响应结果,称为Service A依赖Service B
    调用链路:能支持一个接口请求的相关服务集合及其相互之间的依赖关系
    基础库:公共的工具包、中间件
  • 流程:建立服务性能评估手段;分析性能数据,定位性能瓶颈;重点优化项改造;优化效果验证
  • 建立服务性能评估手段——
    服务性能评估方式:单独benchmark无法满足复杂逻辑分析,不同负载情况下性能表现差异 请求流量构造:不同请求参数覆盖逻辑不同,线上真实流量情况
    压测范围:单机器压测,集群压测
    性能数据采集:单机性能数据,集群性能数据
  • 分析性能数据,定位性能瓶颈:使用库不规范,高并发场景优化不足
  • 重点优化项改造:正确性是基础,响应数据diff,线上请求数据录制回放,新旧逻辑接口数据diff
  • 优化效果验证:重复压测验证,上线评估优化效果,关注服务监控,逐步放量,收集性能数据
  • 进一步优化,服务整体链路分析:规范上游服务调用接口,明确场景需求,分析链路,通过业务流程优化提升服务性能
  • AB实验SDK的优化:分析基础库核心逻辑和性能瓶颈,设计完善改造方案,数据按需获取,数据序列化协议优化,内部压测验证,推广业务服务落地验证
  • 编译器&运行时优化:优化内存分配策略,优化代码编译流程,生成更高效的程序,内部压测验证,推广业务服务落地验证

三、课后个人总结:

  • 碍于时间篇幅,本篇笔记待后续继续完善