接口最好从调用方倒着定义,别在实现还没稳定时先抽象
· 阅读需 3 分钟
Go 学久一点以后,很多人都会记住一句话:interface 要小。但真到项目里,接口问题往往不是“大或小”这么简单,而是抽象出现得太早。实现只有一种、调用方式还没定稳,就先定义一堆 UserService、OrderRepository 接口,最后只会让代码多一层跳转。
Go 学久一点以后,很多人都会记住一句话:interface 要小。但真到项目里,接口问题往往不是“大或小”这么简单,而是抽象出现得太早。实现只有一种、调用方式还没定稳,就先定义一堆 UserService、OrderRepository 接口,最后只会让代码多一层跳转。
刚开始写 Go 的时候,很多人会觉得错误处理很重复:每层都要判断 err != nil,看起来很机械。可真到了线上排查问题时,最怕的不是判断多,而是最后拿到的错误只有一句 “open failed” 或 “query error”,根本不知道是哪一步出的事。
很多人刚写 Go 项目时,最有安全感的动作就是先把目录搭完整:controller、service、dao、model、utils 先分好,觉得以后扩展会方便。可项目在功能还不稳定的时候,包分得太细,往往比全写在一个地方更容易把自己绕进去。
刚开始学 Go,并发部分最容易让人紧张的词就是“死锁”。这当然没错,因为死锁一出现,程序常常会非常明显地挂在那里。可等你真正把 Go 服务跑起来一段时间后,会发现另一类问题更难受:goroutine 没有马上死掉,而是在后台一点点堆起来。