前三节，我们讲解了三种程序组织模型：严格层次化、元件化、分布式。在团队内部，为了简单我们习惯称之为“分层分块分布”。综合这三种策略，基本可以决定一个产品中各软件模块的静态组织关系，因此，“分层分块分布”是一种静态组织架构。目前，虽然各有侧重，我们团队研发的各类产品几乎都遵从“分层分块分步”的静态组织架构。
为何会持续的演化出这种程序静态组织模式呢？复盘整个演化过程，我发现这种模式与其说是设计出来的，不如说是长出来的。
现实世界中，需求在持续不断的迭代，但人力永远是紧缺资源。为了能让更少的人做更多的活，平台化研发和高复用模块几乎是我们最自然而然的选择。吃到一次甜头后会越发想吃，而一次次的正循环会将我们推到了目前的状态。这也是我和很多朋友交流时会反复强调，不要担心目前的一片混乱，只要能牢牢的抓住几个关键抓手不放，时间会让我们长成自己曾经羡慕的样子。
“分层分块分布”这种静态组织架构，不仅提供了一种程序组织模式，实际上也在潜移默化的影响着我们的研发模式。
“分层分块分布”静态组织架构的一个核心点是平台化研发。所谓平台化研发，就是不以单一产品作为研发任务，至少是以一个领域方向作为研发任务。如本书的着力点微机保护产品，实际上就包含很多产品类型，不仅有本书提及的综合过流保护和差动保护，还有电动机保护、母联保护、发动机保护、距离保护等很多种类型。基于平台化研发理念，微机保护产品研发时，会首先会构建通用平台，然后基于通用平台进行各产品快速研发。
有时候平台化研发甚至会跨越领域方向，如我们有一款电力行业通讯管理机产品，基于平台化研发理念，这款产品跨越了很多领域方向，放到电表行业就是采集器集中器等抄表系统，放在油田行业就是油田RTU产品，每个领域规约和驱动可能不太一样，但整体架构和设计理念是基本一致的。如下图所示，红色框选出来的就是油田RTU领域方向。类同油田RTU，基于平台化研发，其他产品也是代码产品库中的一个配置子集。
“分层分块分布”静态组织架构的另一个核心点是高复用。实际上平台化研发模式也是构建高复用模块的催化剂。为了能让平台适用面更宽，我们不得不一次次的迭代优化各种平台基础模块。迭代次数多了，自然会诞生很多优秀的高复用软件模块。
基于平台化研发模式和高复用特征，研发团队的人员组织结构也会缓慢适应性调整。以往的研发理念都是以产品为边界的，自然会构建很多项目组，每个项目组负责一款产品。基于平台化研发模式后，研发人员开始分化为平台和领域两类研发人员，因为每个人可以更好的专注于自己的领域，因此会诞生很多领域专家，又因为经常需要整体考虑各行业的产品，因此也会催生一些架构师。有了这些优秀的领域专家和架构师，可以进一步反哺产品，不仅是研发效率提升，甚至可以开始研发一些高层次产品了，这恰恰是国内工业领域最为缺乏的。
◇◇◇
基于平台化研发模式，还能衍生出无限可能。我们在实践中衍生出一个特殊的软件模块：虚拟设备。虚拟设备分为两部分：虚拟硬件和虚拟应用，可分别运行。如下图所示：
嵌入式软件研发依赖于硬件，这会给项目组织带来诸多困难。一个项目从立项开始，到看见第一块完整的硬件板件，需要依次经历需求分析——原理图——PCB——制板——焊接——测试等诸多环节。即使此时，也需要先完成驱动后才能开始应用代码调试，难道这个过程就让软件组傻傻的等待吗！
一种比较好的策略就是额外增加一个虚拟硬件模块，在台式机上模拟完整的设备。借助虚拟硬件模块，可以极大的提升软件组的工作效率。在我们团队，差不多80%的代码是基于虚拟设备研发的，大部分是和硬件组同步的。新板件制作完毕后，仅需要额外进行驱动研发，然后就可以快速的切入整设备集成测试环节了。
虚拟硬件不仅能提升软件组工作效率，而且可以提供额外的测试环境。如我们研发的某款产品AD采样模块，发现在50hz附近输入时计算精度很高，但在偏移基准频率输入时计算精度就开始快速下降，要知道电力系统故障时存在大量的高频分量，这样会影响微机保护动作精度。
基于虚拟硬件，我们做了两个测试：首先确认虚拟硬件上的高频分量计算精度符合要求，说明算法没问题；其次用虚拟硬件的仿真数据代替AD采样在设备中计算，发现计算精度也符合要求。因此，我们可以确定问题出现在硬件的AD采样回路。
后来发现，是因为硬件的AD采样回路是一个滤波器，而滤波器对不同频率的输入信号幅值存在影响，也就是数字信号处理中常提及的频谱曲线。我们的AD采样回路如下图所示，是一个典型的二阶RC滤波回路。
其对应的频谱曲线如下图所示（基于matlab仿真）：
基于频谱曲线，很明显的发现不同频率对应着不同的幅值缩放因子，因此，如果能在计算过程中增加一个逆向调节因子，就会提升幅值计算精度。
随着产品的持续迭代，平台模块也在持续迭代中，但此时会衍生出另外一个问题，每个特定产品仅会使用到平台模块的一个子集，那如何对平台中的诸多模块进行集成测试呢？
为了解决这个问题，我们会构建一个虚拟应用模块，其侧重点不在应用，而在于通过一个应用将各种平台模块耦合起来，便于进行集成测试。
额外，该虚拟应用模块也是一个很好的学习参考模块。各应用开发人员在进行领域产品研发时，无数的文档也不如一个模拟的产品来的适用。实际工作中，很多特定领域产品的研发起点就是fork一个虚拟应用模块，并基于该模块进行修改，简单且快速。
虚拟应用和虚拟设备构成了虚拟设备模块，而虚拟设备模块于我们团队，远远的超越了一个简单的软件模块。晚上下班后，现场一个电话，我快速的在工程云电脑上运行其虚拟设备，快速的解决问题，那种处理问题游刃有余的感觉，让人非常的享受，或许只有真正经历过，才能体味到其中的精彩。
◇◇◇
基于平台化研发模式，程序的目录组织结构也需要相应的适应，如下是适用于微机保护装置的一种可能的程序文件组织形式，供大家参考。
relay 整个项目总目录结构
boot boot程序，用于主程序和参数下载
MMIBoard 面板can分布式程序
…… 不同尺寸液晶对应不同程序版本
expandBoard 各种di,do,ai和ao分布式扩展板
expand16DI 16路DI扩展板
expand16AI 16路AI扩展板
……
hardware 硬件相关资料，包括原理框图，版本，调试说明等
commit 最终提交的各版本程序
XXXXXX(2013-xx-x,V1.xx,0xabcd) 发布程序（时间，版本，校验码）
XXXXXX(2014-xx-x,V2.xx,0x1234)
……
documents 文档目录
设计文档 组织架构设计相关文档
对用户文档 包含对用户文档，如技术说明书，规约文档，工程说明等
测试文档 集成测试文档和测试记录
工作日志.doc 包含版本说明，现场各种反馈等信息
sysCfg 配置软件，基于平台统一研发
maintain 维护软件，基于平台统一研发
simEquip 虚拟设备平台统一构建部分
sysPlat 平台程序部分
sysPlat.h 平台部分给领域产品研发公开的统一接口
driver 驱动层目录
hardwareAbstract.h 硬件抽象层对外统一引用头文件
winSim win仿真实现，对应虚拟硬件部分
…… 具体实现
STM32F207 基于ST207芯片的驱动实现
…… 具体实现
…… 其他驱动版本实现
basePlat 基础平台层
xf 动态执行框架
gui gui模块
script 脚本
……
api API抽象层
apiInclude.h API抽象层对外的统一引用头文件
ai.h,ai.c,aiPrivate.h ai模块
di.h,di.c,diPrivate.h di模块
……
history.h,histroy.c 历史数据模块高级应用
trend.h,trend.c 趋势数据高级应用
……
app
appInclude.h app模块对外统一引用头文件
main.c 统一的主程序入口框架
103Protocol.c 103规约程序
a11Protocol.c A11规约程序
……
relayBoard 各种保护产品程序目录
simEquip 虚拟设备
550 过流综合保护装置
para 配置软件生成的参数存放目录
IAR_ST207 基于iar编辑器和st207芯片的开发环境
VS2017_SIM 基于VS的仿真运行环境。
src 特定领域代码
……
587T 变压器差动保护装置
……
supportToolsSrc 外围支持软件总目录
commSrc 外围支持软件公共代码
createS19 程序格式转换软件
MIMIC 主接线图工具软件
simDisturbFile 模拟采样数据
……
tools 外围支持软件可执行程序统一路径
clear.bat 用于清除整个项目中的中间文件，便于版本提交
限于篇幅，虽然未能将完整的目录结构展示出来，但大家已经可以很清晰的看到程序代码组织分为平台部分和特定领域部分，而平台代码占比较大。
额外强调一点，上述目录结构仅仅是一种简单示例展示，实际项目的目录结构可能要复杂许多，如会区分源文件和头文件目录，分成多个可编译库，包含大量的配置文件，甚至部分配置文件和目录是有配置软件生成的。
◇◇◇
“分层分块分布”静态组织架构不仅影响着程序的组织模式，甚至重构着研发模式。下一章，我们开始探讨程序的动态组织架构，又会给我们带来怎样的惊喜呢？
——————————————
我是小马儿，一个渴望良知与灵魂的嵌入式软件工程师，欢迎您的陪伴与同行，如感兴趣可加个人微信号nzn_xiaomaer交流，需备注“异维”二字。