业余镜像 (Hobby Mirror) —— 为什么要给自己再造一个已有的轮子

一、为什么写这篇

工程师圈子里有一条几乎无人公开反对的"工程常识":

不要重复造轮子。

理由听起来无懈可击 —— 别人写好的、经过生产验证的、有社区支持的、有测试覆盖的工具,你为什么要再写一遍?这是浪费时间,是 NIH 综合征(Not Invented Here),是工程不成熟的表现。

我想给这条常识加一个限定条件 ——

不要在公司的项目里重复造轮子。

但业余时间呢?给自己造一个、不打算交付任何人、不打算上线生产的轮子呢?

我这些年下来的判断是 —— 这恰好是一个工程师把"用着"和"懂着"分开的最有效方式。

这种行为模式我给它起了个名字:Hobby Mirror —— 业余镜像。

生产里你已经在用着某个工具 / 框架 / 库 / 服务,但你不甘心"用着",于是用业余时间从零自己写一份镜像版。生产那份是给公司的,业余镜像是给自己的。

这篇想把这件事讲清楚 —— 什么是业余镜像 / 为什么需要 / 怎么判断该不该做 / 怎么做。

二、起点:"我用着,但我不'懂'"

我自己产生业余镜像这个念头的那一刻,记得很清楚。

那是 2020 年下半年,我在公司参与运营一套外购的实时音视频平台。平台里有一个叫 mems 的服务 —— 它做的事是把实时音视频流转成连续的图片,供下游业务方使用。

我用着它。我接它进我们的运营链路、配合下游业务方调通、写一键部署脚本把它装上、加监控项盯它的活性。它在生产里跑了很久,没出过让我夜里被叫起来的事故。

按"用工具"的标准,我和 mems 的关系已经足够好了。

但有一天我突然意识到:

我"用着"它,但我"不懂"它。

具体讲,mems 内部那些东西 —— RTP 包怎么拆、H264 解码栈怎么接、PTS / DTS 怎么对齐、跨进程的图像数据怎么交给下游 —— 每一处我都能模糊讲出大概,但都讲不到我对"懂"这个词的最低标准。

我对"懂"的最低标准是 —— 我能从零自己写一份。

读源码不够。装一遍不够。讲架构不够。只有自己再写一份,才算懂。

这件事我开始想得越来越多。我意识到 —— 这种"用着但不懂"的状态,在工程师的日常里其实非常普遍:

• 你天天用 nginx,但 nginx 的 epoll 事件循环你能从零写吗?
• 你天天用 Redis,但 Redis 的单线程 + 持久化的取舍你能从零设计吗?
• 你天天用 gRPC,但 gRPC 的 HTTP/2 多路复用你能从零实现吗?
• 你天天用 JSON,但你能从零写一个能解析所有边角 case 的 JSON parser 吗?

用着,不等于懂。这两件事之间有一条很深的鸿沟。

业余镜像,就是把这条鸿沟跨过去的工程动作。

三、我做了什么:hi_rtp 是 mems 的业余镜像

