【每周小结】2023-Week5

本周过后，绝大多数打工人就需要从休假模式切换到工作模式。

趁着春节假期的尾巴，我们聊三个轻松的话题。

Go技巧 - 从官方问卷谈谈未来发展

Go官方最近开放了一个问卷，里面收集了用户的相关意见。整个问卷是全英文的，全部填完需要15min左右，有很多是收集用户背景与满意度的常规问题。

这里，我对其中的关键信息做一下提炼。

配套工具的两个开发方向 - Module与IDE

官方在工具侧的两大投入方向在 模块化 与 IDE配套 。

先说说模块化。自Go Module推出之后，已成为一套官方标准，但仍有不少缺憾：如多模块化管理、互相依赖问题，需要官方给出明确的指导意见。而IDE配套，最常见的包括Goland、VsCode、Vim，需要有更多的插件进行支持，如接口与实现的跳转、重构相关工具等。

在我看来，IDE配套工具比模块化更为重要。尽管Goland已支撑了不少能力，但是其高收费、吃内存的特性，对开发者很不友好，而相对轻量级的VsCode面对复杂项目时，各项能力很难支撑。而模块化的问题虽然重要，但目前已有临时的解决方案，只要关注官方推出的方案即可。

用Go语言开发的领域

问卷中的领域方向罗列如下：

• Games
• Mobile apps
• Libraries or frameworks
• Agents and daemons (e.g., monitoring)
• Automation/scripts (e.g., deployment, configuration management)
• A runnable/interactive program (CLI)
• Desktop / GUI applications
• Embedded devices / Internet of Things
• Websites / web services (returning HTML)
• Machine learning / Artificial intelligence
• API/RPC services (returning non-HTML)
• Data processing (e.g., pipelines, aggregation)

我们不妨思考一下，Go语言适合哪些方向？（官方在问卷后面征询了用户意见，希望Go语言支持哪些方向）

这里，其实大部分的方向都具有 门槛，并不适合Go语言，例如：

• 游戏方向需要引擎基础，主流是C++
• 移动设备上的应用注重体验，要用原生的语言
• 嵌入设备很吃性能，主流是C/C++
• 机器学习有TensorFlow/PyTorch等框架，主流是Python
• 大数据生态基本定型，主流是Java

所以，目前用到Go语言的场景主要是三块：

• 基础库与框架
• 命令行工具（采集agent、交互CLI）
• 后端服务（包括返回HTML与普通RPC）

对这三个领域，我有如下建议，希望能引起思考：

1. 基础库与框架
   1. 入门：基础库与框架的最重要目标是提效，那么如何量化到具体指标呢？
   2. 进阶：Go开源社区有不少库与框架，该如何取长补短、又能形成自己的技术壁垒呢？
2. 命令行工具
   1. 入门：Go语言工具与脚本（Shell/Python）等的优劣比较，如何选型？
   2. 进阶：云原生技术生态结合，找准工具的切入角度与定位
3. 后端服务
   1. 入门：与主流编程语言（Java）、框架（Spring）的优劣比较，如何选型？
   2. 进阶：沉淀一整套用Go语言开发的方法论（基建、迭代流程、技术价值等）

小结

从目前来看，Go语言自身的迭代频率不高，整个生态也没有具有突破性的新产品诞生（如Kubernetes），接下来很难有井喷式的增长。而另一方面，Go语言入门的门槛较低，很难形成一定的壁垒（如果希望单靠编程语言就能具有技术壁垒的，建议走C++的路）。

所以，想要有足够的市场竞争力，除了Go语言，我们还需要 综合培养多方面的技能：如计算机基础、业务理解、项目管理等，而不要固守一项技能，被市场慢慢淘汰。

编程思考 - 不要陷入过程性的编码

这个子标题包含两层意思。

第一层比较直观：不要单纯面向过程地编码，而是学会抽象、面向对象。这是一个老生常谈的话题，我举一个例子：

现在，要开发一个管理书本的功能。在面向过程时，我们思路是增删改查，很容易写出对应的代码；而如果要抽象，我们需要钻研 - 书 这个对象，就冒出各种问题：

• 书需要哪些属性？
• 书的管理有权限吗？
• 书与书之间有关联吗？

这些问题也许最终并没有对代码开发有所帮助，但能帮助开发者锻炼抽象思维与理解业务场景。

第二层则是一种工作状态：不要闷头写代码，而应时不时确认方向的正确性。

在Coding时，有些人会陷入 心流 的状态，感觉如有神助，一下子写出几千行代码，但回过头却发现这些代码是无效的 - 不满足需求。要解决这个问题，需要突破两个舒适区：

1. 高频沟通：以文档或demo的方式与需求方沟通，而不要闷头“自嗨式”地闭门造车
2. 放弃沉没成本：在软件行业高频迭代的场景下，很容易出现某项工作中途叫停的情况。如果有足够的自信支撑，那么继续坚持是一种勇气；而如果判断最终大概率失败，那么选择中途放弃也是很大的勇气。

用一个词来总结以上两点的话，就是常谈的 以终为始 。

工作生活 - 更多维的视角

在春节的尾巴，我和朋友去吃了个自助餐。

入座后，我发现隔壁座有个小哥哥，穿着一身睡衣，一个人不紧不慢地吃着，时不时地和服务员闲聊两句，整个就餐过程表现得非常轻松；而到我这边，则一心想着“吃回本”，填鸭式地往嘴里塞，就餐过程非常仓促，最后挺着撑饱的肚子才离开。

我的这种情况在网上非常常见，尤其是那些大胃王的短视频，给观众带来价值观是一种 零和博弈 - 吃得少就是商家赚、食客亏，吃得多就是食客赚、商家亏。这种观点没有问题，却扭曲了很多人吃自助餐的初衷 - 吃自助只是为了不受拘束地点餐或者享受某个美食。如果顾客只是为了吃亏商家，那么商家要么降低服务品质，要么只能倒闭。

世界并不是非黑即白的，我们要从更多维的视角来看问题：单维度的视角（如金钱的得失）很容易发生冲突，而多维度的视角（比如那位小哥哥享受了就餐的过程）可以让我们更享受生活。

Github: https://github.com/Junedayday/code_reading Blog: http://junes.tech/ Bilibili: https://space.bilibili.com/293775192 公众号: golangcoding