什么时候才应该造轮子？

前言

这篇博客源于我在前公司的经历与思考。

我前公司是一家金融企业，业务中大量涉及金额处理，金额的特殊性要求处理必须极其严谨。然而，在我们的项目中关于大数字的各种元信息：有效数字信息，舍入信息等等，还有很多处理金额的方法分散在项目各处。它们可预见的难以治理。

同时，我在梳理老项目的的时候发现有一个基于 BigDecimal 的子类 Amount，针对我们的特定的业务场景和常用的金额约束封装了一些 api，也内嵌了我们常用的标准，从 DDD 的视角看，它算得上一个领域对象。遗憾的是，它没有得到广泛使用，已经被废弃了，同事们还是在直接使用 jdk 的 BigDecimal。这篇文章分析一下 Amount 产生的背景，并分享一下我的想法。

Amount 的结局。也是很多内部轮子的的共同结局：在工作中总结提炼功能沉淀知识，投入人力开发了的轮子，不是由于功能或技术缺陷，而是因为没有用户，迎来了自己生命周期的结束。

场景

pros

• 实现功能：针对需要使用大数字金额计算的场景的各种计算方法，沉淀于实践中，经常会被使用
• 解决痛点：封装的公司的各种统一标准要求，将使用者从许多与业务无关的标准中解放出来
• 优化设计：提供很多常用方法的统一入口，方便未来相关逻辑的集中变更

痛点虽小但切实存在，Amount 功能清晰直面问题，价值传递明确。

cons

• 广泛流传的 解决方案“足够好”： 同事们更熟悉 BigDecimal，且它已经足以完成任务，满足大部分核心需求
• 推广乏力：推广策略不力，创造这个轮子的人已经离职，知道这个轮子的技术骨干或核心用户无意愿推广
  • 没有沉淀的文档，新人不知道这个东西
• （尽管微小的）学习成本：新 api 的学习成本

这些原因最终导致了 Amount 推广失败，被废弃。

思考

在我眼中，Amount 正是应该文档化，沉淀下来的内容，需要我们在老人与新人之间传递的知识，它包含了与我们业务深切关联，又无法直接传授，需要经验积累的内容，在我们实际运用的场景中却被轻易抛弃了。

一方面是我原来公司在文档化，知识体系化这方面做的不好，另一方面又不禁让我思考：作为一个一线开发者，在日常开发中提炼总结一些内容，开发一点小小的面向特定问题的小轮子，有意义吗？

很难找到比这个例子的场景更切合痛点，解决更清晰，更容易切换，学习成本更小的场景了，它依然未能成为一个流传下来、持续创造价值的通用组件，我能看出来它的价值，愿意使用，更多的同事却不这么认为，你不能想当然的要求其他人有和你一样的学习的意愿，愿意承担这些成本。

因此，做出一个有价值的轮子很可能只是一厢情愿，存在相当高的概率你一离职，就没人在乎了，会不会被继续使用只是一件完全随机的事情。那么在这个结论之下，所有轮子都应该面向 KPI，让大家用脚投票决定什么东西是有价值的，需要广泛传播的吧。

顺便补一下 ai 的回答，真的有点搞了 D 指导。

补刀1：轮子死亡的根本原因 = 创造者混淆了「发明权」和「立法权」
你以为写了优雅代码就自动获得话语权？真相是：
⚠️ 技术优越性 ≈ 选票
⚠️ 组织影响力 = 政权

补刀2：所有未被疼痛逼出的轮子都是早产儿
“封装业务标准” 这种高端需求，在人类大脑的优先级排序中远低于 “本迭代需求 Deadline”。
真正该问的不是 “为什么不用好轮子”，而是 “为什么他们不疼”：

补刀3：文档是轮子的裹尸布，不是复活甲
我们总幻想：“要是当初写好文档就...”，但真相是：
📜 文档在组织传播链中的地位 ≈ 金字塔里的象形文字
复活术：把文档拆解成 可嵌入工作流的生存工具：