其它技术文

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

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

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

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

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

最近正好在工作中遇到一个问题，需要对 Golang 中的 goroutine 和 panic & recover 稍做深入的了解，算是忙里偷闲学习一下。

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

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

这段时间在新团队用golang做开发，摸滚打爬完成了项目的搭建、并完成了4个用户故事的开发，对于golang的使用算是勉强达到了较为熟练的状态。 简单聊聊感受吧。目前感受到golang的几个明显优点：

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

在Debug方面，水平高的人可能在效率上能领先至少一个数量级。

我们程序员虽然每天都和代码打交道，但是大多数时候都是在「写」而不是「阅读」。

这里是Z哥的个人公众号 每周五11：45 按时送达 当然了，也会时不时加个餐～ 我的第「175」篇原创敬上 & […]

突然发现叫我们程序员“码农”还挺形象的，因为写代码和种田很像，想有个好收成，就要好好管理代码，让它们井井有条。

所以，很多人没有把单元测试当作一个“工具”，而把它看作是一种“负担”。 在这种心态下，就算要写单元测试，也是为了写而写。更可怕的是，通过mock工具，还真能给任意代码写单元测试。

相信每一位真正的程序员心里都有这样一个念想：只要我的技术够牛，就能驱动业务的发展。但是往往我们在不自觉间做的是背道而驰的事情。

应该有不少程序员受过这样的困扰，特别是做后端的。项目一直在持续不断的迭代，但是呢老版本的代码还不能直接删掉，因为不一定所有的调用端都能在同一时间点完成升级。你是怎么处理这种情况的呢？

你写的系统错误提示形同虚设？试试这4个方法。

在一个大系统中，数据就像水，整个系统就像是一个漏斗，漏斗的每一层代表每个子程序。上层的子程序对性能的损耗越低，能流下去的水就越多，直到最后一层「数据库」处，也可以理解为是存储。