本文来自我在GopherCon Israel 2020上的演讲。文章很长:) 如果您希望阅读精简版，请移步到the-zen-of-go.netlify.com。

该演讲视频还未上线。如上线，我会把它更新到本文中的。

我应该如何编写出好代码？

我最近一直在思考很多事情，每当反思自己的工作成果时，眼前常会出现一行字幕：我该如何编写出好代码？ 主观上，没人愿意去编写糟糕的代码，那么问题来了：你是怎么知道你编写出好的Go代码了呢？

如果好与坏之间存在连续性，那么我们怎么知道哪些是好的部分？它的特性、属性、标志、模式和惯用法又是什么呢？

Go语言惯用法(idiomatic Go)

这让我走进Go惯用法。说某种东西是惯用的，就是说它遵循了时代的风格。如果某些东西不是惯用的，那它没有遵循流行的风格，感觉不时髦。

更重要的是，对某人说他们的代码不复合惯用法并不能解释为什么这些代码不符合惯用法。为什么会这样？像所有真相一样，答案可以在词典中找到：

idiom (noun): a group of words established by usage as having a meaning not deducible from those of the individual words.
惯用法（名词）：一组由用法确定的且其含义无法从单个单词的含义中推导出来的单词。

惯用法是共享价值观(value)的标志。Go惯用法不是您从书本中学到的东西，而是通过成为社区的一部分而获得的。

Go惯用法字样用多了，便形成了“口头禅”，这引起我的担忧：这种口头禅在许多方面它可能是具有排他性的。比如：有人说“你不能和我们坐在一起。” 但毕竟这不是我们批评某人的代码不符合惯用法时的索要表达的意思，是吧？他们只是没有做对，看起来不对，它没有遵循流行的风格而已。

我认为Go惯用法不是教如何编写好的Go代码的合适机制，因为从根本上说，它仍然告诉某人做错了(译注：这容易引起对方反感)。如果在他们最愿意接受建议的时候，我们给出让他们不感觉疏远的建议是否会更好些？

谚语(Proverbs)

摆脱有问题的惯用法，Gopher们还有哪些其他的文化手工艺品吗？也许我们可以转向Rob Pike精彩的Go 谚语。这些谚语是合适的教学工具吗？它们会告诉Go新手如何编写好的Go代码吗？

总的来说，我不这么认为。这并不是要驳斥Rob Pike的作品。只是像濑越宪作（Segoe Kensaku）的原著一样，Go谚语只是观察，而不是价值观的陈述。我们再次搬出字典：

proverb (noun): a short, well-known pithy saying, stating a general truth or piece of advice.
谚语（名词）：简短而众所周知的俗语，陈述一般的真理或一段忠告。

Go Proverbs的目的是揭示有关语言设计的更深层次的真理，但是像empty interface says nothing这样的建议对于一个来自商没有结构化类型的语言的新手来说有什么用呢？

重要的是要认识到，在一个不断发展的社区中，任何时候学习Go语言的人的数量都远超过那些声称掌握了该语言的人的数量。因此，在这种情况下，谚语可能也不是最佳的教学工具。

工程价值观

丹·卢（Dan Luu）找到了马克·卢科夫斯基（Mark Lucovsky）关于Windows团队在Windows NT-Windows 2000开发阶段时的工程文化的演讲。我之所以提到它，是因为卢科夫斯基将一种文化描述为一种评估设计和权衡取舍的常用方法。

讨论文化的方法有很多，但是就工程文化而言，Lucovsky的描述是恰当的。其中心思想是在未知的设计空间中用价值观指导决策。Windows NT团队的价值观是：可移植性，可靠性，安全性和可扩展性。粗略地说工程价值观就是在这里完成工作的方式。

Go的价值观

Go的显式价值观是什么呢？定义Go程序员解释世界方式的核心信念或哲学又是什么？他们如何发布宣传？他们怎么传授？如何执行？它们又是如何随着时间变化的？

作为新Go程序员，您将如何被灌输Go的工程价值观？或者，你是一位经验丰富的Go专家，你如何将你的价值观传播给“下一代”？就像我们知道的那样，知识传递的过程不是一个可选项。没有新的血液和新的观念，我们的社区将变得短视和枯萎。

其他语言的价值观

为了给我所要了解的场景做铺垫，我们可以先看看其他语言，我们看看它们的工程价值观。

例如，C++（包括其扩展：Rust）认为程序员不必为自己不使用的特性付费。如果程序未使用该语言的某些计算成本昂贵的特性，则不应强迫该程序承担该特性的成本。该价值观从语言扩展到其标准库，并用作判断所有用C++编写的代码设计的标准。

在Java，Ruby和Smalltalk中，一切都是对象的核心价值观驱动着围绕着消息传递，信息隐藏和多态的程序设计风格。在程序中采用过程式或函数式设计风格会被认为是错误的，或者按照Gophers的说法，是不符合惯用法的。

回到我们自己的Go社区，烙印在Go程序员心中的工程价值观是什么呢？在我们社区中的讨论是很容易引战的，因此要从第一条原则衍生出一套价值观念将是一个巨大的挑战。共识很关键，但随着讨论贡献者数量的增加，难度就成倍增加。但是，如果有人已经为我们完成了这些艰苦的工作了呢？

~~Python~~ Go之禅

几十年前，蒂姆·彼得斯（Tim Peters）坐下来写下了PEN-20（Python之禅）。Peters试图记录他认为Guido van Rossum(Python之父)在Python社区扮演的BDFL(仁慈的独裁者)角色时所应用的工程价值观。

在本文的剩余部分中，我将着眼于Python之禅，并问问大家：是否有什么可以用来揭秘Go程序员的工程价值观的？

一个好的package始于一个好名字

让我们从香辛的东西开始

“Namespaces are one honking great idea–let’s do more of those!” The Zen of Python, Item 19
“命名空间是一个很棒的主意-让我们多做些吧！” Python之禅，条款19

这是相当明确的，Python程序员应该使用命名空间，多多益善。

package就是Go语言的命名空间。我怀疑是否有人质疑将组件分组到程序包中利好设计和潜在重用。但关于这么做的正确方法的困惑肯定会有的，尤其是你拥有另一门语言10年的使用经验。

在Go中，每个程序包都应有一个目的/用途，而了解程序包目的/用途的最佳方法是通过其名字-一个名词。包的名字描述了它提供的内容。因此，这里重新解释一下Peters的话：每个Go软件包(package)都应该仅有一个单一的目的/用途。

这不是一个新主意，我已经说了一段时间了，但是为什么要这样做而不是使用将软件包用于细粒度分类的方法呢？为什么，因为变化(change)。

“Design is the art of arranging code to work today, and be changeable forever.” - Sandi Metz
“设计是安排代码以使其至今天仍然可以工作并且永远可以更改的艺术。” - 桑迪·梅斯

变化是我们所从事的游戏的名称(译注：这里的游戏指代程序开发工作)。作为程序员，我们要做的就是管理变变化。当我们做得很好时，我们称之为设计或架构。当我们做得不好时，我们称其为技术债务或遗留代码。

如果你编写的程序对于一组固定的输入可以一次性地完美地工作，那么没人会在乎代码的好坏，因为最终程序的输出才是企业和业务所关心的。

但这是不正确的。软件具有缺陷(bug)，需求变更，输入变更，并且很少有程序被编写为仅执行一次，因此您的程序会随着时间而变化。可能是您要为此承担任务，更有可能是其他人，但是必须更改该代码。有人必须维护该代码。

那么，如何使程序更改变得容易呢？无所不在的接口？使一切变得易于mock？邪恶的依赖注入(译注：作者对DI似乎很排斥，用了带有感情色彩的词汇)？好吧，也许，对于某类程序，但不是很多，这些技术将很有用。但是，对于大多数程序而言，预先设计一些灵活的方法要比工程设计更为重要。

相反，如果我们采取的立场是取代组件而不是增强组件，该怎么办？知道何时需要更换某些物品的最佳方法是什么时候该物品没有按照锡盒/罐头盒上的说明进行操作。

一个好的包始于选择一个好的名字。把你的包名字想象成电梯游说（Elevator pitch，即用极具吸引力的方式简明扼要地阐述自己的观点）， 仅用一个词就可以描述包的内容。当名字不再符合要求时，请查找替代名字。

简单性很重要

“Simple is better than complex.” - The Zen of Python, Item 3
“简单胜于复杂。” - Python之禅，条款3

PEP-20说：简单胜于复杂，我完全同意。几年前，我发布了这条推文:

大多数编程语言开始都是为了简单，但最终只是为了功能强大而努力。— Dave Cheney（@davecheney）2014年12月2日

至少在当时，我的观察是，我想不出一生中使用的哪门语言不标榜着简单。每种新语言都为其固有的简单性提供了理由和诱因。但是，当我研究时，我发现简单性并不是与Go语言同时代的许多现代语言的核心价值观。也许这只是一个便宜的镜头¹，但是可能是这些语言不是很简单，或者它们不认为自己很简单。他们不认为简单是其核心价值观。

但是什么时候简单变得过时了？为什么商业软件开发行业会忘记这个基本原则？

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” - C. A. R. Hoare, The Emperor’s Old Clothes, 1980 Turing Award Lecture

“构建软件设计的方式有两种：一种方式是使其变得如此简单，以至于显然没有缺陷，另一种方式是使得它变得如此复杂以至于没有明显的缺陷。第一种方法要困难得多。” - CAR Hoare，皇帝的旧衣，1980年图灵奖演讲

我们知道：简单并不意味着容易。通常，使某些东西易于使用而不是易于构建需要更多的工作。

“Simplicity is prerequisite for reliability.” - Edsger W Dijkstra, EWD498, 18 June 1975
“简单性是可靠性的前提。”-  埃兹格·迪克斯特拉（Essger W Dijkstra），EWD498，1975年6月18日

我们为什么要追求简单？为什么Go程序简单很重要？简单并不意味着粗糙，它意味着可读性和可维护性。简单并不意味着“不复杂”，它意味着可靠，有共鸣且易于理解。

“Controlling complexity is the essence of computer programming.” - Brian W. Kernighan, Software Tools (1976)
“控制复杂性是计算机编程的本质。” - Brian W. Kernighan，软件工具  （1976）

