关于“非我发明综合症”的偶发误诊

非我发明综合症 (NIHS) 是一个略带讽刺意味的名称，指的是个人开发人员和整个组织倾向于拒绝适合软件开发问题的外部解决方案，而倾向于内部开发的解决方案。

这句话在我最近参加的一次讨论中出现过，我想谈谈它。究竟是自己构建还是选择现成的解决方案，是我们能够进行的最重要的讨论之一，所以更多的视角总是有用的。这句话完美地概括了我们在软件开发中可能存在的一种偏见：我们武断地相信自己的解决方案，而没有考虑到开发的成本和痛苦，更重要的是，维护。

即使这是一个合理的概念，也不要过分强调它的重要性。一个类似的概念是“不要重新发明轮子”。它们可能在某种程度上可以互换。我想探讨一下这些想法应该和不应该应用在哪些地方。你对这些想法的理解可能会有所不同。

这句话最适用的地方

基础底层软件，例如数据库和框架，通常不应该在没有痛苦的需求和深思熟虑的情况下被重新发明。在 DEV 中，一些例子包括 PostgreSQL、Ruby on Rails、Preact、Redis 等。其他实用程序库可能不需要重新发明，例如 HTTParty，它基于 Ruby 提供的核心 HTTP 功能提供了一个简洁的接口。有时需要沿着这样的思路发明新的东西，但这并不总是一个好主意。

我们的许多核心外部服务，例如日志记录、支付和监控，或许也不应该被彻底改造。这些服务本身就非常复杂，基础设施、甚至监管都过于繁琐，因此彻底改造似乎非常不明智。

这句话不适用的地方

“重复比错误的抽象要便宜得多”——Sandi Metz

这句话和这篇博文都很棒，非常适合这里。这场争论的焦点始终在于当前主题的抽象是否正确。

前面提到的 PostgreSQL 既是强大又出色的软件，但对于很多类型的数据来说，它却是一个错误的抽象。这就是为什么其他数据库被发明出来的原因。它们也存在抽象漏洞，就像所有软件一样。我们接受这种抽象，是因为构建一个具体的解决方案显然是一个糟糕的主意。在那些尝试和不尝试的人中进行的自然选择，或许足以将这种想法从我们的辩论中剔除。

当讨论“业务逻辑”时，例如我们为解决用户问题并实现项目最终目标而编写的代码类型，很多时候“自行发明”确实是一个好主意。而当寻求外部解决方案时，始终要牢记可能需要迁移到外部解决方案。正确的抽象非常难得。在 DEV 中，我们使用了大量“非我发明”的库，并且总是存在一些限制，这不禁让人思考，我们是否应该自己编写这些逻辑。

一些库，acts-as-taggable-on处理acts_as_follower了很多标签和关注者的逻辑。短期内放弃这些库并不现实，但它们给我们提供了一些不同的意见，有时我们最好自己将这些概念写入应用程序。标签和关注是更高级的抽象，不会像数据库和框架那样复杂。由于这些是我们关注用户体验的领域，因此即使我们当前需要的功能在库中可用，我也采取了“是的，在这里发明！”的态度。

任何与我们团队有效工作流程相关的内容，尤其是在审核和管理方面，通常都应该由我们的团队和社区来编写。我们与软件的交互方式，尤其是任何可能造成破坏性后果的内容，都迫切需要我们内部编写。我们是一家技术驱动的组织，拥有雄厚的资金和开源社区，这很有帮助。

在某些情况下，我会将库代码复制粘贴到项目中，而不是直接包含到包中，以便立即采用部分功能，同时也考虑到在不可避免地需要时，内部代码的可修改性。如果出于错误的原因，这样做并不“干净”，但本质上也并非肮脏。

NPM 和 left-pad：我们忘记了如何编程吗？

这又是一篇让我印象深刻的文章。或许是因为我亲身经历了“Left Pad”的痛苦——JavaScript 社区的清算日。

这篇文章涉及了很多我在这里概述的相同想法，更具体地说是参考了以将这种想法发挥到极致而闻名的“npm 文化”。

对于任何需要花费大量时间、金钱和/或调试才能自行编写的复杂功能，都应将其作为依赖项。例如，数据库访问层 (ORM) 或缓存客户端之类的功能就应该作为依赖项，因为它们非常复杂，而且为了节省成本和提高效率，承担依赖项的风险是值得的。

但是，出于对编程的热爱，请编写您自己的基本编程功能。

综上所述

“非我发明综合症”确实存在，但很容易让人走火入魔。技术驱动型公司应该进行大量的创新，即使感觉像是在重新发明。我们就是这样做的。我们认同的这些命名模式应该始终成为对话或辩论的开端，而不是结束辩论的结局。

我的论点中有很多细节与我们自身的组织情况有关，但正如这句话本身一样，其中也蕴含着广泛的经验教训。个人决策总是与资源限制和文化有关，而你的组织可能也面临不同的情况。众所周知，谷歌内部发明了很多东西，而且一直如此。他们的决策过程与我们大相径庭，但据我所知，内部发明对他们来说既是资源问题，也是文化问题。

请在评论中告诉我您的想法！