Go语言大神亲述:历七劫方可成为程序员!

golang| 2017-10-03

现在这个时代似乎吹牛都不用打草稿，画饼已成为常态，搬个砖都敢说自己是工程师，会敲个“Hello World!”的都说自己是程序员。程序员真的是那么好入行的吗? Daisuke Maki认为成为一个真正的程序员并不是件易事，以Go语言为例，想成为一个Go程序员需经历七大“劫难”。

“历劫1”：你坚信你可以用Go来做面向对象编程?

在经历了一次Go应用之旅之后，你可能就会开始思考：“怎么样才能让这种语言更像面向对象的编程语言?”因为你已经习惯了这种编程，你想要制作健壮的代码、想要多态。

然后，你说：“一定有办法实现的!”再然后，你就发现了结构嵌入，它可以将来自封闭对象的方法巧妙的委托给嵌入对象，而无需重复代码。这简直是太伟大了!

当然，很快你就会发现这并不能真正解决问题。因为结构嵌入只允许委派方法调用，所以看起来你是在做多态方法调度，但关系并不是IS-A，而是HAS-A，方法调用的接收方不是封闭对象，而始终是委托方法调用的嵌入对象。

所以，你明白了不要试图在Go中进行面向对象的编程?

“历劫2”：你相信goroutines会解决所有的问题?

在使用之前，你曾被“通过goroutines可以轻松运行并发代码”所蛊惑，你所要做的就是使用Go关键字，同时运行所有函数或者方法调用。这时你自然就会想到通过让代码并发运行来最大限度地提高代码的效率。通过函数调用自动创建goroutines，甚至调用者都没有意识到。没错儿，它的确做到了所有代码都在同时运行，但是它让代码变得更复杂了。

Go允许用户创建数百万的goroutine，而且不会牺牲太多的效率，那么你真的应该使用goroutine吗?你要知道并行代码相比在单线程中流动的代码而言，是更加难以维护和调试对的。一次从多个goroutine访问时，你要考虑共享对象是否正确同步?执行顺序是否绝对正确? goroutine是否在不再需要时实际退出了?

所以，goroutine并不是万能的，一定要在必要的时候使用，而且尽量不要在用户的后面使用goroutine。

并且因为您通过使您的函数调用自动创建goroutines来隐藏此事实，因此调用者甚至不需要意识到这一点。

“历劫3”：你认为接口将代替面向对象编程解决所有的问题?

在你终于意识到对象无法使用多态之后，突然想到了可以利用接口提供的功能，接口支持API，所以可以使用它来编写更健壮的代码。

所以现在当你编写库时，定义了所有的接口，只导出接口并具有私有结构，以便封装成perrrrfect。它还为你提供了更多的灵活性来切换底层实现，因为现在你已成功地将API与其实现分离。

接口虽然给予了你很大的权力，但它不是一个终极解决方案。在面向对象编程中，它仍然没有提供真正的多态性，而且你也要受到接口只能定义API的限制，无法将所有数据与其相关联。

当然，在某种场景下只导出接口是有意义的，当代码量比较小的时候，接口是很好的方法。但是如果在代码量大的时候，你不得不额外再多编写大量的代码。

如果想要最大限度的利用接口，可以在某些类型互换时使用。

“历劫4”：你相信channel可以解决所有问题?

在你历经曲折，尝试了多种方法曲线救国无果之后，也许某一天灵光一闪，“等等，还有channel。”

Channel隐式处理并发访问，你相信通过channel可以巧妙的来处理同步、返回值以及使用各种channel的select语句来进行流量控制。

没错，channel是很有用的，和你的初衷也是相符的，它提供了一个在goroutine之间传递值的原语。但是，慢慢你就会发现使用channel的Go语言会出现很多问题，例如超时、阻塞I / O，同步问题等。