Python是否遵守其简单性的说法尚有争议，但Go坚持将简单性作为核心价值观。我认为我们都可以认同，就Go而言，简单代码比聪明代码更可取。

避免包级别状态

“Explicit is better than implicit.” - The Zen of Python, Item 2
“显式胜于隐式。” - Python的禅宗，第2项

我认为彼得斯在这个地方的抱负胜于实际。Python中的许多内容并不明确；装饰器，dunder方法(译注：不知此为何物)等。毫无疑问，这些特性的功能强大，存在这些特性是有原因的。每个特性都是因某人非常关心的事情，尤其是复杂的特性。但是大量使用这些特性使读者很难预测操作的成本。

好消息是，像Go程序员一样，我们可以选择显式代码。显式可能意味着很多事情，也许您可能认为显式只是一种表达官僚主义和漫长风气的好方法，但这只是肤浅的解释。只关注页面的语法、烦恼行长和自制表达式是一种错误的说法。在我看来，更有价值的地方是与耦合和状态有关。

耦合(coupling)是衡量一件东西依赖另一件东西的数量的方法。如果两件事紧密结合，它们就会一起运动。影响其中一个事物的行为会直接反映在另一个事物中。想象一下，一列火车，每个车厢连在一起；发动机行驶到哪里，车厢就跟随到哪里。

描述耦合的另一种方法是内聚(cohesion)一词。内聚衡量两件事自然地在一起的程度。当我们进行一个内聚的争论，或者一个内聚的团队，它们的所有零件都可以自然装配在一起，就像设计的一样。

为什么耦合很重要？因为就像火车一样，当您需要更改一段代码时，与之紧密相关的所有代码都必须更改。一个再适合不过的例子：有人发布了他们的API的新版本，现在您的代码无法通过编译了。

API是不可避免的耦合源，但是存在更多隐蔽的耦合形式。显然，每个人都知道，如果API的原型发生更改，则该调用的传入和返回数据都会发生变化。就在函数原型中；我采用这些类型的值，并返回其他类型的值。但是，如果API以其他方式传递数据怎么办？如果每次调用此API的结果都是基于上次调用该API的结果，即使您没有更改参数该怎么办？

这是状态，状态管理是计算机科学中的问题。

package counter

var count int

func Increment(n int) int {
        count += n
        return count
}

假设我们有这个简单的counter包。您可以调用Increment以增加计数器，即便传入0，你也可以得到返回值。

假设您必须测试此代码，那么每次测试后如何重置计数器？假设您想并行运行这些测试，可以吗？现在，假设您要为每个程序进行不止一个计数，您可以这样做吗？

不，当然不行。显然，答案是将count变量封装为类型。

package counter

type Counter struct {
        count int
}

func (c *Counter) Increment(n int) int {
        c.count += n
        return c.count
}

现在想象一下，这个问题不局限于计数器，还包括应用程序的主要业务逻辑。您可以单独测试吗？您可以并行测试吗？您一次可以使用多个实例吗？如果回答那些问题为否，则原因是软件的包级别状态。

避免包级别状态。通过提供一种类型需要的依赖项作为该类型上的字段，而不是使用包变量，来减少耦合和怪异的行为。

为失败而计划，而不是成功而计划

“Errors should never pass silently.” - The Zen of Python, Item 10
“错误绝不能默默传递。” - Python之禅，条款10

有人说过，支持异常处理的语言遵循武士原则(Samurai principle)。要么全胜归来，要么(失败)全不回来。在基于异常的语言中，函数仅返回有效结果。如果他们没有成功，那么控制流程将采纳完全不同的路径。

未检查的异常显然是不安全的编程模型。当您不知道哪些语句可能引发异常时，如何在存在错误的情况下编写健壮的代码？Java尝试通过引入checked exception的概念来使异常更安全，据我所知，这种checked exception在另一种主流语言中没有被引入。有很多使用异常的语言，但是除了Java，所有语言都使用未经检查的各种异常(unchecked exception)。

显然，Go选择了不同的路径。Go程序员认为，健壮的程序是由处理失败情况的片段组成的，然后再处理happy path。在Go设计的空间中：服务器程序，多线程程序，处理网络输入的程序，如果要构建可靠的程序，那么处理意外数据、超时、连接失败和损坏的数据必须是程序员的首要任务。

“I think that error handling should be explicit, this should be a core value of the language.” - Peter Bourgon, GoTime #91
“我认为错误处理应该是显式的，这应该是语言的一个核心价值观。” - 彼得·布尔贡（Peter Bourgon），GoTime＃91

我想回应彼得的主张，因为这是本文的动力。我认为Go的成功很大程度上归功于显式的处理错误的方式。Go程序员首先考虑失败情况。我们首先解决如果...怎么办的情况。这导致程序在编写时处理故障，而不是在生产中处理故障。

反复出现的下面代码片段：

if err != nil {
    return err
}

所付出的成本已基本被在故障发生时刻意处理每个故障情况的价值超过了(译者注：上面的重复代码段也是利大于弊)。关键还在于显式处理每个错误的文化价值观。

早点返回，而不是深层嵌套

“Flat is better than nested.” - The Zen of Python, Item 5
“扁平比嵌套更好。” - Python的禅宗，条款5

这是一个明智的建议，而且它来自以缩进作为控制流主要形式的语言。我们如何用Go来解释这个建议呢？gofmt控制Go程序的整体风格(空白与缩进)，因此无需执行任何额外操作。

我之前写过关于package名字的文章，这里可能有一些建议：避免复杂的软件包层次结构。以我的经验，程序员越努力细分和分类Go代码库，他们越有可能陷入包导入循环的死角。

我认为第5项条款建议的最佳应用是函数内的控制流。简而言之，避免需要控制流缩进过深。

“Line of sight is a straight line along which an observer has unobstructed vision.” - May Ryer, "Code: Align the happy path to the left edge" https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88

“代码行展现给观察者的视觉效果应该是一条畅通的直线。- May Ryer， “代码：将快乐路径对齐到左边缘”

Mat Ryer将这种想法描述为视线编码(line of sight coding )。视线编码意味着：

• 如果不满足前提条件，则使用保护子句尽早返回。
• 将成功的return语句放在函数的末尾，而不是放在条件代码块中。
• 通过提取函数和方法来降低函数的整体缩进级别。

该建议的关键是您所关心的事情，功能所要做的事情永远不会有在屏幕右侧滑出视线的危险。这种风格有一个额外的副作用，您可以避免团队中对行长度的毫无意义的争论。

每次缩进时，都会向程序员堆栈添加另一个先决条件，从而消耗他们的7±2个短期内存插槽之一(译注：7±2指的是人类能短期记忆的事件数量大约是7，±2是个体差异)。将函数的成功执行路径贴近屏幕左手侧，不要深入嵌套。

如果你认为它性能差，请通过基准测试证明

“In the face of ambiguity, refuse the temptation to guess.” - The Zen of Python, Item 12
“面对模棱两可，拒绝猜测的诱惑。” - Python之禅，条款12

编程基于数学和逻辑，这两个概念很少涉及机会元素。但是，作为程序员，我们每天都在猜测许多事情。这个变量有什么作用？此参数有什么作用？如果我在这类传入nil会怎样？如果我调用Register两次会怎样？实际上，现代编程中存在很多猜测，尤其是在使用不是你编写的库时。

“APIs should be easy to use and hard to misuse.”  - Josh Bloch
“API应该易于使用并且不容易被滥用。” - 乔什·布洛赫（Josh Bloch）

我知道的帮助程序员避免猜测的最好方法之一是在构建API时，应专注于默认用例。使调用者尽可能轻松地执行最常见的事情。但是，我过去写过很多关于API设计的文章，所以我对第12项的解释是：不要猜测性能。

尽管您可能考虑到Knuth的建议，但Go语言成功的推动力之一是其高性能的执行。您可以在Go中编写高性能的程序，因此人们会因此选择Go。关于性能有很多误解，所以我的要求是，当您希望对代码进行性能调优时，或者遇到一些教条式的建议时，例如defer缓慢，CGO昂贵，或者始终使用原子操作而不是互斥锁时，请不要猜。

不要因为过时的教条而使您的代码复杂化，并且，如果您认为某些事情很慢，请首先使用基准测试进行证明。Go提供了出色的基准测试和性能分析工具，这些工具均可免费获得。使用它们来找出您程序中的性能瓶颈。

在启动goroutine之前，请知道它何时会停止

在这一点上，我认为我已经从PEP-20中挖掘了有价值的要点，并且可能扩展其重新解释的范围。我认为很好，因为尽管这是一种有用的修辞手法，但最终我们还是在谈论两种不同的语言。

“You type go, a space, and then a function call. Three keystrokes, you can’t make it much shorter than that. Three keystrokes and you’ve just started a sub process.” - Rob Pike, Simplicity is Complicated, dotGo 2015

“您键入go，一个空格和一个函数调用。三次按键，您不能做到比这还短了。三次按键，您就启动了一个子过程。” - 罗伯·派克（Rob Pike），Simplicity is Complicated，dotGo，2015年

接下来的两个建议，我将专注于goroutines。Goroutines是语言的标志性功能，这是我们给出的关于一等公民(first class)并发的答案。它们非常易于使用，只需将单词go放在语句前面，即可异步启动该函数。非常简单，没有线程，没有堆栈大小，没有线程池执行程序(thread pool executor)，没有ID，没有跟踪完成状态。

Goroutines代价很低。由于运行时(runtime)能够将goroutine多路复用到一个小的线程池中（您不必管理），因此可以轻松容纳数十万，数百万个goroutine。这开创了在竞争性并发模型（例如线程或事件回调）下不可行的设计。

但是，即便如goroutine一样便宜，但它们也不是免费的。至少它们的堆栈有几千字节，当您启动10^6个goroutine时，它们的确开始累加。这并不是说就不应该使用数百万个goroutine，如果你的设计需要，可以做。但是当您这样做时，请务必对其进行跟踪，因为10^6数量级的任何东西累计可能消耗的资源都不是少量的。

Goroutines是Go中资源所有权的关键。为了程序有用，goroutine必须做一些事情，这意味着它几乎总是持有对资源的引用或所有权：锁、网络连接、带有数据的缓冲区、channel的发送端。当该goroutine处于活动状态时，将持有锁，保持网络连接打开，保留缓冲区，并且channel的接收器将继续等待更多数据。

