代码共享的陨落：为什么说内部库是反模式？

问题在于，多数的提议都是建立在“共享代码能提高开发效率”这一谬论上的。考虑到共享的代码或资源常常会被视为系统设计中的瓶颈，为什么人们还是如此热衷于代码共享呢？

共享的库会造成团队间的耦合，影响工程设计的效率。应用程序可能会被间接地绑定到特定版本的依赖项中，从而导致各种令人头大的兼容性问题。不认真仔细地进行管理，破坏性改动或回归都可能会带来严重的后果。

代码的复用与耦合之间需要权衡，手动复制粘贴代码或许是一种解耦机制，如此一来应用程序得以按不同的速度发展，代码的稳定性也能有提高，因为应用程序不用再吸收共享依赖关系中的更新。

代码共享不总是件坏事，有些情况下内部共享库是能够带来价值的。举例来说，前端开发人员常常用共享库实现系统设计，在不同应用程序之间实现统一的观感。

很多共享库的目的并不总会非常明确，尤其是项目名称中的“common”、“utility”，或者“helper”关键词。这些通用库的职责总是模糊不清的，很难长期保持清晰的界限。再加上“通用”这些术语的主观意义，工程师们往往会把这些库当作是任何可能在未来复用的功能的垃圾堆放场。

通用库往往会重新实现语言功能或是解决已解决的问题，比如身份验证、序列化、数据的访问和加密。通用库不仅会带来不必要的维护负担，还会在代码中引入陌生的函数调用，增加新使用者的学习难度。

其他内部库也不过是第三方依赖关系的无用包装。这些库存在的理由往往是更易于修改底层依赖关系，但这在实践中并不会真的发生。多数的封装最终都会掩盖接口、限制底层功能，却不会增加任何有价值的功能。

另一类常见的内部库是以“最佳实践”的形式出现。通常是一组工程师试图用自己的观点限制其他工程团队的代码实施，其中隐含的信任缺乏正是不健康的工程文化标志。

一个库的干涉性和意见性越强，其实用性就越低。定义了“最佳”模式的库会束缚住工程师的手脚，造成代码实现之间不健康的耦合。多数情况下，我们可以通过示例来鼓励“最佳实践”，而不是试图将这些抽象到一个库里。

此外，还有一些库则是实现了服务之间的共享领域数据和业务逻辑。这些库模糊了应用程序的边界，并通过共享的模式产生了耦合。对共享的领域库修改，最终会对依赖它们的各类应用程序产生不可预测的影响。一般来说，最好的办法是复制粘贴共享的领域数据，将其作为单独的服务实现，或者是重新考虑服务的边界线。

共享库的最大问题在于它们不仅编写困难，维护起来也是不简单。共享库往往缺乏实质性的需求，这也更是增加了设计和测试的难度。

为代码复用而开发是需要特定的技能，并具备设计模式相关的知识，这些在工程团队中并不常见。只有经验丰富的人才能正确地把握抽象的成都，避免组件过于具体无法通用，或过于笼统而无法增加任何实际的价值。

与其他代码库一样，共享库会随着时间的推移而产生熵值增加，也是需要花功夫进行维护。多数组织的代码库中都会潜藏着一些不受欢迎的共享库，光是维护依赖关系的更新就已经足够挑战，更不用说还要根据不断变化的系统环境发展新功能了。

为共享库的维护腾出足够的工程资源并不简单，尤其是在工程团队围绕系统或商业垂直领域构建的情况下。这就导致了共享库被忘在脑后，最初的激情消退后，共享库就再没人去维护了。

常年没人维护的库往往会变成“孤儿库”，就算没有，它们也会依赖于一小部分热衷开发工作的工程师，而这些工程师们则可能会将开发工作倾向于非常狭隘的利益。

内部源码的方式可以帮助建立以社区为驱动的代码共享方式。不过这也只在大批拥有开源社区工作经验的熟练工程师共同工作的情况下才有可能成功。即使如此，最终你还是躲不过分配资源到共享库的设计、构建和维护中。

无论开发的工作是如何安排的，共享库都需要有明确且一致的领导。你需要有人能来确保共享库的重点维持在主要的目标上，代码在一定程度上保持健康的状态。

或许你还需要一定的管理，协助确立什么才应该被“共享”。这方面的形式有很多，但合作总是比“自上而下”的管理和强制库有更高的吸引力。衡量共享库成功与否的指标之一就是工程团队自发采用共享库的程度，换句话说，共享的库是否真的能让开发人员的生活更轻松。

成功的共享库往往都具备某些特征。它们的规模往往不大，关注的范围很窄，也更容易保持关注重点并长期维持边界。它们会有管理良好的代码基础架构，其中包含测试组件，便于避免回归或意外出现的破坏性变动。它们也会有高效的构建和发布自动化，支持新增代码的轻松集成。此外，成功的共享库还应该具有清晰一致的文档，让库更易于采用。

最重要的是，组织内部要能够承诺有足够的时间用于持续开发，如果不能做到这一带你，那么内部的代码库就很难创造任何真正的价值。

原文链接：

The shared code fallacy: Why internal libraries can be an anti-pattern（https://www.ben-morris.com/the-shared-code-fallacy-why-internal-libraries-are-an-anti-pattern/?accessToken）

声明：本文为 InfoQ 翻译，未经许可禁止转载。