c - C中常见的代码重用策略是什么

Question

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

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

到目前为止我发现了两种可能性：

• 静态库
• 颠覆中的共享文件

Answer 1

共享库和共享源都允许您在项目之间共享公共代码。库提供了两种选择中的更好的选择，因此如果它们在您的平台上可用，您应该使用它们。这使您可以保护库的源代码免受意外修改，如果源代码控制中的代码在本地更改，则可能会发生这种情况。

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

Answer 2

如果您有可重用的组件，那么库是您的最佳选择。

1. 它更易于维护，并且您拥有清晰的界面。它也更容易融入新项目。
2. 您可以轻松地对库代码进行单独的单元测试
3. 复制和粘贴代码的风险较小。
4. 程序员更清楚，当他们必须从库中使用此代码时，它们是共享的。

Answer 3

图书馆的方法有几个很好的论据。

但是，每次构建依赖项目时，至少有一个很好的论据可以重新构建（可能来自同一个源存储库），那就是能够将目标项目或开发阶段唯一的编译设置应用于所有代码，包括共享部分。

Answer 4

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

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

这样您就可以两全其美：

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

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