释放这些资源的最简单方法是将它们与goroutine的生命周期相关联-当goroutine退出时，资源释放。因此，尽管开始执行goroutine几乎是微不足道的，但在进行三次按键(go+空格)前，请确保您对以下问题有答案：

• goroutine在什么情况下会停止？ Go没有办法告诉goroutine退出。没有停止或终止功能，这是有充分的理由的。如果我们无法命令goroutine停止，则必须礼貌地对其提出要求。这几乎总是归结于channel操作。当channel关闭时，针对一个channel的range loop将退出循环。如果一个channel关闭，它将变为可选(selectable)。从一个goroutine到另一个goroutine的信号最好表示为一个关闭的channel。

• 出现这种情况需要什么？ 如果channel既是在goroutines之间进行通讯的工具，又是它们传达完成信号的机制，那么程序员面临的下一个问题就是，谁将关闭channel，何时会发生？

• 您将使用什么信号知道goroutine已停止？ 当您发出信号告知goroutine要停止时，在将来的某个时间gouroutine停止动作会发生。就人类的感知而言，它可能很快发生，但是计算机每秒执行数十亿条指令，并且从每个goroutine的角度来看，它们的指令执行是不同步的。解决方案通常是使用channel发应答信号或fan-in方法需要的waitgroup。

将并发留给调用者

在您编写的任何严肃的Go程序中，都可能涉及并发。这就提出了一个问题，我们编写的许多库和代码都采用每个连接一个goroutine或采用工作者(worker)模式。您将如何管理这些goroutine的生命周期？

net/http是一个很好的例子。关闭拥有监听套接字的server相对来说是直截了当的，但是从该接受套接字产生的goroutines呢？net/http确实在请求对象中提供了一个上下文(context)对象，该上下文对象可用于向正在监听的代码发出信号，表明应该取消请求(cancel)，从而终止goroutine，但是尚不清楚如何知道何时完成所有这些操作。一种方法是调用context.Cancel，知道取消已经完成是另一回事。²

我想说明的一点net/http是，它是良好实践的反例。由于每个连接都是由net/http.Server类型内部产生的goroutine处理的，因此驻留在程序net/http包外部的程序无法控制接受套接字产生的goroutine。

这是一个仍在不断发展的设计领域，例如go-kit的run.Group和Go团队等努力ErrGroup提供了执行，取消和等待异步运行功能的框架。

这里更大的设计准则是针对库编写者的，或者是任何编写可以异步运行的代码的人，将使用goroutine的责任留给调用者。让调用者选择他们希望如何启动，跟踪和等待函数执行。

编写测试以锁定包API的行为

也许您希望从我这里读到一篇我不咆哮测试的文章。可悲的是，今天不是那天。

测试是关于您的软件做什么和不做什么的契约。程序包级别的单元测试应锁定程序包API的行为。他们用代码描述了程序包承诺要做的事情。如果针对每个输入排列组合都有一个单元测试，那么您已经定义了代码将在代码（而不是文档）中执行的约定 。

通过简单的输入go test，您就可以断言代码是否遵守契约。在任何阶段，您都可以高度自信地知道人们在更改之前所依赖的行为在更改之后将继续有效。

测试会锁定api行为。添加，修改或删除公共api的任何更改都必须包括对其测试的更改。

适度是一种美德

Go是一种简单的语言，只有25个关键字。在某些方面，这使该语言内置的功能脱颖而出。同样，这些是语言销售的功能，轻量级并发，结构化类型。

我想我们所有人都经历过尝试立即使用Go的所有功能所带来的困惑。谁对使用channel如此兴奋以至于他们尽可能多地，尽可能多地使用它们？就我个人而言，我发现结果很难测试，脆弱且最终过于复杂。只有我一个人吗？

我在goroutines上经历了相同的经历，试图将工作分解成很小的单元，我创建了一群难以管理的goroutines，最终观察到我的大多数goroutines总是阻塞等待–代码最终是顺序的，我增加了很多复杂性，几乎没有给现实世界带来任何好处。谁经历过这样的事情？

我在嵌入机制方面(embedding)也有同样的经历。最初，我将其误认为是继承。然后，我通过将已经承担多个职责的复杂类型组合成更复杂的巨大类型重现了创建脆弱的基类问题。

这可能是最不可行的建议，但我认为这一点很重要。建议始终是相同的，所有事情都要适度，Go的特性也不例外。如果可以的话，请不要寻求goroutine或channel，也不要嵌入结构，匿名函数，过渡用package，为每样东西建立接口(interface)，要用简单方法而不是聪明的方法。

可维护性很重要

我想谈谈关于PEP-20的最后一项，

“可读性很重要。” - Python之禅，条款7
“Readability Counts.” - The Zen of Python, Item 7

关于可读性的重要性已经被谈论了很多，不仅在Go语言中，而且在所有编程语言中。像我这样的人，倡导在Go的舞台上使用简单，可读性，清晰度，生产力等词，但最终它们都是一个词的同义词- 可维护性。

真正的目标是编写可维护的代码。原始作者之后的代码可以存活下了。存在的代码不仅可以作为时间点投资，而且可以作为未来价值的基础。不是可读性并不重要，而是可维护性更重要。

Go并不是为聪明人而优化的语言。Go不是一种为了在程序中编写最少行数而进行优化的语言。我们没有针对磁盘上源代码的大小进行优化，也没有针对将程序键入编辑器花费的时间进行优化。而是，我们希望优化我们的代码以使读者清晰(clear)。因为需要维护此代码的人正是读者。

如果您是为自己编写程序，则也许只需要运行一次，或者您是唯一会看到该程序的人，然后程序为您工作。但是，如果这是一个将由多个人贡献的软件，或者将由人们使用足够长的时间以致其需求，功能或运行环境可能发生变化，那么您的目标必须是针对程序的可维护性。如果无法维护软件，则它将被重写；那可能是您的公司最后一次投资Go。

你离开后，您努力实现东西可以维护吗？您今天该如何做才能使某人明天更容易维护您的代码？

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2020, bigwhite. 版权所有.

一、序

今天我要分享的题目是“Go coding in go way”，中文含义就是用“Go语言编程思维去写Go代码”。看到这个题目大家不禁要问：究竟什么是Go语言编程思维呢？关于什么是Go语言变成思维其实并没有官方说法。这里要和大家交流的内容都是基于Go诞生七年多以来我个人对Go的设计者、Go team以及Go主流社区的观点和代码行为的整理、分析和总结。希望通过我的这次“抛砖引玉”，让在座的Gopher们对“Go语言编程思维”有一个初步的认知，并在日常开发工作中遵循Go语言的编程思维，写出idiomatic的Go代码。

二、编程语言与编程思维

1、大师的观点

在人类自然语言学界有一个很著名的假说：”萨丕尔-沃夫假说“，这个假说的内容是这样的：

语言影响或决定人类的思维方式("Language inuences/determines thought" - Sapir-Whorf hypothesis )

说到这个假说，我们不能不提及在2017年初国内上映了一部口碑不错的美国科幻大片《降临》，这部片子改编自雨果奖获得者华裔科幻小说家Ted姜的《你一生的故事》，片中主线剧情的理论基础就是就是“萨丕尔-沃夫假说”。更夸张的是片中直接将该假说应用到外星人语言上，将其扩展到宇宙范畴^_^。片中的女主作为人类代表与外星人沟通，并学会了外星语言，从此思维大变，拥有了预知未来的“超能力”。由此我们可以看出“选择对一门语言是多么的重要”。

奇妙的是，在编程语言界，有位大师级人物也有着与”萨丕尔-沃夫假说”异曲同工的观点和认知。他就是首届图灵奖得主、著名计算机科学家Alan J. Perlis(艾伦·佩利)。他从另外一个角度提出了：

“不能影响到你的编程思维方式的编程语言不值得去学习和使用”

A language that doesn't aect the way you think about programming is not worth knowing.

2、现实中的“投影”

从上述大师们的理论和观点，我们似乎看到了语言与思维之间存在着某种联系。那么两者间的这种联系在真实编程世界中的投影又是什么样子的呢？我们来看一个简单的编程问题：

【问题: 素数筛】

  问题描述：素数是一个自然数，它具有两个截然不同的自然数除数：1和它本身。 要找到小于或等于给定整数n的素数。针对这个问题，我们可以采用埃拉托斯特尼素数筛算法。
  算法描述：先用最小的素数2去筛，把2的倍数剔除掉；下一个未筛除的数就是素数(这里是3)。再用这个素数3去筛，筛除掉3的倍数... 这样不断重复下去，直到筛完为止。

算法动图

下面是该素数筛算法的不同编程语言的实现版本。

C语言版本：

【sieve.c】

void sieve() {
        int c, i,j,numbers[LIMIT], primes[PRIMES];

        for (i=0;i<LIMIT;i++){
                numbers[i]=i+2; /*fill the array with natural numbers*/
        }

        for (i=0;i<LIMIT;i++){
                if (numbers[i]!=-1){
                        for (j=2*numbers[i]-2;j<LIMIT;j+=numbers[i])
                                numbers[j]=-1; /*sieve the non-primes*/
                }
        }

        c = j = 0;
        for (i=0;i<LIMIT&&j<PRIMES;i++) {
                if (numbers[i]!=-1) {
                        primes[j++] = numbers[i]; /*transfer the primes to their own array*/
                        c++;
                }
        }

        for (i=0;i<c;i++) printf("%d\n",primes[i]);
}

Haskell版本：

【sieve.hs】

sieve [] = []
sieve (x:xs) = x : sieve (filter (\a -> not $ a `mod` x == 0) xs)

n = 100
main = print $ sieve [2..n]

Go语言版本：

【sieve.go】

func generate(ch chan<- int) {
    for i := 2; ; i++ {
        ch <- i // Send 'i' to channel 'ch'.
    }
}

func filter(src <-chan int, dst chan<- int, prime int) {
    for i := range src { // Loop over values received from 'src'.
        if i%prime != 0 {
            dst <- i // Send 'i' to channel 'dst'.
        }
    }
}

