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

56 阅读3分钟

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

一、本堂课重点内容:

本堂课的知识要点有哪些?

-- 介绍编码规范,帮助大家写出高质量程序

  • 介绍 Go 语言的性能优化建议,分析对比不同方式对性能的影响和背后的原理

  • 讲解常用性能分析工具 pprof 的使用和工作原理,熟悉排查程序性能问题的基本流程

  • 分析性能调优实际案例,介绍实际性能调优时的工作内容

image.png 二、详细知识点介绍:

本堂课介绍了哪些知识点?

常见编码规范

代码格式
  • 使用 gofmt 自动格式化代码,保证所有的 Go 代码与官方推荐格式保持一致

总结

  • 提升可读性,风格一致的代码更容易维护、需要更少的学习成本、团队合作成本,同时可以降低 Review 成本
注释
  • 注释应该解释代码作用

  • 注释应该解释代码如何做的

  • 注释应该解释代码实现的原因

  • 注释应该解释代码什么情况会出错

  • 公共符号始终要注释

总结

  • 代码是最好的注释
  • 注释应该提供代码未表达出的上下文信息
命名规范
  • variable

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

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

    • 只由小写字母组成。不包含大写字母和下划线等字符
    • 简短并包含一定的上下文信息。例如 schema、task 等
    • 不要与标准库同名。例如不要使用 sync 或者 strings

总结

  • 关于命名的大多数规范核心在于考虑上下文

  • 人们在阅读理解代码的时候也可以看成是计算机运行程序,好的命名能让人把关注点留在主流程上,清晰地理解程序的功能,避免频繁切换到分支细节,增加理解成本

错误和异常处理
  • panic

    • 不建议在业务代码中使用 panic
    • 如果当前 goroutine 中所有 deferred 函数都不包含 recover 就会造成整个程序崩溃
  • recover

    • recover 只能在被 defer 的函数中使用,嵌套无法生效,只在当前 goroutine 生效

总结

  • panic 用于真正异常的情况

  • error 尽可能提供简明的上下文信息,方便定位问题

  • recover 生效范围,在当前 goroutine 的被 defer 的函数中生效

三、实践练习例子:

有什么实践举例帮助理解知识点?

性能分析工具

性能调优的核心是性能瓶颈的分析,对于 Go 应用程序,最方便的就是 pprof 工具

image.png

实战源码链接: link.juejin.cn/?target=htt…

pprof 的采样过程和原理

image.png

image.png

image.png 四、课后个人总结:

  • 本章有什么知识点不容易掌握?
  • 什么地方容易与其他内容混淆?

五、引用参考:

  • 我参考了哪些外部博客/笔记/文章?
  • 文章中有什么地方是我参考引用了外部博客/笔记/文章的?