Go语言学习路线 - 1.方向篇:明确Go语言的成长方向

Go的就业方向

目前，后端开发语言的就业方向主要分为两块：业务系统开发 与 基础平台开发 。Go语言自然也不会例外。

也许有朋友不太了解这两块，那我简单地解释下：

业务系统开发 主要指公司对外盈利的系统，包括 toB 与 toC。由于这个是公司安身立命的根本，所以开发者是必须跟着业务走的。

基础平台开发 指的是公司为了提升工作效率（不仅仅是研发），搭建的一套内部体系，常常需要跨业务支持。

目前主流的云平台，其实是包装成一套业务系统的基础平台，比如阿里云的ECS。 这类云平台是大型公司将自己的基础平台能力沉淀下来后，包装成一套业务系统对外销售，内部也是分成了两类开发人员：上层开发一些多语言接口、计费等业务系统；下层开发对应的基础平台。

Go语言的劣势

很遗憾，我依然在这里不得不进行一些编程语言间的对比。毕竟，如果不清楚一些技术的优劣势，我们很难明确自己的定位和发展方向。

并不是所有编程语言适合各个领域

我先简单地抛出几个例子：

• 游戏、音视频领域主流是C/C++
• 测试、人工智能的主流是Python
• 大数据平台的主流是Java
• 前端的主流是JavaScript

这里的说法并不是绝对的，但选对了语言，能大量地复用业界现有的资源，少走很多弯路。

语言特点决定“轮子”不会太多

Go的生命已有十年多，但新增的特性很少，主要是语言创建者的核心理念 - 简洁。这个理念导致了现成可用的轮子少：以map容器来说，Java至少提供了数十种，可根据不同的场景选择不同的实现，达到性能极致化，而Go只提供了一种通用的基本数据结构。

Go 的设计哲学可以类比为 Unix

那么，我们是否可以采用开源社区中Go的现成库呢？当然可以！那我们来继续拿Java中的容器对比一下，看看改造的成本：

• 在Java中，容器是一个对象类型，已定义对应的接口interface
  • 新的容器类实现对应的接口
  • 改造成本：在创建容器的地方(如beans)替换即可
• 而Go里的容器是基本类型，它的操作是定义在基本语法中，并没有抽象出接口interface
  • 改造成本：新的容器实现后，所有的增删改查代码都需要修改
• 在复杂的嵌套数据结构中，Go的改造成本更大

我们自然可以在自己的项目中，对map/slice操作先封装成一个方法，这样后续改造成本也很低了，但这种思想就很偏向于Java体系了：

1. Go 崇尚的是简洁，map/slice能满足99%以上的使用场景
2. 无法在语言层面将 map/slice 封装成方法，就不能发展成一个语言层面的通用标准，很难推广

没有一套成熟的复杂系统开发方法论

细心的读者可以注意到我这边用到的两个关键词：成熟 和 复杂系统 。用 Go 语言开发的系统自然有不少，但我认为至今为止，业界还没有一套非常适配 Go 语言的系统开发方法论，包括大厂们也是在摸索的过程中（或者说没有公开）。

这里，我列举四个我比较关注的点：

1. 引入DDD设计思想拆分微服务后，如何保证实践与设计一致
2. 如何借用 面向对象UML设计图 类似的实践，梳理复杂系统内的关系
3. 如何组织代码的仓库、目录与分层，适配业务场景
4. 一整套覆盖开发各模块的工具集和最佳实践：如监控埋点、日志链路追踪、测试套件

以上四点业界都有一定的实践，但没有如Spring那般形成一个生态圈，达到一致。 如果达不到一致认可，就无法用工具去强制约束，那么软件工程的复杂度就无法控制了。

明确Go语言的核心成长方向

1. 掌握计算机基础 Go 官方包覆盖了操作系统、网络、数据库等各类常用操作，我们不能停留在 使用 上，而是通过代码去了解它们的 底层实现 ，为后续遇上相关瓶颈时做好基础的知识储备。由于 Go 的源码简洁，所以阅读起来相对其它语言轻松不少。
2. 常用工具库的储备 Go 在开源上存在一些 优秀的轮子，常常能达到事半功倍的效果。我建议分三步走： 会用 、 用好 、体系化 。其中体系化是指要将这些库串联起来，根据场景选择，形成一整套灵活的解决方案。
3. 项目/工程化 将Go的项目与公司的整个研发流程、甚至是产品周期结合起来：小到如何保证一个需求的准确实现，大到如何保证研发架构的合理落地，都是比较有挑战的内容。

也许不少人会认为第三点是一个远超编程语言的话题，在这里讲意义不大。确实，项目工程化更多地是看团队结构、工作流程等上层机制的约束，编程语言能做的不多。 然而，目前Java编程语言已经产生了一个成熟的生态圈，从单纯的代码实现功能，慢慢影响到了开发的各个流程，这样就或多或少地具备了 项目工程化 的一些特征。其它的编程语言如果希望能支持复杂的开发场景，必须得有一套初步的系统化方法论（成熟度暂且不论），才有可能分得一杯羹。当然，由于不同编程语言背后的编程范式、设计理念不同，方法论也各具特色，很有可能随着时间推移而变化。

总结

今天跟大家聊的话题挺广的，也结合了很多我的个人感受，希望能给大家带来启发。下一篇，我会继续 方向篇 的话题，细化到具体工作上，和大家谈谈具体工作上的内容。