func sieve() {
    ch := make(chan int) // Create a new channel.
    go generate(ch)      // Start generate() as a subprocess.
    for {
        prime := <-ch
        fmt.Print(prime, "\n")
        ch1 := make(chan int)
        go filter(ch, ch1, prime)
        ch = ch1
    }
}

• C版本的素数筛程序是一个常规实现。它定义了两个数组：numbers和primes，“筛”的过程在numbers这个数组中进行(纯内存修改)，非素数的数组元素被设置为-1，便于后续提取；
• Haskell版本采用了函数递归的思路，通过 “filter操作集合”，用谓词(过滤条件）\a -> not $ a mod x == 0；筛除素数的倍数，将未筛除的数的集合作为参数传递归递给下去；
• Go版本的素数筛实现采用的是goroutine的并发组合。程序从2开始，依次为每个素数建立一个goroutine，用于作为筛除该素数的倍数。ch指向当前最新输出素数所位于的筛子goroutine的源channel，这段代码来自于Rob Pike的一次关于concurrency的分享slide。

3、思考

通过上述这个现实中的问题我们可以看到：面对同一个问题，来自不同编程语言的程序员给出了思维方式截然不同的解决方法：C的命令式思维、Haskell的函数式思维和Go的并发思维。这一定程度上印证了前面的假说：编程语言影响编程思维。

Go语言诞生较晚（2007年设计、2009年发布Go1），绝大多数Gopher(包括我在内)第一语言都不是Go，都是“半路出家”从其他语言转过来的，诸如：C、C++、Java、Python等，甚至是Javascript、Haskell、Lisp等。由于Go语言上手容易，在转Go的初期大家很快就掌握了Go的语法。但写着写着，就是发现自己写的代码总是感觉很别扭，并且总是尝试在Go语言中寻找自己上一门语言中熟悉的语法元素；自己的代码风格似乎和Go stdlib、主流Go开源项目的代码在思考角度和使用方式上存在较大差异。而每每看到Go core team member(比如：rob pike)的一些代码却总有一种醍醐灌顶的赶脚。这就是我们经常说的go coding in c way、in java way、in python way等。出现这种情况的主要原因就是大脑中的原有语言的思维方式在“作祟”。

我们学习和使用一门编程语言，目标就是要用这门语言思维方式去Coding。学习Go，就要用Go的编程思维去写Go代码，而不是用其他语言的思维方式。

4、编程语言思维的形成

人类语言如何影响人类思维这个课题自然要留给人类语言学家去破解。但编程语言如何影响编程思维，每个程序员都有着自己的理解。作为一个有着十几年编程经验的程序员，我认为可以用下面这幅示意图来解释一门编程语言思维的形成机制：

决定编程语言思维的根本在于这门编程语言的价值观！什么是价值观？个人认为：一门编程语言的价值观就是这门语言的最初设计者对程序世界的认知。不同编程语言的价值观不尽相同，导致不同编程语言采用不同的语法结构，不同语言的使用者拥有着不同的思维方式，表现出针对特定问题的不同的行为（具现为：代码设计上的差异和代码风格上的不同），就像上面素数筛那样。比如：

C的价值观摘录：

- 相信程序员：提供指针和指针运算，让C程序员天马行空的发挥
- 自己动手，丰衣足食：提供一个很小的标准库，其余的让程序员自造
- 保持语言的短小和简单
- 性能优先

C++价值观摘录：

- 支持多范式，不强迫程序员使用某个特定的范式
- 不求完美，但求实用（并且立即可用）

此外，从上述模型图，我们可以看出思维和结构影响语言应用行为，这是语言应用的核心；同时存在一个反馈机制：即语言应用行为会反过来持续影响/优化语言结构。我们常用冰山表示一个事物的表象与内涵。如果说某种语言的惯用法idiomatic tips或者best practice这些具体行为是露出水面上的冰山头部，那么价值观和思维方式就是深藏在水面以下的冰山的基座。

三、Go语言价值观的形成与Go语言价值观

从上述模型来看，编程语言思维形成的主导因素是这门编程语言的价值观，因此我们首先来看一下Go语言价值观的形成以及Go语言价值观的具体内容。

Go语言的价值观的形成我觉得至少有三点因素。

1、语言设计者&Unix文化

Go语言价值观形成是与Go的初期设计者不无关系的，可以说Go最初设计者主导了Go语言价值观的形成！这就好比一个企业的最初创始人缔造企业价值观和文化一样。

图中是Go的三位最初设计者，从左到右分别是罗伯特·格瑞史莫、罗伯·派克和肯·汤普逊。Go初期的所有features adoption是需要三巨头达成一致才行。三位设计者有一个共同特征，那就是深受Unix文化熏陶。罗伯特·格瑞史莫参与设计了Java的HotSpot虚拟机和Chrome浏览器的JavaScript V8引擎，罗博·派克在大名鼎鼎的bell lab侵淫多年，参与了Plan9操作系统、C编译器以及多种语言编译器的设计和实现，肯·汤普逊更是图灵奖得主、Unix之父。关于Unix设计哲学阐述最好的一本书莫过于埃瑞克.理曼德(Eric S. Raymond)的《UNIX编程艺术》了，该书中列举了很多unix的哲学条目，比如：简单、模块化、正交、组合、pipe、功能短小且聚焦等。三位设计者将Unix设计哲学应用到了Go语言的设计当中，因此你或多或少都能在Go的设计和应用中找到这些哲学的影子。

2、遗传基因

Go并发模型CSP理论的最初提出者Tony Hoare曾提出过这样一个观点：

The task of the programming language designer " is consolidation not innovation ". (Tony Hoare, 1973).
编程语言设计者的任务不是创新，而是巩固。

和其他语言一样，Go也是站在巨人肩膀上的。这种基因继承，不仅仅是语法结构的继承，还有部分价值观的继承和进一步认知改进。当然不可否认的是Go也有自己的微创新，比如： implicit interface implementation、首字母大小写决定visibility等。虽然不受学院派待见，但把Go的这些微创新组合在一起，你会看到Go迸发出了强大的表现力。

3、面向新的基础设施环境和大规模软件开发的诸多问题

有一种开玩笑的说法：Go诞生于C++程序的漫长compile过程中。如果c++编译很快，那么上面的Go语言三巨头也没有闲暇时间一起喝着咖啡并讨论如何设计一门新语言。

面对时代变迁、面对新的基础设施环境、多核多处理器平台的出现，很多传统语言表现出了“不适应”，这直接导致在开发大规模软件过程中出现了各种各样的问题，比如：构建缓慢、依赖失控、代码风格各异、难用且复杂无法自动化的工具、跨语言构建难等。Go的设计初衷就是为了面向新环境、面向解决问题的。虽然这些问题不都是能在语言层面解决的，但这些环境和问题影响了设计者对程序世界的认知，也就影响了Go的价值观。

4、Go语言的价值观

在明确了Go价值观的形成因素后，我认为Go语言的价值观至少包含以下几点：

 - Overall Simplicity 全面的简单
 - Orthogonal Composition 正交组合
 - Preference in Concurrency 偏好并发

用一句话概括Go的价值观（也便于记忆）：

Go is about orthogonal composition of simple concepts with preference in concurrency.
Go是在偏好并发的环境下的简单概念/事物的正交组合

无论是Go语言设计还是Go语言使用，都受到上述价值观的影响。接下来我们逐个来看一下Go语言价值观主导下的Go语言编程思维，并看看每种编程思维在语言设计、标准库实现以及主流Go开源项目中的应用体现。我将按“价值观” -> “(价值观下的)语言设计” -> “编程思维” -> “编程思维体现”的顺序展开。

四、Overall Simplicity

Go的第一个价值观就是”全面简单”。

图灵奖获得者迪杰斯特拉说过：”简单和优雅不受欢迎，那是因为人们要想实现它们需要更努力地工作，更多自律以及领会更多的教育。” 而Go的设计者们恰恰在语言设计初期就将复杂性留给了语言自身的设计和实现阶段，留给了Go core team，而将简单留给了gopher们。因此，Simplicity价值观更多地体现在了Go语言设计层面。 这里简单列举一些：

- 简洁、正规的语法：大大降低Go入门门槛，让来自其他语言的初学者可以轻松使用Go语言；
- 仅仅25个keyword：主流编程语言中最简单的，没有之一；
-  “一种”代码写法、尽可能减少程序员付出;
- 垃圾回收GC: 降低程序员在内存管理方面的心智负担；
- goroutine：提供最简洁的并发支持；
- constants：对传统语言中常量定义和使用方法做进一步简化；
- interface：纯方法集合，纯行为定义，隐式实现；
- package：Go程序结构层面的唯一组织形式，它将设计、语法、命名、构建、链接和测试都聚于一包中，导入和使用简单。

如今，Go语言的简单已经从自身设计扩展到Go应用的方方面面，但也正是由于在语言层面已经足够简单了，因此在应用层面，“简单”体现的反倒不是很明显，更加顺其自然。接下来，我总结整理几个在“全面简单”价值观下形成的Go编程思维，我们一起看一下。

1、short naming thought（短命名思维）

在gofmt的帮助下，Go语言一统coding style。在这样的一个情形下，naming成了gopher们为数不多可以“自由发挥”的空间了。但对于naming，Go有着自己的思维：短命名。即在并不影响readablity的前提下，尽可能的用长度短小的标识符，于是我们经常看到用单个字母命名的变量，这与其他一些语言在命名上的建议有不同，比如Java建议遵循“见名知义”的命名原则。

Go一般在上下文环境中用最短的名字携带足够的信息，我们可以对比一下Java和Go：

   java    vs. go

  "index" vs. "i"
  "value" vs. "v"

除了短小，Go还要求尽量在一定上下文中保持命名含义的一致性，比如：在一个上下文中，我们声明了两个变量b，如果第一个b表意为buf，那么后续的b也最好是这个含义。

在命名短小和一致性方面，stdlib和知名开源项目为我们做出表率。我们统计一下Go标准库中标识符使用频率，可以看到大量单字母命名的变量标识符占据top30：

cat $(find $GOROOT -name '*.go') | indents | sort | uniq -c | sort -nr | sed 30q
          60224 v
          42444 err
          38012 t
          33386 x
          33302 i
          33277 b
          27943 p
          25121 s
          21228 n
          20831 r
          20634 _
          19236 c
          17056 y
          12850 f
          12834 a
          ... ...

细致分析了一下stdlib中常见短变量名字所代表的含义（见代码后的注释），stdlib在一致性方面做的还是不错的，当然也有例外。

        [v, k, i]

        // loop varible
        for i, v := range s {
        for k, v := range m {
        for v := range r { // channel

        // if、switch/case clause varible
        if v := mimeTypes[ext]; v != "" {
        switch v := ptr.Elem(); v.Kind() {
        case v := <-c:

        v := reflect.ValueOf(x) // result of reflect.Value()

        [t]

        t := time.Now() // time
        t := &Timer{ // timer
        if t := md.typemap[off]; t != nil { // type

        [b]

        b := make([]byte, n) // bytes slice
        b := new(bytes.Buffer) // bytes.Buffer

2、minimal thought（最小思维)

码农们是苦逼的，每天坐在电脑前一坐就是10多个小时，自己的“业余”时间已经很少了。Go语言的设计者在这方面做的很“贴心”，考虑到为了让男Gopher能有时间撩妹，女Gopher能有时间傍帅哥，Go语言倡导minimal thought，即尽可能的降低gopher们的投入。这种思维体现在语言设计、语言使用、相关工具使用等多个方面。比如：

• 一种代码风格：程序员们再也无需为coding style的个人喜好而争论不休了，节省下来的时间专心做自己喜欢的事情:)
• “一种”代码写法(或提供最少的写法、更简单的写法)：你会发现，面对一个问题，大多数gopher们给出的go实现方式都类似。这就是Go“一种代码写法”思维的直接体现。Go在语法结构层面没有提供给Gopher很大的灵活性。Go is not a “TMTOWTDI — There’s More Than One Way To Do It”。这点与C++、Ruby有着很大不同。
• 显式代码（obvious），而不是聪明(clever)代码：Go提倡显而易见、可读性好的代码，而非充满各种技巧或称为“炫技”的所谓“聪明”代码。纵观stdlib、kubernetes等go代码库，都是很obvious(直观)的go code，clever code难觅踪迹。这样一来，别人写的代码，你可以轻松地看懂（为你节省大量时间和精力）。这也是Go代码中clever code比例远远小于其他主流语言的原因，Go不是炫技的舞台。

C++程序员看到这里是不是在“抹眼泪”，这里并非黑C++，C++的复杂和多范式是客观的，C++98标准和C++17标准的差异甚至可以用“两门语言”来形容，用泛型的代码和不用泛型的代码看起来也像是两门完全不同的语言，这种心智负担之沉重可想而知。

接下来，我们看看minimal thought在语言设计和应用中的体现。

1) “一种”循环: for

Go语言仅仅提供了一种用于“循环逻辑”的关键字：for。在其他语言中的各种用于循环逻辑的关键字，比如while, do-while等，在go中都可以通过for模拟实现。

- 常规
  for i := 0; i < count; i++ {}

- "while"
  for condition { }

- "do-while"
  for { // use "for-break" instead
        doSomething()
        if condition { break }
  }

- iterator loop
  for k, v := range f.Value {}

- dead loop
  for {}

2) “一种”constant

前面说过Go设计者是十分体贴的，这种体贴体现在很多不起眼的细节上，比如对传统语言中constant声明和使用的优化。

Go语言中constants只是数字，无论是整型还是浮点型都可以直接写成数字，无需显式地赋给类型：

  const incomingQueueLength = 25

  const (
      http2minMaxFrameSize = 1 << 14
      http2maxFrameSize    = 1<<24 - 1
  )

  const PI = 3.1415928
  const e = 1E6

参与计算的constant无需显式算术转换，而是由编译器自动确定语句中constant的承载类型：

  const a = 10080
  var c int32 = 99
  d := c + a
  fmt.Printf("%T\n", d) //int32
  fmt.Printf("%T\n", a) //int

3) “一种”错误处理方法

C++之父Bjarne Stroustrup说过：“世界上有两类编程语言，一类是总被人抱怨诟病的，而另外一类是无人使用的”。Go语言自其出生那天起，就因错误处理机制看起来似乎有些过时、有些简单而被大家所诟病，直至今天这种声音依旧存在。因为Go仅仅提供了一种基于值比较的简单的错误处理方法。但就是这样的错误处理方法也恰恰是Go设计者simplicity价值观的体现。Go设计者认为如果像其他一些主流语言那样，将exception的try-catch-finally的机制与语言的控制结构耦合在一起，将势必大大增加语言的复杂性，这与simplicity的价值观是背道而驰的。简单的基于值比较的error处理方法可以让使用者更重视每一个error并聚焦于错误本身。显式地去处理每一个error，让gopher对代码更有自信。并且在这种机制下，错误值和其他类型的值地位是一样的，错误处理代码也是普通代码，并无特殊之处，无特殊化处理，无需增加语言复杂性。

这些年来，gopher们也初步探索出了这种错误处理方法的常见处理模式，我们以stdlib中识别出的error handling模式为例：

a) 最常见的

在外部无需区分返回的错误值的情况下，可以在内部通过fmt.Errorf或errors.New构造一个临时错误码并返回。这种错误处理方式可以cover 80%以上情形：

    callee:
    return errors.New("something error")

    or

    return fmt.Errorf("something error: %s", "error reason")

  caller:
    if err != nil {... }

b) 导出的Error变量

当外部需要区分返回的错误值的，比如这里我要进行一个io调用，后续的操作逻辑需要因io调用的返回错误码的不同而异，我们使用导出的error变量：

  // io/io.go
  var ErrShortWrite = errors.New("short write")
  var ErrShortBuffer = errors.New("short buffer")

  if err := doSomeIO(); err == io.ErrShortWrite { ... }

c) 定义新的错误类型实现定制化错误上下文

