提问人：Jagerber48 提问时间：3/9/2023 更新时间：3/9/2023 访问量：215
我想在我开发的多个包/项目中使用的小实用程序函数放在哪里？
Where to put a small utility function that I would like to use across multiple packages/projects that I develop?
问：
现在，我有一个函数在我处理的许多不同的包中很有用。该函数只有几行。但是我希望能够在我工作和部署的许多包/项目中使用此代码，我希望此代码受到版本控制等。例如，没有一个包是所有其他包都已作为要求的，否则我可以将此代码放在该包中并以这种方式导入它。
在我编码期间，我遇到过几次这个问题。具体而言，具有此特征的一些函数可能是：f
- 包装器或上下文管理器，它使用一些日志语句对代码块进行计时
- 将一系列整数划分为少量均匀间隔步幅的函数，同时不超过最大步数
- 将中心值和跨度转换为下限和上限的函数
基本上我看到的选项是：
- 将代码放在一个现有包中，然后将任何想要使用的包作为要求。这里的缺点是，除了在这种情况下，大多数要求都是浪费的，否则可能不需要任何东西。
fRAfRARf - 将代码复制到每个需要它的包中。随之而来的一个问题是，应该住在哪里？因为功能确实超出了包的范围。这是一个小问题，更大的问题是，如果对一个包进行改进，那么在多个包中保持一致性将具有挑战性。
fAfAfAff - 我可以制作一个专用于以下功能的整个包，并将其导入到每个需要的包中。从需求管理和责任分离管理的角度来看，从技术上讲，这似乎是最好的方法。但就像我说的，现在这将是一个完整的包，专门用于一个功能，只有几行代码。
Fff - 如果有一个 stdlib 函数具有我想要的功能，我绝对应该使用它。如果没有，我也许可以找到具有我想要的功能的第三方软件包，但这会带来我宁愿避免的其他潜在问题。
建议的方法来做到这一点？还有其他我没有提到的方法吗？
答：
3赞
hexbioc
3/9/2023
#1
整个打包系统就是为了解决这个问题而设计的——在不同应用程序之间共享代码。所以，是的，理想情况下，您希望从中创建一个包，并将其作为依赖项添加到使用此代码的所有其他包中。此选项有几个好处：
- 包管理是干净的
- 将来的存储库也可以包含此代码
- 对此代码的任何更改仍可以通过适当的版本控制和版本固定进行处理，因此不会破坏其他位置的代码
- 将来，这些函数等可能会被添加到这个包中，从而允许你跨包共享它们
f2f3
但这也带来了一些（潜在的）缺点：
- 现在，您必须维护一个额外的包，包括其部署管道和版本控制 - 但是，如果已经有管道，这应该不会太麻烦
- 每当引入重大更改时，管理不善的版本控制都可能导致系统很快崩溃 - 这通常更难跟踪
话虽如此，将代码复制到使用的每个包的选项仍然是一种选择。请考虑以下几点：f
- 通常，随着时间的推移，这样的代码也会进行调整，以使其适应父包的要求，在这种情况下，在包之间共享它不再有意义 - 并且试图泛化它往往会导致糟糕的抽象。如果您担心遵守 DRY，请查看 Dan Abramov 在 WET 代码库上的演讲'
- Regarding maintaining uniformity - you may not have to do so all the time, depending on the usecase. Package could be using updated code, while package could be using the older one. Regardless, whatever approach you use, you'd still need to update every package to maintain uniformity - for example if you go with a dedicated package, you'd still need to update the version used everywhere.
AB - Regarding where this code will reside in each package's codebase - If does something very specific, it can reside in an appropriately named file of its own. If nothing else, there is always the notoriously overused ¯\(ツ)
futil.py/¯
Recommendation
- Begin with copying over the code to all packages. Update them individually as required in every package.
- Over time if you observe that any updates to is being propagated to all other packages every time, then put in a package of its own and replace the code in the other packages with an import from this new package.
ff - Finally, don't fret the small things. Most things in software are reversible. Pick one approach and change it to the other if it does not workout. Just remember to not drag the decision - delay too much and you'd be left with a huge mountain of tech debt over time.
PS: Someone may recommend using a git submodule for sharing this code - DO NOT do it, managing versions isn't clean and will soon get out of hand - you'd rather just create a new package instead
评论
0赞
Jagerber48
3/9/2023
Accepted. Especially for the advice for a strategy over time and not just for right now. To stop spending time thinking about it I will probably just copy the code into a utils module in each package that uses it for now. And like you suggest I’ll package or something if it looks like that would really be useful/needed down the road.
评论