EEPW论坛

软件架构这东西，众说纷纭，各有观点。在我看来，软件架构是软件系统的基本结构，包含其组件、组件之间的关系、组件设计与演进的规则，以及体现这些规则的基础设施。

软件架构，从来不是一件容易事，它贯穿在产品的整个生命周期，需要所有团队成员遵守并自律，才能将架构思想在软件中体现。新手工程师，由于经历的项目太少，看不到项目全貌，很难从全局理解软件架构。但软件架构真的只是资深工程师的专利吗？这个也不见得。

古人作文，讲究立意为先。今天工程师做项目和产品，也应该先立意。这个意，就是指要有高度。工程师入门能从软件架构的高度出发，看待软件问题，相信对软件的理解，会更加深刻一些。因此，我总结了软件架构的六个步骤，供嵌入式工程师参考。

上次谈到了嵌入式软件架构的第一个步骤，抽象层。建立抽象层（HAL或者DAL）的目的，是为了隔离硬件，让代码与硬件无关。即使整个项目的代码，由某工程师一个人完成，抽象层仍是是有必要的。但这次我们要聊的是，统一的基础设施，这是针对多人合作一个项目，或者多个项目共享同一个系统架构的情况。

如果说，你手头的项目，没有与他人合作，也不会有后续的相关项目，软件基础设施这一步，可以直接跳过。

基础设施，分为硬件基础设施和软件基础设施。硬件基础设施，包含常用器件库、封装库、原理图库和硬件参考设计等等；而今天我们讨论的重点，主要在于软件基础设施。软件基础设施包含以下内容：

• 基础数据结构。

• 底层库。比如C标准库、加密库、校验库、工具库等等。

• 操作系统/调度机制。包含操作系统或及调度相关服务。

• 中间件。比如文件系统、协议栈、数据库等。

• 框架与机制。比如消息通信机制、事件驱动机制、状态机框架、行为树框架。

• 工具支持。

• 统一的编程工具链。

• 统一的代码风格和编程规范。

在一些小公司粗放的开发模式中，并不规定工程师所依赖的软件平台、硬件平台和工具，而是由工程师自己决定。很多工程师，也喜欢这种自由奔放的开发模式，认为只有在这种环境中，才能发挥自身创造力。这种认知是有偏差的，这个我们后续找机会详细讨论。

随着小公司研发能力的提升，对软件基础设施进行约束和规定，几乎是注定的事情。因为软件区别于其他技术的本质，是在于其复用性。

复用程度越高的软件，质量越高，对开发效率和开发质量的提升，就越大。无论从公司的降本增效还是科学管理的角度，都有着强大的动机，去统一软件基础设施。当软件的基础设施统一之后，会产生如下优点：

• 软件质量提升，风格的高度一致性

• 软件复用性，会提升至一个新的水平

• 将可复用的功能，尽量抽象到基础设施层，减少软件冗余，提升开发效率。

• 为高层模块提供约束和纪律

• 有利于团队的技术积累和技术传承

• 有利于团队的技术培训

• 是团队进行单元测试和测试驱动开发，以及跨平台开发的前提。

因此，是否统一，根本不是一个有争议的问题；如何统一，才是今天我们的重点。

来源： 整理文章为传播相关技术，网络版权归原作者所有，如有侵权，请联系删除。