上面的导出Error变量中包含的error context信息和信息形成机制太过简单，当我们要定制error context时， 我们可以定义一个新的Error type。之后通过针对error interface value的type assertion or type switch得到真实错误类型并访问error context：

  // encoding/json/decode.go
  type UnmarshalTypeError struct {
      Value  string       // description of JSON value - "bool", "array", "number -5"
      Type   reflect.Type // type of Go value it could not be assigned to
      Offset int64        // error occurred after reading Offset bytes
      Struct string       // name of the struct type containing the field
      Field  string       // name of the field holding the Go value
  }

  func (e *UnmarshalTypeError) Error() string {
      ... ...
      return "json: cannot unmarshal " + e.Value + " into Go value of type " + e.Type.String()
  }

  if serr, ok := err.(*UnmarshalTypeError); ok {
     //use serr to access context in UnmarshalTypeError
     ... ...
  }

不过这样的用法并不推荐也并不多见，在stdlib、kubernetes中，虽然都有自定义的exported error type，但是却很少在外部通过type assertion直接访问其内部error context字段，那标准库是怎么判断error差别的呢？

**d) 包含package中error公共行为特征的Error interface type

在标准库中，我们可以发现这样一种错误处理方式：将某个包中的Error Type归类，统一提取出一些公共行为特征，并且将这些公共行为特征(behaviour)放入一个公开的interface type中。以stdlib中的net package为例。net package将包内的所有错误类型的公共特征抽象放入”Error”这个error type中。外部使用时，通过这个公共interface获取具体错误的特征：

//net/net.go
  type Error interface {
      error
      Timeout() bool   // Is the error a timeout?
      Temporary() bool // Is the error temporary?
  }

net/http/server.go中的使用举例：

  rw, e := l.Accept()
  if e != nil {
      if ne, ok := e.(net.Error); ok && ne.Temporary() {
         ... ..
      }
      ... ...
  }

OpError是net packge中的一个自定义error type , 它实现了Temporary interface, 可以被外部统一用Error的method判断是否是Temporary或timeout error特征：

  //net/net.go
  type OpError struct {
      ... ...
      // Err is the error that occurred during the operation.
      Err error
  }

  type temporary interface {
      Temporary() bool
  }

  func (e *OpError) Temporary() bool {
    if ne, ok := e.Err.(*os.SyscallError); ok {
        t, ok := ne.Err.(temporary)
        return ok && t.Temporary()
    }
    t, ok := e.Err.(temporary)
    return ok && t.Temporary()
  }

**e) 通过一些公开的error behaviour function对error behaviour进行判断

我们在标准库中还能看到一种判断error behavior的方法，那就是通过一些公开的error behaviour function。比如：os包暴露的IsExist等函数：

  //os/error.go

  func IsExist(err error) bool {
      return isExist(err)
  }
  func IsNotExist(err error) bool { ... }
  func IsPermission(err error) bool { ... }

  例子：

    f, err := ioutil.TempFile("", "_Go_ErrIsExist")
    f2, err := os.OpenFile(f.Name(), os.O_RDWR|os.O_CREATE|os.O_EXCL, 0600)
    if os.IsExist(err) {
        fmt.Println("file exist")
        return
    }

顺便在这里提一下Go关于error type和variable的命名方式：

 错误类型: xxxError

  //net/net.go
  type OpError struct { ... }
  type ParseError struct { ... }
  type timeoutError struct{}

导出的错误变量: ErrXxx

  //io/io.go
  var ErrShortWrite = errors.New("short write")
  var ErrNoProgress = errors.New("multiple Read calls return no data or error")

很多人抱怨，当前Go提供的error handling方案让gopher可以很容易地写出如下面所示的不优雅代码：

  var err error
  err = doSomethingA()
  if err != nil {
      return err
  }

  err = doSomethingB()
  if err = nil {
      return err
  }

  err = doSomethingC()
  if err = nil {
      return err
  }
  ... ...

代码中大量重复着if err!= nil { return err} 这段snippet。但是如果你全面浏览过Go标准库中的代码，你会发现像上面这样的代码并不多见。Rob Pike曾经在《errors are values》一文中针对这个问题做过解释，并给了stdlib中的一些消除重复的方法：那就是将error作为一个内部状态：

  //bufio/bufio.go
  type Writer struct {
      err error
      buf []byte
      n   int
      wr  io.Writer
  }
  func (b *Writer) Write(p []byte) (nn int, err error) {
      if b.err != nil {
          return nn, b.err
      }
      ... ...
  }

  //writer_demo.go
  buf := bufio.NewWriter(fd)
  buf.WriteString("hello, ")
  buf.WriteString("gopherchina ")
  buf.WriteString("2017")
  if err := buf.Flush() ; err != nil {
      return err
  }

