前言
由于自己最近灵感枯竭，所以我决定翻译一篇别人的文章 O(∩_∩)O~。作为一个一直想学 Go，但想了好久还没入门的人，我挑了篇写 Go 的文章，顺便帮自己熟悉一下 Go。原文是 Dave Cheney 根据自己 GolangUK 的演讲所整理的，全文以 SOLID 原则为线路，讲述了什么样的 Go 代码才算是好代码，当然 SOLID 原则也适用于其他语言。
世界上有多少个 Go 语言开发者？
介个世界上有多少 Go 开发者捏？在脑海中想一个数字，我们会在最后回到这个话题。
Code review
有多少人将 code review 当做自己工作的一部分?[听演讲的人都举起了手]。为什么要做 code review？[一些人回答为了阻止不好的代码]
如果 code review 是为了捕捉到不好的代码，那么问题来了，你怎么判断你正在 review 的代码是好还是不好呢？
我们可以很容易的说出“这代码好辣眼睛”或者“这源码写的太吊了”，就像说“这画真美”，“这屋子真大气”一样。但是这些都是主观的，我希望找到一些客观的方法来衡量代码是好还是不好。
Bad code
下面看一下在 code review 中，一段代码有哪些特点会被认为是不好的代码。
- Rigid 代码是不是很僵硬？是否由于严格的类型和参数导致修改代码的成本提高
- Fragile 代码是不是很脆弱？是否一点小的改动就会造成巨大的破坏？
- Immobile 代码是否难以重构？
- Complex 代码是否是过度设计？
- Verbose 当你读这段代码时，能否清楚的知道它是做什么的？