C中的公共代码重用策略是什么？

Question

上下文：C语言，8位微处理器

我们已经确定了可以在项目（产品）之间重复使用的组件。但我找不到哪个是处理可重用组件的最佳基础设施。

我发现的两种可能性：

• 静态库
• subversion中的共享文件

Answer 1

共享库和共享源都允许您在项目之间共享公共代码。库提供了两种替代方案中的更好，因此如果您的平台上可用，则应使用它们。这使您可以防止无意修改库的源代码，如果来自源代码管理的代码在本地更改，则可能会发生这种修改。

通过库共享代码的唯一问题可能是缺少对嵌入式工具链中某些工具（例如，连接到在线仿真器的调试器）的库代码源代码级调试的支持。在这种情况下，通过源重用代码是可以接受的。如果可能，您应该通过文件系统访问控制保护源不被修改。

Answer 2

如果您有可重用的组件，那么可以使用库。

1. 维护起来比较容易，界面清晰。它也更容易融入新项目。
2. 您可以轻松地对库代码进行单独的单元测试
3. 复制和粘贴代码的风险较小。
4. 程序员更清楚这些代码在必须从库中使用时才会被共享。

Answer 3

对图书馆方法提出了几个好的论据。

但是，每次构建依赖项目时，至少有一个很好的理由可以重建（可能来自相同的源代码库），这就是应用目标项目的能力 - 或开发阶段 - 对所有代码的唯一编译设置，包括共享部分。

Answer 4

在我的公司，我们同时使用这两种方法：

• 我们做两个结账：一个用于项目，另一个用于图书馆。
• 当需要编译项目时（通过Makefile），我们首先编译库。
• 然后将库链接为好像它只是一个二进制库。
• 当我们发布项目时，我们会检查其他项目是否仍然针对新库进行编译。
• 当我们发布项目时，我们会将该项目与项目一起标记。

通过这种方式，您可以获得两全其美的效果：

• 共享公共代码：所有项目都可以从错误修复和改进中受益
• 源代码始终完全可用于理解和调试
• 源代码可用性鼓励图书馆维护（修复，改进和实验）
• 库边界强加了一种更像API的方法：更清晰的界面和项目嵌入
• 您可以将编译时标志传递给库以构建不同的风格
• 如果没有图书馆与项目不匹配的麻烦，你可以随时回到过去。
• 如果你赶时间，你可以推迟图书馆检查。

这种方法的唯一缺点是开发人员不知道他们在做什么。如果他们修改了库，他们应该知道更改将对所有项目产生影响。但是你已经在使用版本控制系统了，如果你使用分支机构并且团队内部的沟通很好，那么应该没有任何问题。