error handling的具体策略要根据实际情况而定。stdlib面向的”业务域”相对”狭窄”，像bufio.Write可以采用上面的方法解决，但是对于做业务应用的gopher来讲，业务复杂多变，错误处理没有绝对的模式，需根据上下文不同而具体设计。但如果一个函数中上述snippet过多，很可能是这个函数或方法的职责过多导致，重构是唯一出路。

五、Orthogonal Composition

正交组合是我总结出来的第二个Go语言的价值观。如果说上一个价值观聚焦的是Go程序提供的各种小概念实体或者说”零件”的话，那么Composition就是在考虑如何将这些”零件”联系到一起，搭建程序的静态骨架。

在Go语言设计层面，Go设计者为gopher提供了正交的语法元素，供后续组合使用，包括：

• Go语言无类型体系(type hierarchy)，类型定义正交独立；
• 方法和类型的正交性: 每种类型都可以拥有自己的method set；
• interface与其实现之间无”显式关联”；

正交性为”组合”策略的实施奠定了基础，提供了前提。Rob Pike曾说过： “If C++ and Java are about type hierarchies and the taxonomy(分类）of types, Go is about composition.”。组合是搭建Go程序静态结构的主要方式。“组合”的价值观贯穿整个语言设计和语言应用：

• 类型间的耦合方式直接影响到程序的结构；
• Go语言通过“组合”构架程序静态结构；
• 垂直组合(类型组合)：Go通过 type embedding机制提供；
• 水平组合：Go通过interface语法进行“连接”。

interface是水平组合的关键，好比程序肌体上的“关节”，给予连接“关节”的两个部分各自“自由活动”的能力，而整体上又实现了某种功能。

1、vertical composition thought(垂直组合思维)

传统OO语言都是通过继承的方式建构出自己的类型体系的，但Go语言中并没有类型体系的概念。Go语言通过类型的垂直组合而不是继承让单一类型承载更多的功能。由于不是继承，那么也就没有了所谓“父子类型”的概念，也没有向上、向下转型(type casting)；被嵌入的类型也不知道将其嵌入的外部类型的存在。调用Method时，method的匹配取决于方法名字，而不是类型。

Go语言通过type embedding实现垂直组合。组合方式莫过于以下这么几种：

a) construct interface by embedding interface

  type ReadWriter interface {
      Reader
      Writer
  }

通过在interface中嵌入interface type name，实现接口行为聚合，组成大接口。这种方式在stdlib中尤为常用。

b) construct struct by embedding interface

  type MyReader struct {
      io.Reader // underlying reader
      N int64   // max bytes remaining
  }

c) construct struct by embedding struct

  // sync/pool.go
  type poolLocal struct {
      private interface{}   // Can be used only by the respective P.
      shared  []interface{} // Can be used by any P.
      Mutex                 // Protects shared.
      pad     [128]byte     // Prevents false sharing.
  }

在struct中嵌入interface type name和在struct嵌入struct，都是“委派模式(delegate)”的一种应用。在struct中嵌入interface方便快速构建满足某一个interface的dummy struct，方便快速进行unit testing，仅需实现少数需要的接口方法即可，尤其是针对Big interface时。

struct中嵌入struct，被嵌入的struct的method会被提升到外面的类型中，比如上述的poolLocal struct，对于外部来说它拥有了Lock和Unlock方法，但是实际调用时，method调用实际被传给poolLocal中的Mutex实例。

2、small interface thought(小接口思维)

interface是Go语言真正的魔法。前面提到过，interface好比程序肌体的骨架关节，上下连接着骨架部件。interface决定了Go语言中类型的水平组合方式。interface与其实现者之间的关系是隐式的，无需显式的”implements”声明(但编译器会做静态检查)；interface仅仅是method集合，而method和普通function一样声明，无需在特定位置。

在Go语言中，你会发现小接口（方法数量在1~3）定义占据主流。

  // builtin/builtin.go
  type error interface {
      Error() string
  }

  // io/io.go
  type Reader interface {
      Read(p []byte) (n int, err error)
  }

  // net/http/server.go
  type Handler interface {
      ServeHTTP(ResponseWriter, *Request)
  }

  type ResponseWriter interface {
      Header() Header
      Write([]byte) (int, error)
      WriteHeader(int)
  }

我统计了一下stdlib、k8s和docker里面的interface定义，画出了下面这幅接口个数与接口中method个数关系的折线图：

小接口方法少，职责单一；易于实现和测试，通用性强(如:io.Reader和Writer)，易于组合(如:io.Reader)。不过要想在业务领域定义出合适的小接口，还是需要对问题域有着透彻的理解的。往往无法定义出小接口，都是由于对领域的理解还不到位，没法抽象到很高的程度所致。

3、horizontal composition thought(水平组合思维)

有了小接口，后续主要关注如何通过接口进行“连接”的方式实现水平组合，以解决大问题、复杂的问题。通过interface进行组合的一种常见方法就是：通过接受interface类型参数的普通function进行组合。

以下几种具体形式：

a) 基本形式

接受interface value作为参数是水平组合的基本形式：

形式：someFunc(interface value parameter)

隐式的interface实现会不经意间满足：依赖抽象、里氏替换原则、接口隔离等原则，这在其他语言中是需要很”刻意”的设计谋划的，但在Go interface来看，一切却是自然而然的。

  func ReadAll(r io.Reader) ([]byte, error)
  func Copy(dst Writer, src Reader) (written int64, err error)

b) wrapper function

形式：接受interface类型参数，并返回与其参数类型相同的返回值

  // Wrapper function:
  func LimitReader(r Reader, n int64) Reader { return &LimitedReader{r, n} }

  type LimitedReader struct {
      R Reader // underlying reader
      N int64  // max bytes remaining
  }
  func (l *LimitedReader) Read(p []byte) (n int, err error) {}

  // Usage:
  r := strings.NewReader("some io.Reader stream to be read\n")
  lr := io.LimitReader(r, 4)
  if _, err := io.Copy(os.Stdout, lr); err != nil {
      log.Fatal(err)
  }
  // Output: some

LimitReader是一个wrapper function，它在r的外面再包裹上LimitedReader。通过wrapper function将NewReader和LimitedReader 的两者巧妙的组合在了一起。这样当我们采用包装后的reader去Read时，返回的是受到Limitedreader限制的内容了：即只读取了前面的4个字节：”some”。

c) wrapper function chain

由于wrapper function返回值类型与parameter类型相同，因此wrapper function可以组合一个chain，形式如下：

形式：wrapperFunc(wrapperFunc(wrapperFunc(...)))

我们定义一个wrapper function：CapReader，用于将从reader读取的数据变为大写：

  func CapReader(r io.Reader) io.Reader {
      return &capitalizedReader{r: r}
  }

  type capitalizedReader struct {
      r io.Reader
  }

  func (r *capitalizedReader) Read(p []byte) (int, error) {
      n, err := r.r.Read(p)
      if err != nil {
          return 0, err
      }

      q := bytes.ToUpper(p)
      for i, v := range q {
          p[i] = v
      }
      return n, err
  }

将多个wrapper function串在一起：

  s := strings.NewReader("some io.Reader stream to be read\n")
  r := io.TeeReader(CapReader(io.LimitReader(s, 4)), os.Stdout)
  b, _ := ioutil.ReadAll(r) //SOME
  fmt.Println(len(b))       //4

可以看到例子中，我们将TeeReader、CapReader、LimitedReader、strings Reader等组合到了一起，实现了读取前四个字节，将读取数据转换为大写并输出到标准输出的功能。

**d) adapter function type **

adapter function type是一个辅助水平组合实现的“工具”。adapter function type将一个普通function转换为自己的类型，同时辅助快速实现了某个“one-method” interface。 adapter function type的行为模式有些像电影中的“僵尸” – 咬别人一口就可以将别人转化为自己的同类。最著名的僵尸类型莫过于http.HandlerFunc了：

  type Handler interface {
      ServeHTTP(ResponseWriter, *Request)
  }

  type HandlerFunc func(ResponseWriter, *Request)

  func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
      f(w, r)
  }

  // Usage: use HandlerFunc adapts index function to an implemenation type of Handler interface.
  func index(w http.ResponseWriter, r *http.Request) {
      fmt.Fprintf(w, "Welcome!")
  }

  http.ListenAndServe(":8080", http.HandlerFunc(index))

可以看到通过HandlerFunc，我们可以将普通function index快速转化为满足Handler interface的type。一旦转化ok，便可以通过interface进行组合了。

**e) middleware composition **

middleware这个词的含义可大可小，在Go Web编程中，常常指的是一个满足Handler interface的HandlerFunc类型实例。实质上：

middleware =  wrapper function + adapter function type

我们可以看一个例子：

  func logHandler(h http.Handler) http.Handler {
      return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
          t := time.Now()
          log.Printf("[%s] %q %v\n", r.Method, r.URL.String(), t)
          h.ServeHTTP(w, r)
      })
  }

  func authHandler(h http.Handler) http.Handler {
      return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
          err := validateAuth(r.URL.Query().Get("auth"))
          if err != nil {
              http.Error(w, "bad auth param", http.StatusUnauthorized)
              return
          }
          h.ServeHTTP(w, r)
      })
  }

  func main() {
      http.ListenAndServe(":8080", logHandler(authHandler(http.HandlerFunc(index))))
  }

wrapper function（如：logHandler、authHandler）内部利用 adapter function type转化了一个普通function，并返回实现了Handler interface的HandlerFunc类型实例。

六、Preference in Concurrency

Go语言的第三个价值观是偏好并发。如果说interface和组合决定了程序的静态结构组成的话，那么concurrency则影响着程序在执行阶段的动态运行结构。从某种意义上说，Go语言就是关于concurrency和interface的设计!

并发不是并行(paralell)，并发是关于程序结构的，而不是关于性能的。并发让并行更easy，并且通常性能更好;对于程序结构来说，concurrency是一个比interface组合更大的概念。并发是一种在程序执行层面上的组合：goroutines各自执行特定的工作，通过channels+select将goroutines连接起来。原生对并发的支持，让Go语言更适应现代计算环境。并发的存在鼓励程序员在程序设计时进行独立计算的分解。

