一、生产实践模块组织
在前面进行了模块的尽量详细的分析和说明，对其中的的组织形式也进行了初步的分析。在生产实践中，具体的组织除了遵循技术上的组织方式外，还要针对具体的应用进行组织管理：
- 根据业务领域划分，如通信中的网络模块、串口模块等
- 根据技术领域划分，如数据库模块、服务模块等等
- 根据功能划分，如输入、输出模块等
- 公共模块，如常见的字符串转换、JSON处理等
模块的分区也可以参照前面的技术内部的组织形式和上述的方式灵活机动的进行组织应用。正如形式上的文件路径映射和内在的技术与具体实践的有机的统一，才是一个良好的模块设计开始。
二、实践中的混合编译代码迁移策略
模块间的引用，也是符合设计原则和设计模式的。可以通过依赖注入和接口隔离等方式对模块进行整体设计的把握。可以利用各种有效的工具和方法实现不同的策略来进行更好的编译，特别是与旧的代码的混合编译。
- 增量迁移策略，即不是全部一次性引入模块，而是有步骤的分步引入
- 缓存策略，使用工具提供的增量编译方式实现
- 自下而上的封装策略，即从基础入手，逐渐复杂
- 由近及远的策略，及从最核心的头文件依赖转为模块封装开始，混合过渡
在整个的迁移过程中，特别是清楚当前的环境对模块的支持程度及相关的编译机制。目前gcc,clang和msvc对模块机制的支持并不完全相同，引入的具体的用法可能也有所不同。这就需要开发者不能盲目的搞跨平台的模块处理。
另外，cmake对模块的支持明显还不在状态，许多细节仍然需要人工的处理和指定。这就使得其应用的范围受到了一定的限制。
三、ABI的兼容性控制
ABI的兼容性其实是一个让C++开发者头疼的问题。不过，可能对于大多数的C++开发者说，这并不是一个问题，因为可能遇不到。但实际在跨平台和跨语言的应用中，ABI的兼容性非常重要。为了保证模块引入后的二进制兼容性，可以采用下面的方式：
- 使用原有C++控制ABI兼容的方式，如虚函数的控制、内存对齐、改名方式以及标准库的版本控制等
- 引入PIMPL等机制保证接口的抽象隔离
- 控制编译器和版本管理
- 最小化ABI的暴露
在上述的软件开发的控制基础上，还可以引入工具相关的控制，如使用统一的中间代码IR生成方式（LLVM），再通过符合规范（如WASM）操作生成的二进制进行跨平台的兼容格式处理。
四、第三方库的集成
在实际项目的开发中，使用第三库是一个无法避免的需求。在应用第三方库时，需要注意的有：
- 利用各种设计原则和模式进行第三方库的抽象隔离和解耦。如采用异常统一管理、接口抽象隔离、最小化职责等方式
- 控制第三方库的引入目标范围，减小第三库的广泛引用
- 形成模块管理机制，特别是包管理工具的使用（C++中可能没有权威的工具）
- 适时跟进可能出现的模块新机制如远程模块（类似于JAVA和GO中的模块引入）和自动模块解析相关的技术
总之，对于第三方模块的控制要严格控制使用范围，隔离风险，抽象接口，合理的使用相关的工具，才可以更好的发挥"第三方"的优势。
五、总结
综合应用的例子前面已经有了，更复杂和大规模的应用目前也给不出相关的例子，所以本文就不再给出例程了。作为模块使用的初步经验总结，还是显得比较粗浅。毕竟现在实际的工程中对模块的应用还只是有限的公司和有限的场景，所以，这就需要开发者审慎的根据自己的情况不断的实践和总结，达到对模块应用的"臂控指展"。