2020 年 11 月,我开了个 gitee 仓库,叫 hi_rtp(https://gitee.com/hi_rtp/hi_rtp)。

它的功能定位跟生产里的 mems 几乎一样 —— 输入实时 RTP 视频流,输出连续图片。

但所有代码从零开始,我自己一行行写。不抄 mems 的源码、不读 mems 的实现细节、只用 mems 的"功能形态"作为参照。我手边的资料是 RFC、是 libuv 文档、是 H264 标准、是 Live555 的代码学习笔记 —— 不是 mems 自己。

这个项目断断续续做到 2021 年 4 月,大约半年时间。期间:

• 把 RTP 协议自己拆了一遍(看 RFC 3550 + RFC 6184)
• 自己接了 H264 解码栈(踩到了好几个我之前在 mems 上"用着但从没注意过"的坑)
• 用 libuv 做事件循环,这是我第一次从零搭建一个生产级别的 reactor 模式应用
• 边写边踩坑,边踩坑边修认知

hi_rtp 写完之后没有进过生产,也不打算进生产。它的目的从一开始就不是"给公司用"或"给别人用"。它只服务一个用户:我自己。

但它真正做到的那件事是 ——

mems 在我脑子里,从"模糊的功能轮廓"变成了"清晰的实现路径"。

我开始真正"懂"流媒体了。

这种"懂"的差别,任何"读源码 / 写文档 / 做技术分享"都做不到。

只能自己写一遍才能换到。

四、业余镜像 ≠ 重复造轮子(请把这两个概念分开)

很多人看到"重新写一份功能上已存在的东西",条件反射地说 —— 这不就是重复造轮子吗?

不是。这两件事的目的不同、产物不同、判定标准不同。

维度	重复造轮子	业余镜像
场景	在公司项目里替换已有工具	在业余时间另起炉灶
目的	替代现有工具,投入生产	不替代,不投入生产
产物	必须达到/超过原工具的工业标准	只要在功能轮廓上跑通即可,质量不是优先项
评价标准	跟原工具直接对比性能/稳定性/可维护性	跟"我之前对这件事的理解"对比认知增量
目标读者	团队、下游、运维、未来维护者	只有我自己
成功标志	上线、被采用、被维护	我"懂"了

差别极大。

重复造轮子的逻辑是经济学 —— 我能不能用更低的总成本得到更好的工具。

业余镜像的逻辑是认知论 —— 我能不能通过亲手做一遍,把一个原本模糊的事情,变成我脑子里清晰的事情。

这两件事根本不在一个评价体系里。

公司里写代码必须用经济学逻辑;业余时间里给自己写代码,当然可以、应该、有时候必须用认知论逻辑。

重复造轮子是为了交付一个更好的轮子。

业余镜像是为了让自己真正成为一个"会造轮子的人"。

五、业余镜像的核心价值:把"用着"和"懂着"分开

工程师圈里有一个普遍但很少被点破的现实:

你简历上写"熟悉 X、使用过 Y、参与过 Z 项目",和你真的能从零搭出 X / Y / Z,是两件事。

很多工程师从业 5 年、10 年,简历越来越长,但他们 80% 的技术理解,停留在"用着"这一层

这不是他们懒。这是因为生产环境的要求,只到"用着"这一层就够了。你能让它跑、让它稳、让它接进业务,就算完成工作。

"懂"这一层 —— 它对生产没有直接的额外贡献,但对你这个工程师本人,差别是天壤之别。

懂的人和用的人,差别在哪里?

• 遇到怪问题时的判断速度 —— 懂的人 5 分钟定位,用的人翻一天 issue
• 做技术选型时的判断质量 —— 懂的人凭机理判断,用的人凭口碑判断
• 能不能教别人 —— 懂的人能教会别人,用的人讲不清楚
• 能不能跨场景迁移 —— 懂的人换一个领域也能立刻接得上,用的人换了环境就傻
• 能不能在 AI 时代继续有价值 —— 懂的人能指挥 AI,用的人会被 AI 替代

业余镜像,是把"用着"升级成"懂着"的最便宜也最有效的工程动作。

六、什么样的工具值得做业余镜像?(判断标准)

不是所有"用着的工具"都值得做业余镜像。我自己用下来的判断标准是这几条:

1. 它在你长期技术地图上很重要

未来 5-10 年你大概率还会用它、或者用它的同类。否则镜像了也用不上。

2. 你"用着"的状态已经稳定了

你已经能在生产里熟练操作它了。这时候做业余镜像,是把"操作熟练"升级成"原理通透";如果连用都还没用熟,直接做镜像是在浪费时间。

3. 它的"功能形态"足够小,你业余时间能 cover

不要试图给 Linux 内核做业余镜像。挑那种"核心功能 1-2 周能搭起来 demo,半年能搭到生产级"的工具。

4. 市面上"已有教程 / 已有简化实现"足以做参照系

你不需要在荒野里独行。业余镜像 ≠ 完全独创,你可以参考已有的简化实现、教科书、RFC、规范 —— 但你必须自己一行行敲出来。

5. 它能让你触及一个"你之前没碰过的底层概念"

hi_rtp 让我触及了"reactor 模式 / 协议解析 / 跨进程零拷贝";如果你已经懂这些了,做镜像的认知收益就小了。

满足 3-4 条以上,值得做。否则别做,业余时间宝贵。

七、做业余镜像的几条具体建议

如果你决定做一个业余镜像,我有几条具体建议:

1. 明确"这只服务我自己"

从第一天起就接受这件事 —— 它不需要被任何人看到、不需要被部署、不需要做单元测试覆盖率,只需要让你"懂"。一旦你想把它工程化、产品化、开源化、推广化,它就脱离了业余镜像的定义。

2. 不抄原工具的源码

只用"功能形态"作为参照 —— 输入是什么、输出是什么、关键性能指标是什么。具体实现路径要你自己想、自己踩。抄了就失去镜像的意义了 —— 你只是把"用着"换成"复制粘贴着",没有升级到"懂着"。

3. 不追求质量,只追求理解

代码可以丑、可以重复、可以漏掉一万种 corner case。每一处你"觉得别扭但还是先放着"的地方,都是认知盲点。在镜像里允许自己有盲点,在工作里一定会有解决它的下一次机会。

4. 写一份"认知日志"

我在 hi_rtp 里写过一个 testing-discussion.md,记录的不是代码,是"我当时怎么想 / 后来又怎么想"。半年后回头看,这种文档比代码本身更有价值 —— 它是你认知迭代的化石。

5. 设一个时间盒,但允许跨越

我给自己定的是"3 个月跑通 demo,半年到一个能玩的状态"。实际拖到 6 个月才到 demo,1 年才有玩的形态 —— 没关系。业余镜像的死法不是慢,是"做着做着觉得没意义放弃了"。

6. 做完之后,允许它死

hi_rtp 我半年活跃,之后基本没动过。这是正常的、健康的、不可耻的。它的使命已经完成 —— mems 在我脑子里清楚了,这就够了。不要因为"开源了就得维护一辈子"的道德绑架,把业余镜像变成又一项负担。

八、业余镜像背后,是一种工程师品牌

写到这里我想讲一件比业余镜像本身更大的事。

业余镜像不是孤立的行为。它背后是一种特定的工程师品牌 —— 这种工程师认为:

• "我用什么"是公司决定的,但"我懂什么"必须我自己决定
• 简历上的技术栈是公司的,脑子里的技术理解必须是我自己的
• 生产环境的工具是别人写的,但我每用 5 年某种工具,就给自己写一份业余镜像

这种工程师不依赖公司给他成长 —— 公司当然能给一部分,但他相信最深的那部分,只能靠自己业余时间一行行敲出来。

这跟我之前博客里讲的 "不依附于任何人,但依附客观" 是同一根血脉:职业上不依附公司,技术上不依附"用着即懂"的幻觉。

业余镜像是这种独立姿态的工程实物。

它不一定让你升职加薪 —— 短期看几乎肯定不会。但 10 年下来,有业余镜像习惯的工程师,和没有的工程师,会变成两种完全不同的人。

九、最后

回到开头那条"不要重复造轮子"。

我现在的版本是:

不要在公司里重复造轮子。

但请给自己留几个业余镜像。

不为了交付,不为了简历,不为了开源 star。

为了你脑子里那一份"我真的懂了"的清晰感。

---

附:我自己的业余镜像不止 hi_rtp 一个。早在 2013-2016 年,我看着 Live555、JUnit、NUnit,业余给自己写过一套 C++ 单元测试框架(代码至今还在 https://github.com/xumingxsh/HiTest 上),三代迭代,2014 年还写过一篇 16810 字的博客把它讲透。那时候我还不知道 Hobby Mirror 这个名字,但已经在做这件事了。

人有时候做着某件事很久,只是没给它命名。

写下名字的那一刻,它才真正成了你的方法论。

---

行动召唤

如果你看完这篇,有那么一两个"我用着但不懂"的工具浮现在脑海里 —— 挑一个,定个时间盒,从这周开始。

不为了卷,不为了焦虑,为了让自己 10 年后,脑子里清楚的事比简历上长的事多一点。