在语言层面，Go提供了三种并发原语：

• goroutines提供并发执行, 它是Go runtime调度的基本单元；goroutine实现了异步编程模型的高效，但却允许你使用同步范式编写代码，降低心智负担；goroutines被动态地多路复用到系统核心线程上以保证所有goroutines的正常运行。

• channels用于goroutines之间的通信和同步；channel是goroutines间建立联系的主要途径或者说goroutine通过channel耦合/组合在一起，这一点channel的功用有点像Unix pipe。

• select可以让goroutine同时协调处理多个channel操作。

1、concurrency thought(并发思维)

我将“偏好并发”价值观下的思维统称为“并发思维”。并发思维的核心依旧是组合！

采用并发思维进行程序动态结构设计，需要识别和分解出独立的计算单元放入Goroutines执行，并使用channel/select建立Goroutines之间的联系。计算单元的拆解是并发程序设计的重点，拆解没有统一规则，因业务域不同而异，例如：素数筛实现为每个素数建立一个goroutine以筛除素数的倍数。

不过我们可以从建立Goroutines间的“联系”的角度来看一些常见的goroutines间的“关系”模式。我们可以从“退出机制”和“通信联系”两大方面出发考虑。

a) “detached” goroutine

所谓分离的goroutine，即不需要关心它的退出，相当于与父goroutine间“无关系”。这类goroutines启动后与其创建者彻底分离(detached)，生命周期与程序生命周期相同。通常，这类goroutine在后台执行一些特定任务，如：monitor、watcher等。其实现通常采用for-select代码段形式；以timer或event驱动。

Go应用中内置的GC goroutine就是这种类型的：

// runtime/mgc.go
  go gcBgMarkWorker(p) // each P has a background GC G.

  func gcBgMarkWorker(_p_ *p) {
      gp := getg()

      for {
        ... ...
      }
  }

b） “parent-child” goroutine

这类goroutine与detached goroutine正相反，parent需要通知并等待child退出。如果仅通知并等待一个child，我们可以这样做：

parent:

  quit := make(chan string)
  go child(quit)

child:

  select {
    case c := <-workCh:
    // do something
    case <-quit:
    // do some cleanup
    quit<-"done"
  }

parent:

  quit<-"quit"
  <-quit

当需要同时通知多个child goroutine quit时，我们可以通过channel close来实现：

parent:

  quit := make(chan struct{})
  for ... {
    go child(quit) // several child goroutines
  }

child:

  select {
    case c := <-workCh: // do something
    case <-quit: // do some cleanup
    return
  }

parent:

  close(quit)
  time.Sleep(time.Second * 30)

如果parent要获得child的退出状态值，可以自定义quit channel中的元素类型：

  type ExitStatus interface {
      Status() int
  }

  type IntStatus int // an adapter
  func (n IntStatus)Status() int {
    return int(n)
  }

  quit := make(chan ExitStatus) // for each child goroutine

child:

  quit <- IntStatus(2017)

parent:

  s := <-quit
  fmt.Println(s.Status()) //2017

c) service handle

一些goroutine在程序内部提供特定service，这些goroutine使用channel作为service handle，其他goroutine通过service handle与其通信。

比如：我们经常使用的time.After返回一个service handle：

  //time/sleep.go
  func After(d Duration) <-chan Time {
      return NewTimer(d).C
  }

对应的service goroutine就是runtime中的timer service goroutine：

  // runtime/time.go
  func timerproc() {
    timers.gp = getg()
    for {
      ... ...
    }
  }

编写此类service goroutine时，需要考虑对于“慢消费者”service goroutine应该如何处置：阻塞还是丢弃。timer service goroutine使用的是buffered channel(size=1)，并在向channel发送消息时通过select做了一个判断。如果channel buffer满了，则丢弃这次timer事件。

如果我们要同时处理来自不同service goroutine的handle，那么可以使用service handles aggregation，见下面例子：

比如：我们从wechat、weibo、短信渠道获取msg：

  type msg struct {
      content string
      source  string
  }

  func wechatReceiver() <-chan *msg {
      c := make(chan *msg)
      go func() {
          c <- &msg{"wechat1", sourceWechat}
          c <- &msg{"wechat2", sourceWechat}
          c <- &msg{"wechat3", sourceWechat}
      }()

      return c
  }

  func weiboReceiver() <-chan *msg {...}
  func textmessiageReceiver() <-chan *msg {...}

我们需要把这些handle聚合起来统一处理，我们通过一个aggregation function来做。对于不固定数量handles的聚合，用goroutine来聚合(非常类似于unix pipe chain)：

  func serviceAggregation(ins ...<-chan *msg) <-chan *msg {
      out := make(chan *msg)
      for _, c := range ins {
          go func(c <-chan *msg) {
              for v := range c {
                  out <- v
              }
          }(c)
      }
      return out
  }

  c := serviceAggregation(weiboReceiver(), wechatReceiver(), textmessageReceiver())
  m := <-c // 获取message并处理

对于固定数量handles聚合，用select就可以实现：

  func serviceAggregation(weibo, wechat, textmessage <-chan *msg) <-chan *msg {
      out := make(chan *msg)

      go func(out chan<- *msg) {
          for {
              select {
              case m := <-weibo:
                  out <- m
              case m := <-wechat:
                  out <- m
              case m := <-textmessage:
                  out <- m
              }
          }
      }(out)
      return out
  }
  c := serviceAggregation(weiboReceiver(), wechatReceiver(), textmessageReceiver())
  m := <-c // 获取message并处理

d) dispatch-and-mix goroutines

在“微服务”时代，我们在处理一个请求时经常调用多个外部微服务并综合处理返回结果：

  func handleRequestClassic() {
    r1 := invokeService1()
    //handle result1
    r2 := invokeService2()
    //handle result2
    r3 := invokeService3()
    //handle result3
  }

上述例子中的问题是显而易见的：顺序调用、慢、一旦某个service出现异常，返回时间不可预知，可能会导致调用阻塞。

一个优化的方法就是讲将处理请求时对外部的服务调用分发到goroutine中，再汇总返回结果。并且通过设置一个总体超时时间，让调用返回的时间可预知。：

  func handleRequestByDAM() {
    c1, c2, c3 := make(chan Result1), make(chan Result2), make(chan Result3)
    go func() { c1 <- invokeService1() } ()
    go func() { c2 <- invokeService2() } ()
    go func() { c3 <- invokeService3() } ()
    timeout := time.After(200 * time.Millisecond)
    for i := 0; i < 3; i++ {
        select {
        case r := <-c1: //handle result1
            c1 = nil
        case r := <-c2: //handle result2
            c2 = nil
        case r := <-c3: //handle result3
            c3 = nil
        case <-timeout:
            fmt.Println("timed out")
            return
        }
    }
    return
  }

不过这次优化后的程序依旧存在一个问题，那就是一旦timeout，调用返回，但一些在途的请求资源可能没有回收，request无法显式撤回，久而久之，可能导致资源的泄露。于是我们做进一步改进：通过Context显式cancel掉已经向外发起的在途请求，释放占用资源:

  type service func() result
  func invokeService(ctx context.Context, s service) chan result {
    c := make(chan result)
    go func() {
      c1 := make(chan result)
      go func() {
        c1 <-s()
      }
      select {
        case v := <-c1:
             c <-v
        case <-ctx.Done():
        // cancel this in-flight request by closing its connection.
      }
    }()
    return c
  }

  func handleRequestByDAM() {
    ctx, cf := context.WithCancel(context.Background())
    c1, c2, c3 := invokeService(ctx, service1), invokeService(ctx, service2),
                   invokeService(ctx, service3)
    timeout := time.After(200 * time.Millisecond)
    for i := 0; i < 3; i++ {
        select {
        case r := <-c1: //handle result1
        case r := <-c2: //handle result2
        case r := <-c3: //handle result3
        case <-timeout:
            cf() // cancel all service invoke requests
            return
        }
    }
    return
  }

优化后的程序的优点：并发、快、返回结果可预知。

七、总结

通过这篇文章，我总结了主导Go语言编程思维的三个价值观：

• Overall Simplicity
• Orthogonal Composition
• Preference in Concurrency

阐述了每种价值观主导下的编程思维，并给出了每种编程思维在语言设计、语言应用方面的一些模式和实际例子。

Go最初的设计初衷还有一点，那就是将编程时的fun重新带给Gopher们。但个人觉得只有当你使用Go编程思维去写Go code时，你才能体会到Go设计者的用意，才能让你没有别扭的赶脚，发现自己走在正确的way上，才能真正感到go coding时的fun。

另外，虽然总结出的三个价值观数量不多，但如果能在实际运用中认真践行，却能迸发巨大能量。它会让你应对各种复杂情况、代码设计变得游刃有余、顺利解决各种业务问题。

最后再说说Go 2.0。回到前面的 “编程语言思维的形成”模型，行为总是对结构有反馈的，这将导致结构的持续改变和优化。Go team将于今年8月份发布Go1.9版本，这是一个关键的时间节点。恰好今年的denver的Gophercon大会上，Russ Cox将做”the future of go”的演讲，后续是继续1.10还是Go 2.0，让我们拭目以待！不过个人觉得，无论对语言结构改动的需求有多大，Go的价值观都是不会发生改变的。

本文的slide文件可以在这里下载。

微博：@tonybai_cn
微信公众号：iamtonybai
github.com: https://github.com/bigwhite

© 2017, bigwhite. 版权所有.

一、印象

这是我连续第二年参加AstaXie组织举办的GopherChina大会。而且不同于去年的是，这次我是以讲师身份参与的。虽然大会地点不同，我的角色不同，但不变的是和广大Gophers一样的对Go语言的极大热情。

这也是第三届GopherChina大会。随着Go语言自身的快速演进以及Go在国内各个行业应用的快速增长，GopherChina大会在大中华区的影响力与日俱增：既得到了更多圈内赞助商的赞助，也得到了Gophers们的极大关注。有好多Gophers都是GopherChina大会的连续参加者，有些Gopher甚至连续参加了三届，我个人就看到了好多去年在北京大会上遇到的Gophers。这让能容纳近1500名观众的主会场又近乎爆满。举办和参加这样级别的技术大会，无论是对于主办方还是观众都是一种考验。索性的是，在谢大和相关工作人员的不懈努力之下，两天的大会举办的是很是成功，大会紧凑而有序。并且在第一天晚上举办的技术Party上，大胡子Dave Cheney还为我们带来了“Gopher puzzlers”。这让技术party的气氛一下达到了高潮。

