这个时代，似乎不需要打稿子来吹牛了，画饼成了常态。！说他们是程序员。程序员真的那么容易进吗？真木大辅认为，成为一名真正的程序员并不容易。以Go语言为例，要成为一名Go程序员，需要经历七次“劫难”。《生活1》：你坚信可以用Go进行面向对象编程吗？经历过Go的应用之旅后，你可能会开始思考：“这门语言如何才能更像一门面向对象的编程语言？”？因为你习惯了这种编程，所以你想要编写健壮的代码，你想要多态性。然后，你说，“一定有办法！”然后，您会发现结构化嵌入，它巧妙地将方法从封闭对象委托给嵌入对象，而无需重复代码。这简直太棒了！当然，用不了多久就会发现这并不能真正解决问题。因为结构嵌入只允许委托方法调用，看起来你在做多态方法分派，但关系不是IS-A，它是HAS-A，方法调用的接收者不是封闭对象，它总是委托方法调用嵌入对象。所以，你明白不要尝试在Go中进行面向对象编程吗？《生活2》：你相信goroutines会解决所有问题吗？在使用它之前，你被“通过goroutines轻松运行并发代码”迷住了，你所要做的就是使用Go关键字并同时运行所有函数或方法调用。这时候你自然会想到让代码并发运行来最大化代码的效率。Goroutines是由函数调用自动创建的，而调用者甚至都没有意识到。是的，它确实允许所有代码同时运行，但它使代码变得更加复杂。Go允许用户在不牺牲太多效率的情况下创建数百万个goroutines，那么你真的应该使用goroutines吗？你要知道并行代码比在单线程中流动的代码更难维护和维护。调试是对的。当一次从多个goroutines访问时，你要考虑共享对象是否正确同步？执行顺序是否绝对正确？当不再需要goroutine时，它??真的会退出吗？所以，goroutine不是唯一的，必须在需要的时候使用，尽量不要在用户背后使用goroutine。因为你通过让你的函数调用自动创建goroutines来隐藏这个事实，调用者甚至不需要知道它。《李杰3》：你认为接口会取代面向对象编程来解决所有问题吗？当你终于意识到对象不能使用多态后，突然想到可以使用接口提供的功能。接口支持API，因此您可以使用它来编写更健壮的代码。所以现在你写库的时候，定义所有的接口，只导出接口，有私有结构，这样才能封装得很好。它还让您更灵活地切换底层实现，因为现在您已经成功地将API与其实现分离。尽管接口给了你很大的权力，但它并不是一个完美的解决方案。在面向对象的编程中，它仍然没有提供真正的多态性，而且您还受到接口只能定义API而不是与其关联的所有数据这一事实的限制。当然，只导出特定场景下的接口是有意义的。当代码量比较少的时候，接口是一个很好的方法。但是如果代码量很大，就得额外写很多代码。如果您想充分利用接口，可以在某些类型互换时使用它。《生活4》：你认为渠道可以解决所有问题吗？当你几经波折，试了很多方法救国无果后，说不定哪天你灵光一现，“等等，还是有渠道的”。隐式处理通道对于并发访问，您认为可以使用各种通道的select语句通过通道巧妙地处理同步、返回值和流量控制。没错，通道是有用的，并且符合你的初衷，它们提供了一个原语，用于在goroutine之间传递值。但是，慢慢的你会发现使用channels的Go语言会有很多问题，比如超时，阻塞I/O，同步问题等等。所以，你要明白channel是一个非常简洁的结构，但是如果被滥用了，这将导致更复杂和难以调试的代码。《李杰5》：“哼，Go语言马马虎虎，哪有大家说的那么厉害？”“为什么？为什么？写Go代码真的很痛苦，已经不允许我按照自己的方式去写了。”在尝试了各种方法后，你发现都无法解决多态和并发的问题，你甚至开始怀疑Go语言存在的合理性，你觉得自己被剥夺了其他语言的所有好处提供。结构和工具。你认为表达抽象思想的更强大的工具是绝对必要的，而Go就是不适合。然而，你忘记了所有的语言都是有限的，你不能一味地想让语言按照你的想法运行，而不考虑作者设计语言的初衷。《李杰6》：你开始意识到前5个阶段其实是你的想象，达到这个阶段，你基本上放弃了各种高明的做法，决定按照大多数标准库的写法来写Go代码。这时候你还有这样的想法：我不想接受Go语言的方法。但这一次，一切都开始变得有趣起来。在不得不放弃面向对象编程转而拥抱Go语言的同时，我也不得不接受编写并发代码太难的事实。我一直坚信语言的意义在于让程序员写出更简洁的代码，所以语言应该足以编写和执行复杂的代码，但是通过去除某些关键工具，最终编写的代码更简单。《李杰7》：在这个阶段，你已经完全接受了Go，你可以用Go来写所有的内容，包括Perl/Ruby/Python的内容。您开始意识到没有更多的错误会打扰您；你必须使用goroutines和channels因为你是Gopher；你为Go语言允许你写出这样的代码而感到荣幸。恭喜你，你已经是一名Go程序员了！
