图书馆悖论

我最近开始了一些新项目，并且面临很多引导工作。 交易技巧，例如将环境变量有效地加载到运行时中，或将常见的设置汇总在一起进行测试，都需要付出很多努力。

为无服务器计算开发微服务或什至更小的东西，最终会得到许多小的独立代码库。 有一个难题：

• 一遍又一遍地写相同的代码
• 用一些与它们有关的巨大的整体式数据库膨胀代码

这是您所看到的两难境地……不过，这是一个隐藏的问题。

图书馆很棒，直到没有

两个单独的服务并不意味着共享代码。 如果您不能以一种比以往更好的方式保证库之间的接口，那么您将输入所有依赖关系，它们都是由相同版本的代码构建的 。

因此，在考虑跨服务共享库时，您必须考虑一些我们没有想到的缺点：

• 不相关服务之间的耦合是什么？
• 使服务与共享关注点保持同步的构建过程是什么？
• 这个共享库的代码膨胀效果是什么？
• 图书馆的维护者会关心使用图书馆的服务吗？
• 在每个用例的基础上，这种通用代码是否比更简单，更具体的代码更好？
• 这个图书馆会最终成为不相关功能（ 功能磁铁）的垃圾场吗？

所以没有任何图书馆吗？

这似乎是一个荒谬的前景。 如果您有经过深思熟虑的组件可以解决常见问题，那么编码将越来越像附加乐高积木一样。 我们想要那种效果。 相关时。

图书馆的成功标准是什么？

如果您拥有庞大的整体架构，则可以使用库-它们易于管理，您可以将它们全部干燥。 这是一个很好的模式。

如果您要创建一个梦幻般的自包含，可维护，可重用的库。 以开源项目的方式进行。 那太好了 您将组成一组可靠的接口和流程来保持其正常运行。 您将拥有一个出色的库，并且可以对其进行维护和控制。

如果要在相关模块之间共享一些本地技巧，则：

• 模块化–使库成为单一用途
• 确保消费者是本地人
• 很好地记录它，好像它是一个更大的库
• 在变得过于多样化/纠缠之前停止
• 避免将服务业务逻辑放入库中

何时粘贴/叉

我们在另一个项目中做到这一点的方式很棒！

如果您觉得自己拥有所需的库，但该库已在另一个项目中使用，则除非可以将其提升为组织的全局库，否则最好将其派生或复制/粘贴所需的代码。

听起来不对。

但是库有其自己的轨迹，如果不能保证所有使用者之间的关系，则不应基于一些巧合的相似代码来构建链接。

翻译自: https://www.javacodegeeks.com/2020/04/the-library-paradox.html