几年前写过一篇 如何使你的代码达到 awesome-go 的入选标准
[http://xargin.com/how-to-meet-the-quality-standard-of-awesome-go/]
。几年过去了，标准和工具都有所变化。
linter 已经换了两代，刚开始是散乱的 golint，go vet，staticcheck，后来出现了 gometalinter，把散乱的工具集集成到一起。
gometalinter 时代，我把这个工具集成到了当时组内所有项目 Makefile 里，合并代码前要求提交者自行执行 make lint
来检查不符合规范的代码并修正，可惜 Makefile
里的命令没有强制约束，某些没有追求的程序员根本不把君子之约当回事，
坊间传言 fasthttp 在某些场景下比 nginx 还要快，说明 fasthttp 中应该是做足了优化。我们来做一些相关的验证工作。
先是简单的 hello server 压测。下面的结果是在 mac 上得到的，linux 下可能会有差异。
fasthttp：
~ ❯❯❯ wrk -c36 -t12 -d 5s http://127.0.0.1:8080
Running 5s test
架构的腐化是必然的，不以人的意志为转移。
我们先从一个故事开始，从前有一个公司，这个公司有一个部门，这个部门里有两个组。
两个组做的项目比较类似，都是策略类项目。
其中一个组做需求基本靠堆人，业务和 PM 的所有需求，能找到人，并且让这个人在各种场景，各种模块，各种分支里加 if else
就可以搞定，代码膨胀飞快。很快没人能说得清项目内的细节，但是公司业务涉及的策略又很多，需求做不过来，所以疯狂堆人，小组规模迅速膨胀到几十个人。大家都很忙碌，充实，每天都在加班，就是代码稍微有点看不懂，但这不重要。重要的是大家都很充实且周报饱满。小组
leader
注意，这里讨论的内容可能有争议。如果不同意，欢迎讨论。
awesome-go 要求项目测试覆盖率达到 80% 以上才符合入选标准。有一些公司也会要求项目有相对合理的测试覆盖率(如 70%
以上才符合代码准入条件等等)。
但有时，我们的逻辑代码却挺难做到这么高的覆盖率，主要还是因为目前 Go 的错误处理逻辑：
func Register(req RegisterReq) error{
if len(req.Username) == 0 {
return errors.New("length of username
之前 go mod 用的比较少，而且一直听社区有各种抱怨，所以也兴趣寥寥。新公司的项目直接使用了 go
mod，本来觉得无非是个简单的工具，不需要学习，结果在一个简单的依赖上却浪费了很多时间。
先来看看我碰到的例子：
package main
import "fmt"
import registry "github.com/apache/dubbo-go/registry"
import zk "github.com/apache/dubbo-go/registry/zookeeper"
import
