embedded - 固件工程师可以从软件工程师那里学到什么？

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

4年前关闭。




Improve this question




从我对固件工程工具、实践等历史的了解来看，它一直落后于软件工程领域好几年。例如，据我所知，关于 C++ 是否真的值得用于我们的应用程序，固件世界仍然存在相当多的争论，并且一些 C++ 编译器明显不存在(微芯片？!？)。我想这在很大程度上是由于固件和软件之间的要求不同。同样，从历史来看，经过适当审查的工具和技术进入固件世界似乎只是时间问题。

现代软件工程师经常使用哪些方法、工具、最佳实践等，固件工程师还可以利用哪些方法来改进他们的工艺？

具体来说，我正在考虑以下几个方面(但不要让它们限制你):

提高代码清洁度/可维护性

减少缺陷引入和改进检测

改进文档

需求管理

提高可重用性

我也很想看到嵌入式商店的回答或对答案的评论，以提供有关理论可行性的反馈，或者更好的是，个人经验。

更新
我对稍微领先一点特别感兴趣。所以相对较新的东西已经过相当好的审查(对大多数人来说效果很好)，比如 C++、TDD 等。你一直使用什么，喜欢什么？

更新 2
到目前为止，我在答案中得到了很多很好的通用编程建议，这很好，但我真的在寻找更多已经证明对人们成功的非常规方法。我正在尝试梳理敏捷实践者、TDD 人员以及其他尝试过一些东西并看到它获得成功或惨遭失败的人。作为一名软件工程师，您在过去几年中采用的工具或实践是否产生了显着的积极或消极影响？

Answer 1

固件工程师可以从软件工程师那里学到什么？很多!

我很惊讶今天的固件开发与 25 年前我们第一次开始使用 C 进行嵌入式开发时的相似。 C 是汇编语言向前迈出的一大步，但固件工程师可以而且应该从中吸取更多经验教训。是的，有些工具更好，但许多实践停留在​​ 70 年代和 80 年代。

除了非嵌入式开发人员面临的挑战之外，嵌入式软件开发确实增加了一些额外的挑战。但是熟练的软件开发人员使用的所有原则和实践都适用于嵌入式开发。顺便说一句:不仅仅是嵌入式软件开发人员没有掌握这些最先进的实践，许多非嵌入式软件开发人员也是如此。

我认识和遇到的做固件的人总的来说是一个非常熟练的团队，致力于解决难题。不幸的是，无论出于何种原因，许多人没有跟上软件世界的发展。我认为这与固件工程师建立的假想障碍有关。

嵌入式和非嵌入式开发人员使用不同的语言，但解决的问题相似。保持嵌入式代码独立于硬件设备与保持应用程序代码独立于 UI 或数据库本质上是一样的。基本原理是相同的。

以下是我认为嵌入式开发人员应该多加注意的几件事。其中一些原则和实践可以立即使用，而其他原则和实践可能需要稍作调整以应对嵌入式挑战。如果你想用固件这个词代替下面的软件，请继续，我并没有真正区分这两者。

依赖管理

必须管理模块之间的依赖关系。从软件到硬件的依赖性是一种特殊情况，必须由嵌入式软件开发人员积极管理。如果您不管理依赖项，它将管理您。

实际上，这意味着只有有限的软件模块子集应该了解底层硬件(和操作系统)。随着硬件的发展，它总是如此，可以保留对硬件独立代码的投资。
请参阅我的 ah ha! 时刻。

Robert Martin 撰写了大量关于 SOLID 设计原则的文章。嵌入式开发人员应该了解它们并将它们应用到他们的设计中。

S-单一责任原则

O-Open 封闭原理

L-Liskov 替换原则

I接口(interface)隔离原则

D-依赖倒置原理

这些原则导致设计更经得起时间的考验。 SOLID 原则鼓励创建有凝聚力和独立的模块。它们建立在面向对象的思想之上，但可以应用于 C。我们必须停止在嵌入式 C 代码中太常见的函数调用数据结构。

C++ 和 OO 语言

为什么不能使用 C++ 和 OO？因为它们太慢了，或者太大了。事实是什么？ C++ 是一种庞大而神秘的语言，但您不必全部使用它。看看Why are you still using C?

C++ 弥补了一些 C 没有太大帮助的问题，例如:

封装和信息隐藏

接口(interface)编程

可替代对象

临时初始化

C++可以有效地用于嵌入式开发。好吧，您确实需要一个 C++ 编译器和空间。也许这在你的世界里是不可能的，或者这可能是做生意的成本。从学习开始:

类 - 这些是具有成员函数和成员数据的结构。

构造函数 - 这些使初始化正确成为可能，一直。

析构函数 - 如果你学习了构造函数，你还必须学习析构函数来保持宇宙的平衡。

继承 - 主要用于定义仅包含纯虚函数的接口(interface)。接口(interface)提供了重要的依赖中断和灵活性点。这些在嵌入式中通常是不公正的。这里不应该有任何神秘或偏见；虚函数是引擎盖下的函数指针。有效使用接口(interface)的替代方案是复杂的条件逻辑，嵌入式 C 程序通常有太多的东西。

如果嵌入式开发人员使用 C++ 的这些部分，他们可以构建更灵活的设计，而不会产生高成本。

测试驱动开发

这可能是最大的游戏规则改变者。我很高兴看到其他帖子也提到了它。 TDD 可以帮助预防现在和将来的缺陷。要了解为什么 TDD 可能会有所帮助，请查看 The Physics of TDD 。

嵌入式确实给 TDD 带来了一些独特的挑战。例如，TDD 需要极快的增量编辑/编译/链接/运行周期。对于许多嵌入式开发人员来说，这意味着仔细的依赖管理和首先在目标上运行单元测试。查看更多关于 adapting TDD for Embedded 的信息。

使用 TDD，您正在创建经过彻底测试的代码。全面的自动化测试覆盖范围充当安全网，允许随着需求的变化安全地更改代码。意外的后果会立即被发现。

此外，通过 you get almost for free 的测试，您可以无所畏惧地重构代码......

持续重构

代码编写一次，但阅读多次。然后它被改变和调整，导致设计随着时间的推移而退化。如果开发人员不不断重构以保持代码干净，它就会变成一团糟。也许你们中的一些人正在处理那些烂摊子。 TDD 的自动化测试支持低成本和低风险的重构。

持续集成

自动化您的构建过程。让它在每个工作区 checkin 时运行。对于将编译后的代码输入到目标中通常需要的异构工具集来说，这是一个挑战，但它仍然是正确的目标。

嵌入式开发人员越早知道某个更改在某种程度上与其他工作不兼容，修复的速度就越快，并且花费在痛苦合并上的时间就越少。

增量交付

找到拆分工作的方法，这样就可以避免大量痛苦的集成，并且可以尽早尝试设计想法。避免沿着架构线 split ，专注于提供可见功能的切片。

合作

嵌入式开发人员!离开那里的立方体并一起工作。当您只看到自己的代码时，如何变得更好？当你是技术 XXX 的专家，已经掌握它并且没有机会在不同领域工作时，你如何改进。

那里有很多东西要学习。你有责任尽你所能吗