汽车软件架构学习笔记(一)：九问软件架构

Q1.什么是软件架构？

软件架构的定义没有一个统一的标准，各有各的看法。但可以参考来自SEI的定义：

计算系统的软件架构是解释该系统所需要的结构体的集合，包括软件元素、元素的交互，以及两者各自的属性。

可以从 2 个维度描述：

静态结构，包括层次、模块划分以及更细节的数据结构体等等，代表一个系统的骨架，就如一幢建筑物的框架；
动态行为，包括模块间的通信、交互机制，代表系统的行为。

Q2.什么属于架构层面的内容？

架构一般指的是软件系统宏观层面的设计部分,前面讲到架构是骨架，关注于整体,一般不会关注于细节。

但同时，如果有一些元素的设计会影响到整体系统的质量属性，那么它也应该被拉进架构设计中讨论。比如，嵌入式系统当中，实时性是一个很重要的质量属性，那么对于通信协议的技术选型也就是非常重要的。比如，一个汽车软件架构师，你说不你懂CAN协议终归不合适。

Q3.架构重要吗？

重要，关系到软件系统的成败。
有下面的作用：

扮演着系统骨架的角色
影响质量属性
与软件功能正交决定系统能做什么
更加重要的是决定系统不做什么

尤其是最后一点非常重要，比如在汽车自动驾驶当中，自动化程度是分等级的，假如你设计一个L2级别自动驾驶系统，你就应该将L3级别以上功能排除在外，通过 ODD 进行准确的界定。

Q4. 什么时候需要架构？

可以不需要架构，这个叫大泥球模式。

说起来也挺尴尬的，很多时候我们发现一个软件团队没有架构师、没有架构也能正常开发并正常实现所有功能。但没有架构设计的系统其实也有架构，它代表一种功能优先设计的模式，就像一个大泥球一样越滚越大。

当然，正常的开发者都知道很多情况需要架构的，比如：

实现特别难的解决方案
非常容易失败的高度复杂项目
非常难以满足的质量属性的系统
需要统筹的产品线

无非就 2 点：
越难的项目越需要架构设计
产品平台需要架构设计，比如一家自动驾驶企业，如果做L3，也做L4，最理想的状态就是他们的产品基于同一套架构，这样能够避免资源冗余和浪费。

Q5. 什么是推定架构和参考架构？

推定架构(presumptive architecture) 是行业占主导地位的架构族，不采用会需要特别做说明的技术。比如你做汽车ECU软件开发，如果你不采用 CP Autosar，你得准备好来自各个方面的质问，你要说明你不选它的逻辑是什么。
参考架构(reference architecture) 是针对某个问题在架构方面的解决方案。推定架构是事实标准，参考架构想成为事实标准。
自动驾驶软件架构有一些参考架构，但它只做参考用，比如下面这张图。

Q6. 如何在一个项目中运用架构？

有几种选择：

不运用任何架构
从0到1严肃的正向设计开发
在原有架构上进行重构与提升

3 种方式都很普遍。

Q7. 企业架构师与应用架构师的区别？

企业架构师是站在企业的角度负责多个应用系统的开发，不负责单个系统的具体功能，专注于打造企业内的软件生态系统，促进每个软件系统为企业贡献力量。
应用架构师关注于单个软件系统的架构设计。
我举个例子。智能汽车当中现在有智能网联、智能驾驶、智能座舱 3 大系统。企业架构师的职责就是打造整个智能汽车软件生态。应用架构师可以只负责其中一个系统或者子系统的架构。

8.康威定律如何描述软件架构？

任何设计系统的组织…必然会产生以下设计结果，其结构就是该组织沟通结构的写照。

我比较认同一种说明，架构设计本质就是一种社交行为。和客户、用户、项目经理、产品经理、测试人员、开发人员、其他相关人员

9.软件架构的另外一个定义？

前面讲到软件架构没有统一标准，另外一个比较有名的定义来自 Martin Fowler 与 Ralph Jonson 之间的讨论。
架构是必须在项目早期作出的一组设计决策。

也被称为“那些在项目后期难以改变的内容”。

但我个人认为，这种说法只是为了强调架构设计在软件开发过程中应该越早介入越好，是一种理想的状态。

备注：本文观点大多来自《恰如其分的软件架构》。