及时交付嵌入式软件的最大障碍之一是代码的结构质量。嵌入式开发项目中的代码质量通常在开始时还不错，但是当团队急于尽快实现功能时，质量会迅速下降。以两个团队为例：

　　l 团队A专注于快速实现特性，很少关注结构化代码的质量

　　l 团队B关注结构质量，不太强调快速交付。

　　随着时间的推移，交付的功能数量可能如下图所示

　　在项目开始时，团队A似乎是英雄，他们快速实现和交付特性，超过了团队B。然而，团队A的低结构代码质量很快妨碍了他们交付更多特性。每一个新特性都需要花费更多的时间和巨大的努力来实现。结果，团队A停滞不前，因为每次添加新功能时，他们都会陷入大量的调试活动中。

　　另一方面，B队虽然看起来起步较慢，但却稳步前进。随着时间的推移，他们花在调试和处理代码结构上的时间越来越少。与团队A相比，他们最终会达到生产力和成本拐点。团队B继续前进，创造新的功能，这导致了两个团队之间的功能差距。

　　你希望你的团队表现得像团队B，而不是团队A。评估你的代码质量可以而且应该在整个嵌入式开发过程中进行。这里有三个评估嵌入式软件代码质量的技巧。

　　技巧1——分析你的软件依赖性

　　高结构代码质量的一个特点是软件的高内聚和低耦合。内聚力指一个模块内部的元素属于一起的程度。高内聚意味着模块中的一切都支持模块在软件中服务的功能，仅此而已。例如，一个USART模块也不会支持CRC。虽然CRC可能用于传递给USART外设的串行数据，但计算CRC不属于USART模块。

　　耦合是软件模块之间的相互依赖程度;紧密相连的两个模的度量。模块之间的耦合度越高，依赖性就越大。在具有高结构质量的软件中，软件模块具有最小数量的依赖性。低耦合是高结构质量的标志。模块耦合得越紧密，一个模块中的变化对另一个模块的影响就越大。如果一个团队不小心，他们的软件结构可能会变成一个“大泥球”。

　　大泥球

　　通过对软件进行依赖性分析，很容易识别出一大团泥巴。下面是一个大泥球的例子:

　　分析相关性

　　嵌入式开发团队在开发软件时应该分析他们的软件架构和相关性。如果他们这样做了，他们就可以在早期识别潜在的耦合问题，并在它们演变成问题之前解决它们。

　　技巧2——测量函数长度

　　评估代码质量的一个简单方法是测量代码库中每个函数的长度。从统计上看，大型函数包含bug的概率更高。在许多情况下，长函数表明该函数不符合单一责任原则!每个功能应该只做一件事，并且只负责做一件事。(注意:这个原则通常应用于类或模块级别，但在C中，它也可以应用于函数级别)。

　　大型函数通常做得太多，这表明代码质量存在潜在问题。分析代码可以指出潜在的问题。例如，在下图中，你可以看到示例代码库中最大的函数和文件。代码中最重要的函数有5000多行代码(LOC)!另一方面，有一个接近18,000 LOC的模块!

　　每个功能的LOC度量可以识别在分析代码库时可能存在问题的模块。当识别出这样的代码时，它们是高优先级的函数、文件和模块，需要重构并分解成更有意义的单元。例如，一个5000行的函数可能被分解成50个更清晰、更易维护的辅助函数。但是，像这样的大型函数通常几乎无法测试!

　　技巧# 3——每个代码单元都应该有测试

　　测试，尤其是单元测试，对于确保代码的高质量至关重要。嵌入式开发人员测试验证该功能是否满足该功能应该做什么的要求。如果你没有对你的函数进行测试，那么你就没有办法验证该函数是否做了它应该做的事情!此外，当代码更改时，没有办法知道你是否破坏了任何东西，除非有测试来验证该函数仍然按预期运行。

　　测试可以是代码结构质量的最大指示器。这是因为在编写单元测试时，开发人员经常被迫管理依赖关系，最小化耦合，抽象他们的接口，并执行许多其他最佳实践。因此，结构质量低的代码通常难以测试。相反，具有高结构质量的代码易于测试。

　　评估代码质量结论

　　结构化代码的质量可以与团队是否能在预算内按时交付软件联系起来。高结构代码质量将导致一致的特性交付，实现高质量的结构化代码不是偶然发生的事情，团队必须建立过程和程序来评估和监控他们的软件。质量问题更容易处理，因为它们发生了，而不是等到项目结束时，最简单的事情就是重新开始。(这通常会导致同样的问题再次出现)。

　　在今天的文章中，我们探讨了如何衡量代码质量的三个容易实现的技巧，如果你从这些技巧开始，你就能理解在嵌入式开发过程中你的嵌入式软件中的缺陷和潜在问题。一旦你能看到并理解，只有这样你才能开始你的行动计划来提高你的软件结构质量。