<p><strong>Write tests to lock in the behaviour of your package’s API</strong><br> Test first or test later, if you shoot for 100% test coverage or are happy with less, regardless your package’s API is your contract with its users. Tests are the guarantees that those contracts are written in. Make sure you test for the behaviour that users can observe and rely on.</p>

<p><strong>If you think it’s slow, first prove it with a benchmark</strong><br> So many crimes against maintainability are committed in the name of performance. Optimisation tears down abstractions, exposes internals, and couples tightly. If you’re choosing to shoulder that cost, ensure it is done for good reason.</p>

<p><strong>Moderation is a virtue</strong><br> Use goroutines, channels, locks, interfaces, embedding, in moderation.<br>Maintainability counts</p>

<p><strong>每个包实现单一目标</strong><br>设计良好的 Go 软件包提供一个单一的思路，以及一系列相关的行为。一个好的 Go 软件包首先需要选择一个好名字，使用电梯法则（30 秒内向客户讲清楚一个方案），仅用一个词来思考你的软件包要提供什么功能。</p>

<p><strong>明确处理错误</strong><br>健壮的程序其实是由处理故障案例的片段组成的，并且需要在故障出现之前处理好。冗余的if err != nil { return err }比出了故障再一个个去处理更有价值。panic 和 recover 也一样。</p>

<p><strong>尽早 return，不要深陷</strong><br>每次缩进时都会在程序员的堆栈中添加另一个先决条件，这会占用他们短期内存中的 7±2 个片段。避免需要深层缩进的控制流。与其深入嵌套，不如使用守卫子句将成功路径保持在左侧。</p>