C++ 关于保持大型C++；项目模块化？

我们的团队正在进入规模更大的项目，其中许多项目使用了几个开源项目

有什么建议或最佳实践可以使库和依赖项相对模块化，并且在发布新版本时易于升级

换句话说，让我们假设您制作了一个开源项目的分支程序。随着这两个项目的发展，维护和共享核心更新的最简单方法是什么

---

关于我只想问的问题，请给我一些建议……我不需要“你应该这样做”或“你为什么这样做”。谢谢。

对于开源项目的克隆，你最头疼的问题之一就是根据上游来源保持同步/修补。您可能不关心新功能，但您肯定需要应用关键的bug修复

我的建议是小心地将这些内部项目包装到共享库中，这样，如果ABI没有被更改破坏，您就可以或多或少地轻松地升级这些部分

还有一件事——如果你在一个开源项目中发现并修复了bug——不要把修复工作留给你自己。把补丁往上游推。这将使项目变得更好，并将节省您与新版本合并的时间。

按优先顺序排列

对第三方库进行尽可能少的更改。尝试在代码中绕过它们的限制。记录您的更改，然后提交修补程序

如果你不能绕过他们的限制，就把你的更改作为补丁提交（这可能是理想主义的，因为有些项目的进度缓慢）

如果你不能做这两件事中的任何一件，请在一个集中的位置记录你所做的更改，这样做新版本集成的穷人就可以知道你到底在做什么，以及所做的更改是否仍然需要

1和2是最好的选择（但是，分别快和慢），而第三个选项只会导致头痛和错误，因为您的代码库偏离了依赖项的代码库。在我的代码中，我甚至没有在IDE中加载第三方代码，除非我必须仔细阅读头文件。这消除了改变不属于我的事物的诱惑

---

就模块化而言，这是假设您使用的是相对稳定的第三方库，只有面向公众的接口的程序。仅仅因为你有源代码并不意味着你必须在你的代码中使用它。这应该允许基本上拖放更新。现在，这是完全理想化的，但这正是我所致力于的代码。

我所在的一家公司多年来一直使用不受支持的Bugzilla旧版本，因为相对较小的更改无法与上游更改完全合并。没有人有时间去解决它。当然，如果我们需要上游的变化，我们会找到时间，但故事的寓意是，如果你分叉，那么你最终会遇到一个“不容易升级”的情况。与其试图避免这种情况发生，不如尽量减少这种情况发生的频率。我认为这属于Programmars.SE，但由于它太旧了，不允许迁移，我只是投票关闭它。+1支持包装-最好自己包装所有依赖项。+1建议推后补丁：即使你不想共享，我想你以后会在自己的补丁上得到社区的支持，所以没有理由不这么做。我也会说+1代表包装。。。但我不能投两次票。无论如何，包装第三方软件是一件轻而易举的事（至少对于经典代码来说，纯模板代码更难）。包装允许您在一个地方适应接口更改，而不让它影响整个公司代码库。最后，与所有中间件活动一样，您最好确保获得一些好的开发人员来处理它，因为它将被广泛使用，您不希望它出现错误。