停止解决已解决的问题：摆脱重复代码的循环

Source: Dev.to

这是一种每天在无数办公室和家庭办公环境中上演的情景：一名软件开发者盯着一个棘手的问题，捏捏指关节，开始在脑海中构思解决方案。他们设想模块、API，以及能够斩龙的优雅代码。几天，甚至几周后，他们带着一个可工作的方案出现，为自己的创作感到自豪，却发现（或被同事指出）已有开源库或内部工具已经实现了完全相同的功能。

有时现有的工具甚至比开发者自己构建的更好。

这种现象是业界流传已久的笑话的来源：“每当开发者遇到问题时，他们就开始构建解决方案，完全忽视了它已经存在。”虽然这很搞笑，但背后的现实是一个代价高昂且令人沮丧的重复工作循环。这是一个多方面的问题，根源于心理、企业文化，有时还因为缺乏培训。它常被贬义地称为 “Not Invented Here” (NIH) 综合征。

“自豪地在别处找到”的案例

这种重复的成本惊人。它不仅是浪费的开发时间；更是维护多个略有差异的同一实现的复合成本。每一次 bug 修复都必须在多个地方应用。每一个新开发者都必须学习多个系统。随着时间推移，软件生态系统变得臃肿且脆弱。

向 “自豪地在别处找到” 的文化转变是必不可少的。这种思维方式把解决业务问题置于亲自编写每一行代码的满足感之上。它认识到，站在巨人的肩膀上——无论是开源维护者还是隔壁楼的团队——都能实现更快的交付、更高的质量以及更可持续的软件。

如何打造“自豪地在别处发现”文化

克服 NIH 综合症需要个人和组织的有意识努力。

对组织而言：构建一个市场，而非黑洞

• 让代码易于查找且易于使用。
• 投资内部组件市场，让团队能够发布带有清晰文档、使用示例和版本管理的库。
• 培养协作文化，鼓励团队讨论技术挑战并分享解决方案。

对组织而言：激励复用

• 改变衡量标准。
• 奖励为内部库作出贡献的工程师以及选择复用这些库的工程师。
• 庆祝因利用现有组件而更快交付且缺陷更少的项目。

对开发者而言：在问“怎么做？”之前先问“为什么不？”

• 在为常见问题（例如日志记录、身份验证、数据校验）编写任何代码之前，养成搜索已有解决方案的习惯。
• 向同事请教，查阅公司 Wiki，并寻找开源库。
• 假设已有解决方案，除非你能够证明不存在。

对开发者而言：贡献而非分叉

• 如果已有库已覆盖 80 % 的需求，避免从头构建剩余 20 %。
• 考虑将缺失的功能贡献回原项目，或通过插件进行扩展。
• 改进已有工具几乎总比创建一个需要永远维护的新工具更好。

微妙之处：何时重新发明是正确的选择

重新发明轮子并不总是坏事；有时它会带来创新。正如开发者 Lea Verou 所指出的，使用一个庞大且臃肿的库来实现其极小一部分功能，可能会导致显著的性能开销和长期的维护成本。如果你只需要 5 % 的库功能，编写一个小型、专用的函数实际上可能是更明智的选择。

例如，解析几行简单的 Markdown 来处理粗体文本和链接，并不一定需要一个 1,700 行的库。一个小的自定义函数可能更高效，且复杂度更低。

关键在于有意为之。目标是避免偶然或傲慢的“重新发明轮子”——那种因为开发者没有查找、没有询问或根本不在乎而产生的情况。通过将关注点从“创造的自豪感”转向“高效解决实际问题的满足感”，我们可以摆脱这种代价高昂的循环。

我们应该同样庆祝找到完美的现有解决方案，就像庆祝从头构建一个全新方案一样。