别再 reinvent the wheel 了

在 .NET 开发者的日常中，有一个令人舒适的事实：当你突然需要功能标志（feature flags）时，答案其实无聊得可爱——安装 Microsoft.FeatureManagement，在 appsettings.json 里配几个开关，完事。

这种“无聊”恰恰是软件工程的最高境界。然而，我们这一行有一种危险的惯性：面对需求，第一反应往往是“我要造一个更好的”。

无聊的方案，才是好方案

很多开发者沉迷于自己造轮子，仿佛这能证明技术深度。但现实是，那些真正赚钱、稳定运行的工具，往往是由最“无聊”的现成方案组合而成的。

AI 时代让“自己写代码”变得前所未有的容易。一行提示词就能生成一个模块，这使得“自建”的门槛跌到了谷底。但这恰恰是个陷阱。易得性不等于必要性。

当你在深夜对着屏幕思考是否要手写一个支付网关封装时，请停下来问自己：这个轮子的价值，在于它“是我造的”，还是在于它“解决了问题”？如果现有的开源库或 SaaS 已经能覆盖 95% 的需求，剩下的 5% 定制化成本，远高于你开发维护的时间成本。

时间比代码值钱

我见过太多聪明的开发者，花三个月做一个“更好的 XX”，结果上线才发现市场上已经有十个更成熟的竞品。这不是嘲笑，我也曾深陷其中。

但后来我学到最重要的一课是：除非你能做出别人做不了的东西，否则别 reinvent the wheel。

你的时间比你的代码值钱得多。自建一个轮子，意味着你占用了一小时打磨真正差异化功能的时间。一个能克制“自建冲动”的开发者，其产品在市场上的存活率通常更高，因为他们把精力押注在了真正的业务逻辑上，而不是基础设施的重复建设上。

决策三步法

下次遇到需求时，别急着打开 IDE，先问三个问题：

1. 有没有现成开源方案？ 先搜 GitHub，再搜 NuGet/Pypi/Composer。
2. 有没有付费 SaaS 能解决？ 有时候花 $29/月 买一个服务，比你请人维护半年的成本低得多。
3. 自己造的核心价值在哪里？ 只有当现有方案无法满足你的差异化竞争点时，才考虑自建。

记住这条规则：先买，后用，再想有没有必要自己造。 这不是偷懒，这是对商业效率的极致尊重。在独立开发的道路上，克制，往往比创造力更稀缺。