文章指出，编码中最大的误区之一是认为依赖项没有成本，实际上依赖项可能带来显著的学习成本、因接口变更导致的代码重写成本，以及部署复杂性。作者以Tigerbeetle为例，强调有时自行实现功能比使用复杂依赖项更高效，避免为部署而“重新发明轮子”。

文章主要内容总结

标题：NIH（Not Invented Here）比错误的依赖更便宜

文章链接：NIH Is Far Cheaper Than The Wrong Dependency

发布时间：2025年7月18日

1. 依赖的代价

文章指出，许多开发者认为使用依赖库是“免费”的功能，但实际上依赖库存在显著的代价： - 学习成本：依赖库通常庞大且复杂，学习使用它们可能比自行编写功能更耗时。 - 破坏性变更：依赖库的更新可能导致代码重写，以适配新的接口。 - 部署复杂性：确保依赖库在客户端机器上正确安装和运行，可能引入复杂的容器化或打包设置。

2. TigerBeetle的零依赖策略

文章以TigerBeetle为例，说明其采用“零依赖”策略的原因： - 供应链攻击风险：依赖库可能引入安全漏洞。 - 性能和安装时间：依赖库可能影响性能和安装速度。 - 工具选择：TigerBeetle选择Zig作为主要工具，尽管它并非万能，但足够应对大多数问题，并减少了开发环境的复杂性。

3. 依赖评估框架

文章提出了一个评估依赖库的框架，包含五个维度： - 普遍性（Ubiquity）：依赖库是否广泛可用，是否需要在目标环境中预装。 - 稳定性（Stability）：依赖库的破坏性变更频率。 - 深度（Depth）：依赖库提供的功能深度，是否难以替代。 - 易用性（Ergonomics）：API是否声明式，是否易于使用。 - 严密性（Watertightness）：抽象是否泄漏，是否需要频繁考虑底层技术。

4. 好依赖与坏依赖的示例

文章列举了几个“好依赖”的示例： - POSIX系统调用：广泛可用、稳定、功能深度大，但易用性一般。 - ECMA-48终端控制代码：几乎在所有终端模拟器中可用，标准自1991年以来未变，功能深度大，易用性尚可。 - Web平台（Web API、HTML、JS、CSS等）：浏览器是广泛部署的平台，具有深度功能，易用性较好，抽象较为严密。

5. 总结与建议

文章最后提醒读者，选择依赖库时应批判性思考，权衡成本与收益，做出明智的选择。

（注：原文中没有图片标记，因此此处不保留图片信息。）

评论主要围绕软件依赖管理的利弊展开，观点多样，以下是总结：

支持减少依赖的观点：

1. 依赖最小化：减少依赖可以降低系统出错的可能性，提升软件的健壮性。

   • "One technique for making software more robust is to minimize what your software depends on – the less that can go wrong, the less that will go wrong." (评论 2)
   • "If a dependency is paid, than it is usually bad. Because the company providing that dependency has an incentive to lock you in." (评论 1)

2. 依赖的风险：依赖可能带来锁定、安全漏洞和维护成本等问题。

   • "Dependencies introduce risks, but not using them at all puts you at a competitive disadvantage against those who are using them." (评论 17)
   • "Their breaking changes can trigger expensive re-writes of your own code to handle a new interface." (评论 18)

支持使用依赖的观点：

1. 依赖的效率：使用依赖可以加速开发，避免重复造轮子。

   • "Even using a 'bad' dependency is far more effective than writing in-house." (评论 10)
   • "Dependencies introduce risks, but not using them at all puts you at a competitive disadvantage." (评论 17)

2. 依赖的规模优势：大规模使用的依赖通常更稳定，问题更早被发现和修复。

   • "If a tooling or backend dependency is being production deployed by a company at a scale of 10^2 or 10^3 times your use case, you're much less likely to hit insurmountable performance issues." (评论 5)

中立或平衡观点：

1. 依赖管理的策略：依赖管理需要权衡利弊，制定合理的流程。

   • "What you need is a process to manage dependencies: Only consider open-source dependencies, review new dependencies, and be prepared to fork them if necessary." (评论 17)
   • "NIH is amazing as long as you are realistic about what you are taking ownership of." (评论 15)

2. 依赖的适用性：依赖的选择应根据具体场景和团队能力决定。

   • "Sometimes it's easier to write it yourself than install the dependency, but this is only relevant if you're a solo dev or in for the long haul." (评论 12)
   • "Often I find that the need for libraries can be an indictment of complexity against the problem space." (评论 14)

其他观点：

1. AI与依赖管理：AI工具可以帮助减少依赖，但自身也是一种依赖。

   • "With AI NIH will be the new normal." (评论 11)
   • "AI code assistance helps us avoid dependencies by generating CLI tools for code and config generation." (评论 8)

2. 文化背景：某些文化背景（如新西兰的“Number 8 wire”思维）可能影响对依赖的态度。

   • "You have to understand the Number 8 wire mindset to put this in context." (评论 9)

总结：依赖管理是一个复杂的问题，既需要减少依赖以降低风险，又需要合理使用依赖以提高效率。团队应根据具体场景制定管理策略，权衡利弊。