实时应用程序和基于组件的开发的关键作用

组件化开发，或称 CDB，是构建复杂嵌入式系统的公司已采用的成熟实践。这种实践的实际成果不难发现。使用智能手机、驾驶汽车、在设备上玩游戏，你很可能正在使用受益于某种形式 CBD 的嵌入式系统。对于这类设备，让一块软件，即一个组件，负责与该小工具交互是有意义的。对于嵌入式系统，这种方法相当明确。

有关物联网的更多思考，请参阅我们早期的相关文章，“应对物联网革命”。

将 CBD 应用于纯软件

但 CBD 在大型“纯软件”组织（如数据挖掘和大数据分析）中也越来越受欢迎。与嵌入式系统（其中 Day 1 就需要某种形式的 CBD）不同，对于大型软件组织而言，这是一个组织演进的模型。组织通常寻求“打破单体”，将大型单体代码库拆分成模块。他们这样做是为了获得更大的代码重用、更高的质量和更少的测试工作，以满足日益缩短的软件交付截止日期。

一家成熟且复杂的软件组织才能认识到这一点：你应该只有一个地方编写与特定软件小工具交互的代码。以 FTP 服务器为例，你想与之通信。通过 CBD，将只有一个软件组件与 FTP 服务器交互，所有人都将使用它。它将被编写一次，虽然它会随着时间演变，但将有一个命名组件供人们查找和重用——或者至少在考虑重用是否比从头开始构建更好时进行考虑。

一旦达到一定的项目规模，组织就会计划或偶然（在后者情况下，是出于纯粹的必要性）走上 CBD 的道路。当今的敏捷软件环境和消费者对更高质量软件更快交付的期望，都要求这样做。

从头构建的高昂成本

在典型的、大型的、非 CBD 的软件开发环境中，开发人员一直在从头开始构建。当他们需要某样东西时，这种方法通常看起来最快捷。但是，当他们回顾时，会发现不同团队在不同时间编写了数十个大致相似的 FTP 连接器实现，所有这些都试图做或多或少相同的事情。不同的实现将具有不同的质量和测试程度，并且都单独维护。

最终，这种方法在初始开发时比一次构建和重用更耗费组织的时间和资源，并且在维护时耗费的时间和资源要多得多。重复造轮子会产生高额的技术债务利息，并增加错过关键开发里程碑的风险。

采用 CBD 涉及建立定义和发布组件的标准、建立 API 和数据共享协议的标准，以及定义清晰的软件构建系统的生产者/消费者模型。在某些情况下，采用 CBD 需要在构建基础设施中引入层。

在拥有大量模块的系统中，关键在于使其易于搜索组件，以便开发人员可以实际去搜索，而不是每次都从头开始重新解决别人在几周、几个月或几年之前就已经解决的相同问题。一个好的搜索引擎可以搜索开源选项。但是，大型的企业内部代码库和可重用的小部件也需要是可搜索的。

提高开发速度

传感器、陀螺仪和 GPS 等组件的商品化正在加速物联网的实现，物联网是一个描述人类之间共享数据于小工具、传感器和机器人之间的互联网的术语。这些想法并非新颖，但物联网计划开发速度的加快令人兴奋。这是推动适用于大规模软件开发工作的软件开发流程和标准的再工具化和优化的力量。

尽管总体规模巨大，但典型的 CBD 实现涉及许多小型团队，每个团队只有少数几个人负责某个组件。通常，对于任何单个组件，只有少数主题专家。

单一事实来源

无论你是为物联网开发还是将单体代码库拆分成模块，CBD 的一个共同主题是必须有一个**单一事实来源**来管理各种配置信息，包括

• 要交付的产品列表以及它们构建所用的组件
• 要维护的活动开发流（分支）列表（例如，主线和两个维护版本）
• 每个分支所需的组件版本列表
• 工具链
• 开发人员和官方构建的工作区

考虑到其中任何一项都可能随时更改，因此对强大配置管理的需求就很明显了。组件的新版本可能需要更改工具链，如果需要更新版本的编译器。支持旧版本产品意味着要查看以前使用的组件列表，可能包括旧的编译器或旧的构建系统。

成功实施 CBD 的关键在于工具。存在许多机会来匹配复杂依赖关系的各种排列组合。开发人员很难正确地做到这一点，因此**必须使其几乎不可能出错**。其精妙之处必须在于工具，以便开发人员能够专注于当前的任务。

例如，在 CBD 世界中，开发人员可以简单地指示“我想开发 Friendly Greeting System (FGS) v1.4”，然后将该输入转换为一个可用的工作区域，其中包含实时编码所需的一切。

在一个良好的 CBD 环境的底层，所有内容都是版本化的：文件、工作区定义以及所有组件的依赖项。开发人员可以忽略所有这些，然后开始签出代码并提交更改。他们可能会更改**代码**，也可能会更改**配置**（例如，更新到他们使用的某个组件的新版本），有时两者都会一起更改。重要的是，开发人员能够以类似的方式审查代码和配置更改，并能够将两者作为单元进行协调和提交。

强大的版本管理系统是 CBD 基础设施的核心。版本控制系统直接提供的 CBD 功能越多，开发和采用 CBD 工作流程所需的自定义工作就越少。

将 CBD 引入内部

大多数组织通过某种 CBD 类似流程来处理第三方产品，即使他们不这样认为。他们希望指定某个第三方软件（例如，组件）的版本 X.Y，他们知道该版本与他们自己的东西兼容。当一个组织编写的软件越来越多，以至于需要开始将自己的系统分解成层时，将 CBD 流程引入内部就变得有利可图，组件的消费者将他们消费的东西视为几乎是第三方产品——至少从消费它们的其他组件和产品的角度来看。

避免技术债务

最终，CBD 部分是为了实现软件开发的规模化效率。软件开发将永远不同于制造，制造的目标是以最低的成本大规模生产数百万个相同的部件。软件开发应用人类的创造力来产生一系列软件更改。

随着开发规模的增加，将软件开发与生产线进行类比变得越来越相关，其中软件**变更集**就是大规模生产的部件。规模越大，管理和制度化代码重用就越关键，以确保软件开发“生产线”能够满足组织的需要和截止日期。实践 CBD 的公司认识到这一价值，并避免了当软件被反复重写而不是组装时产生的技术债务。