二、选题考量

由于本次是以讲师身份参加的大会，因此这里就不打算像去年那样对其他讲师以及其presentation进行点评了（若要看点评，可以移步到知乎上小伙伴开的贴子）。这里我主要来说说我这次参会的选题以及个人对于类似GopherChina这样的技术大会应该讲些什么的理解。

年初，谢大在征集GopherChina的topic的时候问我是否愿意在今年的GopherChina大会上做分享？说实话我非常想去分享，自己也是一个爱分享之人。但是分享什么topic的确是一个问题。自己研究Go较早，但一直没有全职Go，直到去年才开始成为full-time Go。而自己对GopherChina这类技术大会分享的主题也是有自己的想法的，那就是希望大会能像美国丹佛举办的gophercon大会一样，多一些关于Go语言本身的Topic。于是我就有了自己来分享一个关于Go语言自身的topic的想法，和谢大做了沟通后得到了谢大的支持。下面的topic初步描述反映了我当时关于slide的思路规划：

*“2016年Go语言问鼎TIOBE编程语言排行榜的年度语言，证明了Go语言在全世界范围内的蓬勃发展之势，将来会有越来越多的开发人员加入到Gophers行列。Go以语法简单、门槛低、上手快著称。但入门后很多人发现要写出地道的、遵循Go思维的代码却是不易。为此，在本次分享中，作者将结合Go team的talk资料、参考和提炼Go标准库以及主流Go开源项目的精华源码风格和惯用法，和大家一起探讨《go coding in go way》之道。” *

关于这样的一个主题，我的心理也是忐忑的，内心中有种赶脚：这个topic有些大啊！在阅读代码、收集和整理资料方面的工作肯定也不少，于是我早早开始了一些资料收集工作。

最初我的topic是偏向于go idiomatic tricks或best practice这个方向的，但随着准备工作的进行，我的头脑中出现了几个疑问：Go诞生这么多年，go idiomatic tricks或best practice已经为人知晓，但很多问题并无定论，我是否可以探讨一下呢？比如：Go的编程思维到底是如何形成的？为什么Go上手易，写出idiomatic的code难呢？我是否能再上一个层次，将go idiomatic tricks或best practice这些冰山上面的具现事物的底层根源找出来呢？这时恰逢国内上映《降临》这部美国大片，在电影院看完片后，我思考着影片中的理论核心：“萨丕尔-沃夫假说”并陷入沉思。

于是乎那天晚上我就有了一个关于topic的新的想法，那就是探究Go编程思维背后的东西。但考虑到如何应用编程思维去写go代码，我又阅读了大量go stdlib、kubernetes的代码，试图在这些代码中找到”Go语言编程思维”的应用实例并补充的slide中。这样slide的大体结构就出来了：

铺垫
    - “萨丕尔-沃夫假说” 作为引子，说明语言与思维的联系
    - 针对一个问题的三个语言版本实现，说明编程语言对编程思维的影响
    - 提出：语言价值观是语言影响思维的根本(一个示意图阐述模型)

价值观
    - Go语言的价值观的形成和价值观内容
    - 每种价值观下的语言设计
    - 每种价值观主导下的Go编程思维
    - 这写Go编程思维的具体运用实例

而随着资料准备的深入，逐渐完成了价值观（“全面简单”、“正交组合”和“偏好并发”）与编程思维的内容体系构架（大纲）：

   Overall Simplicity
        - short naming thought
        - minimal thought

   Orthogonal Composition
        - vertical composition thought
        - small interface thought
        - horizontal composition thought

    Preference in Concurrency
        - concurrency thought

其实在这个资料准备过程，我个人对于Go语言的理解也得到了一定的升华，也更加理解Go的设计者在当初设计语言时做出的一些选择了，并且感觉在面对实际业务问题时、在代码设计时，更加有道可循了。

临近大会，开始写slide。本着present in go way的思路^_^，我首选go present tool支持.slide格式文档，最后形成了近70 pages的文档。我也感觉页数有些多，并且每次自己彩排一遍都超时。但页面之间逻辑紧扣，武断地删除一页又担心思维跳跃，不便于整体理解，于是硬着头皮将所有内容都保留到了最后。

三、Presentation分析

不过实际presenting过程，我依然超时了:(了，整个presentation过程并不顺利。

• 首先是大会的屏幕分辨率似乎有些问题，slide的标题部分根本没有显示出来，这直接导致在座的gopher们看不清我的思路体系，内容让人感觉突兀。就像知乎上ezbuy 翁总的“批评”：“不知为何说变量统计”。
• 其次，不得不承认自己在千人面前speaking，的确紧张紧张紧张啊，尤其是初期，节奏变慢，有些东西没有讲出来，可能会让在座观众感觉思路有跳跃；
• 再次，也许gopher们更关心编程思维下的具体展现，也就是后面的代码部分，但由于前面节奏控制不好，铺垫部分有些多了，占用了大量时间，而导致后面代码部分讲解非常快。
• 再再次，每个会场的gopher的关注点不同，一些gopher可能更喜欢像“微服务实战”这样的一些关于他们目前所遇到问题的解决方案的topic。
• 最后，话题大，不够聚焦。自己准备这类规模大会topic时的经验还是不足。即便讲语言本身，也应该聚焦，就像Dave Cheney或Francesc Campoy的topic那样，只把一个事情的来龙去脉讲透。

纵观前两届gopherchina大会，国人讲关于Go语言自身层面topic的比例较低，甚至可以用凤毛麟角来形容。更多topic集中在某一业务领域的产品、架构、原理和工程上的实践等。我并不是说这些topic不好，毕竟像GopherChina这样规模的大会需要topic的多样性。只是这一届我要挑战一下自己，虽然结果不是那么理想。

不过，即便被吐槽，其实也没什么，说明和优秀的Go讲师相比，自己的确是有差距的。有差距就努力去弥补呗。如果下一届还有机会分享，我还会分享与Go语言相关的topic，只是要吸取经验，更加聚焦。

四、回复吐槽

在这里也回复一下几个gopher的吐槽：

1、”过度吹捧Go”

我真想不出为何这位Gopher能有这种想法。

首先在Gopher大会上，说Go肯定是没问题的。我从来都说Go是一门牛逼的语言，但从来没说Go是最好的语言。
至于所谓的上升到“价值观”的层面，那是对一门编程语言本质上的探讨，是对Go代码设计思维本源的思考，无关吹捧或不吹捧。
任何一门编程语言都有设计者自己背后的理解和选择，都可以上升到价值观。

不过我不能否认的是上升到编程语言价值观这个层次，是需要一定编程语言积累的。所以初学者体会不到也是正常的。慢慢来:)

2、“一些模凝两可的结论”

我不知道这个“吐槽”的原因是否是因为我在talk开始时说了几句谦虚的话。但谦虚并不代表模棱两可。slide中的所有结论都是我思考后的结果，这种东西本身就是主观的，这又不是数学，需要有精密的证明过程。但我在表达这些观点时一直都是坚定的。不知道在这位gopher心中，萨丕尔-沃夫假说是否也算是模棱两可的结论呢？

我的确希望这个topic能作为一次“抛砖引玉”，让广大gopher一起深层次理解语言设计者的初衷以及go设计过程中的一些考虑和认知，能让我们更好的使用Go语言。你可以补充，可以针对某个观点反驳，但你要拿出你的思考过程。如果能说服我，说服大家，那我就认同。这次的分享就是我的思考过程，绝不是模棱两可。

小结

最后，十分感谢AstaXie，没有他就没有GopherChina！希望今后的GopherChina大会越办越好，希望Go基金会越做越大！

gopherchina 2017所有讲师的slide已经放出，可以在这里下载。

我个人的talk slide在这里可以下载。

GopherChina会场周围的美丽景色

与GopherChina mascot合影

演讲中

微博：@tonybai_cn
微信公众号：iamtonybai
github.com: https://github.com/bigwhite

© 2017, bigwhite. 版权所有.

如果你问我为何可以长期持续地将博客写下去，我会告诉你：这与我的博客观息息相关。

人有三观：人生观、价值观和世界观。这三观是在你的成长过程中潜移默化地形成的，即便你自己无法表达出来，甚至没有意识到其存在，但这三观却真真切切地在 影响着你人生道路上的每个选择。这三观是用来决定一个人前进的大方向的，但在一些细微的事物上，人也是有“观”的，比如读书之人有读书观，写博客的人有自己的博客观。

观，意为对事物的看法和认知。博客观就是一个人对博客的看法和认知，比如博客对自己有何种意义？是否该写博客？如何写博客？该写什么样的博客以及自己对博 客的定位等等。个人观点：博客观将直接影响博者的博客风格以及写博行为；反之，一个博者的博客观可以从其博客风格与写博行为反映出来。

以我的博客为例。“一个程序员的心路历程”，这一副标题最初是从dreamhead的博客“仿效”过来的，但这个副标题却长期影响了我后续的博客内容和风 格。程序员，我的职业，这一职业脱离不开技术话题，因此这八年来我的博客肯定是以技术方面的内容为主；心路历程，多指成长经历以及在这个过程中的思考和感 悟。显然成长过程中不光光只有技术和工作，生活、家庭方方面面都会有涉及。虽然当初无心确定了这个副标题，但现在看来，它与我的博客目标却是无比弥合 – 编写一部持续且完整的人生履历，这就是我的博客观，也是我对我的博客的定位，这决定了我不会放弃，写博到底。

在这样的博客观的指引下，我把每一篇博客文章都视为一种成长；将每一条来自评论中感谢都视为一种激励：能够给大家带来帮助，让我的心灵得到满足；将每一条来自评论中的建议、批评或纠错都视为一种教诲，这种强大的驱动力让我欲罢不能。

也许写博初期有虚荣心在作祟，但现在我却是在谱写我的人生履历。我不追求这份履历有多美完美，也不求笔风有多么的华丽，但求源自内心的真实。

博者无欲，乐在其中。欲将博客进行到底，请先树立远大宏伟的博客观吧。

© 2012 – 2013, bigwhite. 版权所有.