分类：其它技术文

最近在想一个问题，为什么大多数软件开发的工作都深陷在“吃力不讨好”的困境中。为什么这么说呢？因为我看到很多程序员小伙伴工作很辛苦，但是往往最终获得的结果或者说外部评价并不好。

在编码实现一个功能时，发现有一个逻辑如果按照全面去考虑的话需要改动很多地方，甚至可能要推翻当前已经写过的部分代码，但是呢现在实际场景并没那么多，当前的实现已经能满足。算了，先这样吧，后续业务怎么发展还不知道呢，到时候再说。

做技术的都知道，程序之间的通讯，常用的方式有两种，RPC 和 HTTP。普遍的共识是系统内部的各个子系统之间的通讯用 RPC，与外部系统之间的通讯用 HTTP。

最近系统在压测过程中发现有一个程序在压力增大后会内存溢出。正好之前自己对 Golang 里分析 dump 这块还没怎么涉及，借此契机学习一下。

最近工作中正好在设计一个方案，以支持 CD 环节的第一个部署节点可以完全自动部署，并且整个环节中尽量减少人为干预的节点。

最近在项目中遇到了一个使用 RabbitMQ 时的问题，这个问题我觉得还是有一定普适性的，和大家分享一下，避免大家后续在同一个问题上犯错。

如果每个子系统都能够内置一个mock工具（模块），通过数据的自动生成，导入和导出，可以灵活地在不同环境上快速地让系统run起来，哪怕自己还没有真正地完成内部的业务逻辑代码编写。

最近正好在学习 Golang，对它的里面用到的三色标记法的 GC 机制有些好奇（