序言 - 构建企业级 web 应用程序

在热衷敏捷交付的时代，鼓励将小功能点持续地交付给用户。软件行业开始青睐这种方式，因为它最大限度地降低风险，并最大限度地提高用户的参与度和满意度。

即使采用现代的交付方式，一些风险仍然不可避免。复杂性就是这样一种风险，对于成熟的应用程序而言，复杂性更成为一个重要的关注点。无论应用程序遵循什么样的系统架构，随着时间的推移，许多小功能聚集出一个庞大且令人畏惧的代码库，需要几个团队监督。

应用程序上线的时间越久，实现一个设计简洁的新功能的机会就越少。相反，更多的是在现有功能的基础上调整、修复 bug 或扩展。一个成功的应用程序——以及所包含的功能——大部分时间都花在维护上。

维护复杂的应用程序需要经过严格的训练。团队很容易陷入泥潭，将时间花在抱怨代码和同事上面，而不是向用户交付价值。要降低这种风险涉及很多方面，包括标准化、模式化、技术选型和工具等领域。

管理复杂性

在软件交付的生命周期中，错误发现的越早越好。在开发阶段修复一个错误，比在交付环节修复错误，或者已给用户带来负面影响的上线阶段修复错误要快的多，成本也低得多。

早期捕获错误的好方法是在应用程序的开发阶段支持强类型。如果应用程序的代码中显式指定了类型信息，就可以避免数据类型不匹配而导致的逻辑错误。编译器和静态类型检查程序可以验证类型信息，并当类型不匹配时让构建失败。只有修复了这些错误，软件才能从个人的工作空间进入到交付管道的后续环节。

Dojo 构建在 TypeScript 之上，提供了显式的类型和静态编译时的类型检查。使用 Dojo 构建的应用程序可以用到 TypeScript（而不是普通的 JavaScript）带来的优势。

当使用 Dojo CLI 构建应用程序时，应用程序的构建过程会默认包含 TypeScript 的编译阶段。开发人员从一开始就能编写出类型安全的应用程序。

理想情况下，一个组件应该足够小，以便它只实现单一职责。一个组件越简单、封装程度越高，则大量程序员长期理解和维护时就越容易。拥有庞大代码库的大型应用程序就是由大量的更小、更容易理解的组件组合而成的。

试图降低复杂度时，在单个组件中隔离职责有以下好处：

限制范围。假设组件维护一套一致的 API，则能在不影响外部用户使用的情况下更改内部实现。相反，组件的详细信息保存在定义模块的内部，这意味着其定义不会与其他组件的定义冲突，所以就不会与其他组件的命名约定重叠。
简化测试需求，因为单元测试只需关注单一职责，而不是多个条件组合成的越来越多的应用程序逻辑。
组件可以在多处重用，避免多处重复实现。修复错误时，只需专注于单个组件，而不是散落在各处的单独实例。

对于 web 应用程序而言，隔离还能为终端用户带来额外的好处。应用程序可以划分为多个层，用户在给定的时间点只加载他们感兴趣的层。这减少了资源大小和网络传输需求，从而缩短了加载时间。