With clones of open source projects one of your biggest headaches will be keeping in sync/patched according to the upstream sources. You might not care about new features, but you will sure need critical bug fixes applied.
My suggestion would be to carefully wrap such inner projects into shared libraries, so you can more or less painlessly upgrade just those parts if the ABI is not broken by the changes.
One more thing - if you find and fix bugs in an open source project - don't keep the fixes to yourself. Push the patches upstream. That will make the project better and will save you days of merging with a new version.
Make as few changes as possible to the third party libraries. Try and get around their limitations within your code. Document your changes and then submit a patch.
If you can't get around their limitations, submit your change as a patch (this may be idealistic with the glacial pace of some projects).
If you can't do either of those things, document what you've changed in a centralized location so that the poor person doing the integration for new versions can figure out what the heck you were doing, and if the changes made are still needed.
1 and 2 are greatly preferred (however, fast and very slow respectively), while the third option will only lead to headaches and bugs as your code base deviates from the dependencies' code base. In my code, I don't even have the 3rd party code loaded up in the IDE unless I have to peruse a header file. This removes temptation to change things that aren't mine.
As far as modularity, and this is assuming you are using relatively stable 3rd party libraries, only program to the public facing interface. Just because you have the source doesn't mean you have to use it all over your code. This should allow updates to be essentially drag and drop. Now, this is completely idealistic but its what I strive for with code I work on.
发布评论
评论（2）
对于开源项目的克隆，您最头痛的问题之一将是根据上游源保持同步/修补。您可能不关心新功能，但您肯定需要应用关键的错误修复。
我的建议是仔细地将此类内部项目包装到共享库中，这样，如果 ABI 没有因更改而破坏，您就可以或多或少轻松地升级这些部分。
还有一件事 - 如果您发现并修复开源项目中的错误 - 不要将修复保留给自己。将补丁推向上游。这将使项目变得更好，并为您节省与新版本合并的时间。
With clones of open source projects one of your biggest headaches will be keeping in sync/patched according to the upstream sources. You might not care about new features, but you will sure need critical bug fixes applied.
My suggestion would be to carefully wrap such inner projects into shared libraries, so you can more or less painlessly upgrade just those parts if the ABI is not broken by the changes.
One more thing - if you find and fix bugs in an open source project - don't keep the fixes to yourself. Push the patches upstream. That will make the project better and will save you days of merging with a new version.
按优先顺序
1 和 2 是首选（但是分别快和慢），而第三个选项只会导致头痛和错误，因为您的代码库偏离了依赖项的代码库。在我的代码中，除非我必须仔细阅读头文件，否则我什至没有在 IDE 中加载第 3 方代码。这消除了改变不属于我的东西的诱惑。
就模块化而言，假设您使用相对稳定的第三方库，仅对面向公众的接口进行编程。仅仅因为您拥有源代码并不意味着您必须在整个代码中使用它。这应该允许基本上通过拖放进行更新。现在，这完全是理想主义的，但这是我为我所编写的代码所努力的目标。
In order of preference
1 and 2 are greatly preferred (however, fast and very slow respectively), while the third option will only lead to headaches and bugs as your code base deviates from the dependencies' code base. In my code, I don't even have the 3rd party code loaded up in the IDE unless I have to peruse a header file. This removes temptation to change things that aren't mine.
As far as modularity, and this is assuming you are using relatively stable 3rd party libraries, only program to the public facing interface. Just because you have the source doesn't mean you have to use it all over your code. This should allow updates to be essentially drag and drop. Now, this is completely idealistic but its what I strive for with code I work on.