这是我参与「第三届青训营 -后端场」笔记创作活动的的第1篇笔记
01 并发vs并行
区别：并发：多线程程序在一个核的CPU上运行 并行：多线程在多个核的CPU上运行 1.1Gorouting（高效） 内核态：线程(内核态，线程跑多个协程，栈KB级别)
用户态：协程（用户态，轻量级线程。栈MB级别） 1.2CSP(Communicating Sequential Processes) 提倡通过通信共享内存而不是通过共享内存而实现通信 1.3Channel make(chan 元素类型，[缓冲大小]） 有缓冲通道 make(chan int,2) 无缓存 make (chan int) 1.4并发安全Lock 1.5WaitGroup 计数器：开启协程+1，执行结束—1，主协程阻塞直到计数器为0，
02 依赖管理 各种开发包（利用已有的工具提升效率） 工程项目不可能基于标椎库0~1编码的搭建 管理依赖库 2.1GO依赖管理推进 G0PATH------GO Vendor----G module 不同环境（项目）依赖的版本不同，控制依赖库的版本 2.1.1GOPATH 项目代码直接依赖src下的代码 go get 下载最新版本的包到src目录下 （bin--------项目编译的二进制文件 pkg-------项目编译的中间产物，加速编译 src--------项目源码） 弊端：无法实现package的多版本控制 2.1.2Go Vendor 项目目录下增加vendor文件，所有依赖包副本形式放在$ProjectRoot/vendor 依赖寻址方式：vendor=>GOPATH （通过每个项目引入一份依赖的副本，解决了多个项目需要同一个package依赖的冲突问题。） 弊端：一旦更新项目，无法控制依赖的版本，可能出现依赖冲突，导致编译错误（主要依赖于源码的编译） 2.1.3Go Module 通过go.mod文件管理依赖包版本 通过go get/go mod指令管理依赖包 终极目标：定义版本规则和管理项目依赖关系 2.2依赖管理三要素 1.配置文件------go.mod 中心仓库管理依赖库 Proxy 本地工具 --------go get/mod 2.3.1依赖配置--go.mod (module example/project/app 依赖管理基本单元 go 1.16 ------原生库 require{ example/libl v1.0.2
}单元依赖
依赖标识：[Module Path][Version/Pseudo-version] 2.3.2依赖配置----version 语义化版本 MAJOR−−−−−大版本，不同的版本见代码隔离，.{MINOR}----要做到见后兼容${PATH}---bug的修复
基于commit伪版本
2.3.3依赖配置---indirect 没有直接依赖的用 indirect标识出来 2.2.4-------incomatible 主版本2+模块会模块路径增加/vN后缀 对于没有go.mod文件并且主版本2+的依赖，会+incompatible 2.3.4 依赖配置-----依赖图----选择最低版本 2.3.5 ---回源 直接从第三方使用源码存在一定的问题 1.无法保证构建稳定性 增加/修改/删除软件版本 2.无法保证依赖可用性 删除软件 3.增加第三方压力 代码托管平台负载问题 2.3.5 依赖分发----Proxy（稳定可靠） 2.3.6 依赖分发-变量GOPROXY GOPROXY=“proxy1.cn,https://proxy2.cn,… 2.3.7工具-----go get go get example.org/pkg{
@ update 默认 @none 删除依赖 @v1.1.2 tag版本，语义版本 @23dfdd5 特定的commit @master 分枝的最新的commit 2.3.8 工具--go mod { init 初始化，创建go.mod文件 download 下载模块到本地缓存 tidy 增加需要的依赖，删除不需要的依赖（可减少构建的时间） } 二 测试（回归测试----集成测试-----单元测试（一定程度上决定代码质量）） 3.1单元测试（期望与测试相同------保证质量，提升效率） 3.1.1单元测试规则 所有测试文件已_test.go结尾 fun Test Xxx(*testing.T) 初始化逻辑放到TestMain中
3.1.5 单元测试--覆盖率（越完备越好）通过对各个分支的测试，提高覆盖率 tips：一般测试50%-60%，较高80%+ 测试分枝相互独立，全面覆盖 测试单元粒度足够小，函数单一 3.2单元测试--依赖 外部依赖=>稳定&幂等 3.3单元测试---文件测试 3.4 单元测试--Mock 快速Mock函数 为一个方法/函数打桩
3.5基准测试 优化代码，需要对当前的代码分析 内置的测试框架提供了基准测试的能力 4项目实践
