软件架构设计

最近从零到一开在发新的项目，项目不大但是愈发觉得软件架构的重要性。好的架构非常读起来就非常优雅，逻辑通顺。之前看了太多屎山，毕竟在屎山上修修改改不是什么好的体验。

1. 软件架构

Q: 什么是软件架构？
A: 如何定义？各说纷纭，架构这种东西每个开发者都知道，但是却又说不清楚，更多的是一种感觉。从本质上来看，软件架构是属于一种系统草图，用于指导软件开发人员编写代码，也是一种约束。

Q: 软件架构有什么好处？
A: 良好的软件架构本质上是用前期设计的确定性应对后期变化的不确定性，在软件开发前期，可以将一些可能出现的问题考虑进来，以减少开发过程中出现问题的试错成本。其次软件架构通常将软件模块化处理，这样做的好处可以方便代码的移植和复用，以及多开发者之间的协同开发。

所以整理代码结构，最主要想实现的就是：高内聚，低耦合。高内聚意味着模块和模块之间彼此紧密联系，模块要保持单一功能原则低耦合意味着模块之间依赖关系简单、清晰。单个模块的改动不会影响其他模块。

好的架构大同小异。在网络上也可以看到各路大神归纳总结的软件架构模式。对于嵌入式系统来说，最常用的架构模式不过就是分层设计模式啦。当然还有其他的架构模式，其他的都没怎么实践过，博主个人也不过是个菜鸡，现学现卖罢了。

综上我所理解的架构其实就是分层，分模块。

常见的几种架构

1.1. 裸机架构

2. 分层设计

分层设计是一种将系统分解为多个层次或级别的软件架构方法，每个层次提供特定的功能，是构建复杂系统的基础方法之一。

2.1. 分层设计原则

分离关注点：每一层专注于特定的功能
抽象：上层不需要了解下层的实现细节
松耦合：层与层之间通过明确定义的接口通信
层次独立性：可以独立修改或替换某一层而不影响其他层
接口上下级调用，减少跨层调用，同层级之间避免相互调用

2.2. 常见应用开发层级划分

表示层(Presentation Layer)：用户界面
业务逻辑层(Business Logic Layer)：核心业务规则处理
数据访问层(Data Access Layer)：与数据库交互

[ 应用层 / OS ]   <-- 调用 BSP 提供的板级 API
[ BSP 层 ]        <-- 基于 HAL（或直接寄存器）写板上外设驱动
[ HAL 层 ]        <-- 厂商提供的硬件抽象(放弃这一层抽象)
[ 硬件寄存器 ]
[ MCU/外设 ]

[ 协议/算法层 ]

Q: 为什么我要放弃HAL层抽象？
A: 目前尝试了兼容同一个厂商的两款不同的库函数，配置方式和差异都很大，包括宏定义、接口。如果是两个不同的厂商的芯片，差异可能更明显。设计这样一套程序来完成芯片替换，技术上完全可行，但其成本和复杂性非常高。相对来说还是直接抽象一层BSP，BSP只要封装好，内部使用不同的库。因为HAL很难封装好，导致有一些配置要漏到BSP层，这就导致了BSP同样要改动。既然如此为什么不只改BSP层？果然有些事情只有尝试过才知道。如果是配置寄存器的话，可以适当封装一层hal，增加代码可读性。如果是厂商提供hal，干脆还是用厂商的hal直接写比较合适。维护一个完美的、通用的HAL需要处理所有芯片的功能交集，还要为功能差异设计补偿方案。这本身就引入了额外的复杂度和性能开销。降低架构设计的复杂度！盲目追求完美的架构还是不可取的。

3. 软件架构图设计

设计好了架构肯定是需要宣贯的，让参与的开发者指导每个人应该要负责的内容。所以有必要设计架构图，供大家评审讨论。

个人常用绘制工具是 draw.io，这是一款开源的路程图绘制工具，有网页版本非常友好。