本文主要是介绍书摘：C 嵌入式系统设计模式 01，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
本书的原著为：《Design Patterns for Embedded Systems in C ——An Embedded Software Engineering Toolkit 》，讲解的是嵌入式系统设计模式，是一本不可多得的好书。
模式 ，英文为 pattern，指的是在软件开发中，经过长期实践和经验积累形成的一种解决特定问题的标准化方法或方案。这些模式是在反复出现的情境下，通过总结和抽象化得出的最佳实践，它们提供了一种通用的设计词汇和一种通用的语言，以方便开发人员之间进行沟通和交流，使得设计方案更加通俗易懂。
为什么会有各种介绍模式的书？
通过总结和抽象化得出的各种设计模式，可以帮助开发人员更加简单方便地复用成功的设计和体系结构，以提高软件的开发效率和软件质量，在一定程度上节约设计成本。同时，这些模式还有助于初学者更深入地理解面向对象思想，方便阅读和学习现有类库与其他系统中的源代码。
本系列描述我对书中内容的理解。如果你想买这本书进行学习，我的建议是不要买中文版！！！你可能听劝或者不听劝，都没有关系，这不是什么大事。你只需记着，如果读中文版一头雾水、读不下去，那不是你的问题，试试英文原版。
软件开发的真相之一是，协同开发必然伴随着重建。
当两个或多个组织、公司共同开发时，我们称之为 协同开发 。协同开发之路困难重重，良好的规格说明和硬件原型等手段，能够缓解其中的部分困境，但意料之外的挑战和需求仍会不可避免地出现。这就需要我们反复修正原始设计，不断适应和应对。
我们要直面这一现实，并在协作过程中保持充分的沟通。设定短期目标，经常交付可以工作的软件，然后积极听取反馈，一步步进行迭代。只有这样，我们才能在协同开发的过程中不断前行，逐步攻克难题，最终实现我们的目标。
普鲁士将军 von Clausewitz 写道：“战争中的一切都很简单，但最简单的事情也非常困难。” 对于软件开发，他也可以这样说！
军队中的一切事务，根本上非常简单，似乎很容易管理。然而，我们必须牢记，其构成并非简单的整体，而是由众多个人组成的各个部分。这些部分中蕴含着无数无法预见的小事件，它们相互交织，降低了整体表现水平，结果人们总是远远达不到预期的目标。对于没有战争经验的人来说，这一切的复杂性是难以想象的。
对于软件来说，最困难的不是编写软件，而是编写具有正确功能的软件。
开发无缺陷软件的最新技术是一种称为
测试驱动开发(TDD) 的敏捷实践。
无缺陷的软件 （defect-free software）表示该软件没有任何错误、缺陷或问题，能够按照预期的功能和需求正常运行。
“开发无缺陷的软件？这怎么可能！”换做以前的我，不假思索地就会如此断言。但那时的我，从没有想过，我给出的这个结论，依据是什么。事实上，我没有依据，我连脑子都没动过一下，就草率地下了这样的判断。
而现在，我开始反思这个问题，一方面是因为我的思维方式发生了转变，不再轻易地给出片面的结论；另一方面，是因为我尝试了测试驱动开发。尽管我依然认为开发完全无缺陷的软件是一个难以企及的目标，但测试驱动开发确实让我看到了这一目标的可能性。它让我对我的软件质量越来越有信心。
在尝试测试驱动开发的早期，最难以理解、最难以坚持的可能是被称为 Bob Martin 的测试驱动 3 条原则：
- 不允许编写任何产品代码，除非它可以让失败的单元测试通过。
- 不允许编写任何足以导致失败的更多的单元测试，编译失败也算失败。
- 不允许编写任何足以让单元测试通过的更多的产品代码
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
首先，你需要先编写单元测试，这就是为什么叫做测试驱动的原因之一。但是根据规则 2，你不能写太多的单元测试，一旦单元测试代码无法编译或者断言失败，就必须编写产品代码。但是根据规则 3，你只能编写使单元测试编译通过或者断言通过的产品代码，而不能再多！
当我年轻时，我曾尝试测试驱动编程，先后尝试过两次，都因为第 2 和第 3 条原则而放弃，我觉得它很愚蠢！如果你没有尝试过测试驱动开发，也许无法体会到我当时的感受。没有关系，我只是想分享一下我曾经的态度和后来的变化。
随着年龄的增长，我的思维方式发生了转变，我收起了排斥和轻视的态度，放下成见，严格遵守测试驱动原则来编写一个程序。然后，我被测试驱动开发迷住了。
我开始认识到，那些我曾经认为愚蠢的规则，实际上并不愚蠢，而是构建稳健软件必不可少的基础，坚持这样的原则，能确保我的代码在全面且细致的测试用例中得到验证，换句话说，能产生彻底测试过的产品代码。
彻底测试，是每一个软件开发者的理想目标，只有达到这一条件，我们才有可能触及编写无缺陷软件的可能。很多时候，我们都在竭尽全力追求彻底测试，但受限于大脑的逻辑和记忆能力，总是会遗漏某些测试路径。然而，遵守测试驱动开发的 3 条原则，可以帮助我们系统化地进行测试，确保每一个细节都得到了验证。只是遵守 3 条原则，就能实现如此的效果，这真是太划算了。
有关测试驱动编程的框架，可以参考《测试驱动的嵌入式开发 001：VSCode + CMake + CppUTest 环境搭建》。里面提到了环境搭建，还推荐了一本讲解测试驱动的书。
这篇关于书摘：C 嵌入式系统设计模式 01的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
