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体系了:
- Go 崇尚的是简洁,map/slice能满足99%以上的使用场景
- 无法在语言层面将 map/slice 封装成方法,就不能发展成一个语言层面的通用标准,很难推广
没有一套成熟的复杂系统开发方法论
细心的读者可以注意到我这边用到的两个关键词:成熟 和 复杂系统 。用 Go
语言开发的系统自然有不少,但我认为至今为止,业界还没有一套非常适配 Go
语言的系统开发方法论,包括大厂们也是在摸索的过程中(或者说没有公开)。
这里,我列举四个我比较关注的点:
- 引入
DDD
设计思想拆分微服务后,如何保证实践与设计一致 - 如何借用 面向对象UML设计图 类似的实践,梳理复杂系统内的关系
- 如何组织代码的仓库、目录与分层,适配业务场景
- 一整套覆盖开发各模块的工具集和最佳实践:如监控埋点、日志链路追踪、测试套件
以上四点业界都有一定的实践,但没有如Spring那般形成一个生态圈,达到一致。
如果达不到一致认可,就无法用工具去强制约束,那么软件工程的复杂度就无法控制了。
明确Go语言的核心成长方向
- 掌握计算机基础
Go
官方包覆盖了操作系统、网络、数据库等各类常用操作,我们不能停留在 使用 上,而是通过代码去了解它们的 底层实现 ,为后续遇上相关瓶颈时做好基础的知识储备。由于Go
的源码简洁,所以阅读起来相对其它语言轻松不少。 - 常用工具库的储备
Go
在开源上存在一些 优秀的轮子,常常能达到事半功倍的效果。我建议分三步走: 会用 、 用好 、体系化 。其中体系化是指要将这些库串联起来,根据场景选择,形成一整套灵活的解决方案。 - 项目/工程化 将
Go
的项目与公司的整个研发流程、甚至是产品周期结合起来:小到如何保证一个需求的准确实现,大到如何保证研发架构的合理落地,都是比较有挑战的内容。
也许不少人会认为第三点是一个远超编程语言的话题,在这里讲意义不大。确实,项目工程化更多地是看团队结构、工作流程等上层机制的约束,编程语言能做的不多。
然而,目前
Java
编程语言已经产生了一个成熟的生态圈,从单纯的代码实现功能,慢慢影响到了开发的各个流程,这样就或多或少地具备了 项目工程化 的一些特征。其它的编程语言如果希望能支持复杂的开发场景,必须得有一套初步的系统化方法论(成熟度暂且不论),才有可能分得一杯羹。当然,由于不同编程语言背后的编程范式、设计理念不同,方法论也各具特色,很有可能随着时间推移而变化。
总结
今天跟大家聊的话题挺广的,也结合了很多我的个人感受,希望能给大家带来启发。下一篇,我会继续 方向篇 的话题,细化到具体工作上,和大家谈谈具体工作上的内容。