S.O.L.I.D 原则在 Go 中的应用

前言

由于自己最近灵感枯竭,所以我决定翻译一篇别人的文章 O(∩_∩)O~。作为一个一直想学 Go,但想了好久还没入门的人,我挑了篇写 Go 的文章,顺便帮自己熟悉一下 Go。原文是 Dave Cheney 根据自己 GolangUK 的演讲所整理的,全文以 SOLID 原则为线路,讲述了什么样的 Go 代码才算是好代码,当然 SOLID 原则也适用于其他语言。

英文原文比较长,由我和 Kevin 合译。

世界上有多少个 Go 语言开发者?

介个世界上有多少 Go 开发者捏?在脑海中想一个数字,我们会在最后回到这个话题。
thinking

Code review

有多少人将 code review 当做自己工作的一部分?[听演讲的人都举起了手]。为什么要做 code review?[一些人回答为了阻止不好的代码]

如果 code review 是为了捕捉到不好的代码,那么问题来了,你怎么判断你正在 review 的代码是好还是不好呢?

我们可以很容易的说出“这代码好辣眼睛”或者“这源码写的太吊了”,就像说“这画真美”,“这屋子真大气”一样。但是这些都是主观的,我希望找到一些客观的方法来衡量代码是好还是不好。

Bad code

下面看一下在 code review 中,一段代码有哪些特点会被认为是不好的代码。

  • Rigid 代码是不是很僵硬?是否由于严格的类型和参数导致修改代码的成本提高
  • Fragile 代码是不是很脆弱?是否一点小的改动就会造成巨大的破坏?
  • Immobile 代码是否难以重构?
  • Complex 代码是否是过度设计?
  • Verbose 当你读这段代码时,能否清楚的知道它是做什么的?