优秀实践 #1 – 使用抽象层移除依赖项
审查代码库的常见问题之一是开发人员将他们的应用程序代码与他们使用的软件库紧密结合在一起。例如，如果开发人员正在使用 FreeRTOS，他们的应用程序代码会调用特定于 FreeRTOS API 的方式，如果开发人员决定更改他们的 RTOS，他们将不得不重写大量代码来替换所有这些 RTOS来电。你可能会认为更改库很少见，但你会惊讶于团队经常使用一个操作系统、库或组件开始一条路径，只是在他们决定需要进行更改时才不得不返回并重写代码。
团队在选择开源组件甚至商业组件时应该做的第一件事是创建一个抽象层来与该组件进行交互。以 RTOS 为例，团队将使用 OS 抽象层 OSAL，这将允许他们使用独立于 OS 的 API 编写应用程序代码。如果操作系统发生变化，应用程序并不关心，因为它正在访问一个抽象层，而软件更改可能需要几分钟而不是几天。
优秀实践 #2 – 尽可能利用集成软件
大多数开源软件都是在自己的沙箱中编写的，没有过多考虑可能需要与之交互的其他组件。组件通常使用不同的编码标准、风格、测试程度等来编写。如果嵌入式开发人员开始将多个并非旨在相互协作的开源组件组合在一起时，可能会导致长时间的调试会话和错过最后期限，尽可能选择已经集成和测试的组件。
一个很好的例子是使用 Amazon FreeRTOS 连接到 AWS。FreeRTOS 已经与连接到云所需的其他连接库进行了集成和测试，因此不要选择其他库，除非它也已经过测试和集成。另一个例子是许多微控制器制造商生产的代码生成器工具。这些工具通常已经集成了驱动软件组件、RTOS、文件系统、USB 和其他几个组件。它们已经被证明可以一起工作，因此如果可以利用它们，它将节省时间和金钱。
优秀实践#3——执行软件审计和质量分析
有很多很棒的开源软件和很多不太好的软件，在开发人员决定在他们的项目中使用开源组件之前，他们需要确保他们花时间对软件进行尽职调查，这涉及花时间审核组件并执行质量分析，质量往往在旁观者的眼中。
至少，在开始使用开源组件时，应审查源代码：
- 使用圈复杂度测量的复杂度
- 在功能上确保它满足业务需求和目标
- 遵守最佳实践和编码标准(根据需要)
- 处理错误的能力
- 可测试性
至少，这将帮助嵌入式开发人员了解他们正在使用什么，以及潜在的问题和陷阱。
优秀实践#4 – 让律师审查许可证
开源软件许可可能难以驾驭，有十几种不同的许可方案，它们对用户提出了不同的要求。在某些情况下，开发人员可以按照他们认为合适的方式使用开源软件。在其他情况下，可以使用该软件，但任何其他软件也必须是开源的，这意味着它可能需要发布产品的秘方，这可能会损害他们的竞争市场优势。
尽管近年来这些许可证变得更加易于理解，但产品开发人员正在开展业务，因此必须聘请律师来审查软件许可证，以确保一切正常。会有额外的费用，但它是经商成本的一部分，如果发生错误，从长远来看可以节省资金。
优秀实践 #5 – 从活跃的社区中选择软件
快速进行网络搜索或仔细阅读 github 以找到解决问题的软件组件总是很诱人。嵌入式开发人员在选择开源组件时，确保该组件具有活跃的社区非常重要。
例如，使用 FreeRTOS 的开发人员知道他们可以上论坛、提出问题，并且通常会得到快速响应。新版本会定期发布，并且软件始终会随着新功能的添加而不断改进。选择具有不活跃社区的组件可能会导致开发人员独自一人，被迫自己找出问题，或者更糟糕的是，不得不维护该组件。
结论
正确利用开源软件可以极大地使开发团队受益。然而，为了取得成功，开发人员需要确保他们明智地选择他们的开源组件，这包括抽象出组件以确保其应用程序保持灵活和可维护。它还需要仔细审查开源软件，假设它不是 Linux，以确保在提交组件之前满足质量和一般要求。
遵循这些最佳实践可以帮助嵌入式开发团队避免导致产品延迟、架构不佳的解决方案、质量问题以及产品开发过程中经常出现的许多其他问题的泥潭。
