本周过后，绝大多数打工人就需要从休假模式切换到工作模式。
趁着春节假期的尾巴，我们聊三个轻松的话题。
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）
对这三个领域，我有如下建议，希望能引起思考：
- 基础库与框架
- 入门：基础库与框架的最重要目标是提效，那么如何量化到具体指标呢？
- 进阶：
Go开源社区有不少库与框架，该如何取长补短、又能形成自己的技术壁垒呢？
- 命令行工具
- 入门：
Go语言工具与脚本（Shell/Python）等的优劣比较，如何选型？ - 进阶：云原生技术生态结合，找准工具的切入角度与定位
- 入门：
- 后端服务
- 入门：与主流编程语言（
Java）、框架（Spring）的优劣比较，如何选型？ - 进阶：沉淀一整套用
Go语言开发的方法论（基建、迭代流程、技术价值等）
- 入门：与主流编程语言（
小结
从目前来看，Go语言自身的迭代频率不高，整个生态也没有具有突破性的新产品诞生（如Kubernetes），接下来很难有井喷式的增长。而另一方面，Go语言入门的门槛较低，很难形成一定的壁垒（如果希望单靠编程语言就能具有技术壁垒的，建议走C++的路）。
所以，想要有足够的市场竞争力，除了Go语言，我们还需要 综合培养多方面的技能：如计算机基础、业务理解、项目管理等，而不要固守一项技能，被市场慢慢淘汰。
编程思考 - 不要陷入过程性的编码
这个子标题包含两层意思。
第一层比较直观：不要单纯面向过程地编码，而是学会抽象、面向对象。这是一个老生常谈的话题，我举一个例子：
现在，要开发一个管理书本的功能。在面向过程时，我们思路是增删改查，很容易写出对应的代码；而如果要抽象，我们需要钻研 - 书 这个对象，就冒出各种问题：
- 书需要哪些属性？
- 书的管理有权限吗？
- 书与书之间有关联吗？
这些问题也许最终并没有对代码开发有所帮助，但能帮助开发者锻炼抽象思维与理解业务场景。
第二层则是一种工作状态：不要闷头写代码，而应时不时确认方向的正确性。
在Coding时，有些人会陷入 心流 的状态，感觉如有神助，一下子写出几千行代码，但回过头却发现这些代码是无效的 - 不满足需求。要解决这个问题，需要突破两个舒适区：
- 高频沟通：以文档或demo的方式与需求方沟通，而不要闷头“自嗨式”地闭门造车
- 放弃沉没成本：在软件行业高频迭代的场景下，很容易出现某项工作中途叫停的情况。如果有足够的自信支撑，那么继续坚持是一种勇气；而如果判断最终大概率失败，那么选择中途放弃也是很大的勇气。
用一个词来总结以上两点的话，就是常谈的 以终为始 。
工作生活 - 更多维的视角
在春节的尾巴，我和朋友去吃了个自助餐。
入座后，我发现隔壁座有个小哥哥，穿着一身睡衣，一个人不紧不慢地吃着，时不时地和服务员闲聊两句，整个就餐过程表现得非常轻松；而到我这边，则一心想着“吃回本”，填鸭式地往嘴里塞，就餐过程非常仓促，最后挺着撑饱的肚子才离开。
我的这种情况在网上非常常见，尤其是那些大胃王的短视频，给观众带来价值观是一种 零和博弈 - 吃得少就是商家赚、食客亏，吃得多就是食客赚、商家亏。这种观点没有问题，却扭曲了很多人吃自助餐的初衷 - 吃自助只是为了不受拘束地点餐或者享受某个美食。如果顾客只是为了吃亏商家，那么商家要么降低服务品质，要么只能倒闭。
世界并不是非黑即白的，我们要从更多维的视角来看问题：单维度的视角（如金钱的得失）很容易发生冲突，而多维度的视角（比如那位小哥哥享受了就餐的过程）可以让我们更享受生活。
Github: https://github.com/Junedayday/code_reading
Blog: http://junes.tech/
Bilibili: https://space.bilibili.com/293775192
公众号: golangcoding
