在本月初的 GopherCon 上,知名 Go 语言贡献者与布道师 Dave Cheney 发表了名为《The Zen of Go》的演讲,之后他整理了演讲内容在博客中分享,由于内容过长,他又写了一个简洁版本:
-
完整版:
https://dave.cheney.net/2020/02/23/the-zen-of-go
-
简洁版:
https://the-zen-of-go.netlify.com
这里简单翻译一下简洁版本的内容:
编写简单、可读、可维护的 Go 代码的十个工程要点。
每个包实现单一目标
设计良好的 Go 软件包提供一个单一的思路,以及一系列相关的行为。一个好的 Go 软件包首先需要选择一个好名字,使用电梯法则(30 秒内向客户讲清楚一个方案),仅用一个词来思考你的软件包要提供什么功能。
明确处理错误
健壮的程序其实是由处理故障案例的片段组成的,并且需要在故障出现之前处理好。冗余的if err != nil { return err }
比出了故障再一个个去处理更有价值。panic 和 recover 也一样。
尽早 return,不要深陷
每次缩进时都会在程序员的堆栈中添加另一个先决条件,这会占用他们短期内存中的 7±2 个片段。避免需要深层缩进的控制流。与其深入嵌套,不如使用守卫子句将成功路径保持在左侧。
并发权留给调用者
让调用者选择是否要异步运行你的库或函数,不要强制他们使用异步。
在启动 goroutine 之前,要知道它什么时候会停止
goroutines 拥有资源、锁、变量与内存等,释放这些资源的可靠方法是停止 goroutine。
避免包级别的状态
要完成明确和减少耦合的操作,需要通过提供类型需要的依赖项作为该类型上的字段,而不是使用包变量。
简单很重要
简单不是老练的代名词。简单并不意味着粗糙,它意味着可读性和可维护性。如果可以选择,请遵循较简单的解决方案。
编写测试以确认包 API 的行为
软件包的 API 是与使用者的一份合约,不管先后,不管多少,一定要进行测试。测试是确定合约的保证。要确保测试使用者可以观察和依赖的行为。
如果你认为性能不行,先通过基准测试进行验证
以性能之名会犯下许多危害可维护性的罪行。优化会破坏抽象、暴露内部和紧密耦合。如果要付出这样的代价,请确保有充分理由这样做。
节制是一种美德
适度使用 goroutine、通道、锁、接口与嵌套。
文章评论