前言 - 打造企业级 Web 应用程序
在敏捷交付的时代，功能的小片段不断地交付给用户。软件行业开始青睐这种方法，因为它有助于最大限度地降低风险，同时最大限度地提高用户参与度和满意度。
即使采用现代交付方法，一些风险仍然不可避免。复杂性就是其中一种风险，并且可能成为成熟应用程序的主要问题。无论应用程序可能遵循哪种系统架构，随着时间的推移，许多功能的小片段可能会累积成一个庞大而令人生畏的代码库，需要多个团队来监督。
随着应用程序投入生产的时间越长，实施新功能、干净设计的可能性就越小。相反，现有功能更有可能被调整、修复错误或扩展。成功的应用程序及其包含的功能在其生命周期的绝大部分时间都在维护中度过。
维护一个复杂的应用程序需要极大的纪律。团队很容易被压垮，将时间花在与代码库和同事发生冲突上，而不是为用户提供价值。缓解这种风险涉及许多不同的方法，涵盖标准、模式、技术选择和工具等领域。
管理复杂性
错误最好在软件交付生命周期的尽早阶段被捕获。修复刚刚在单个开发流中引入的错误比修复已经通过整个交付管道并投入生产的错误要快得多、便宜得多，因为用户可能会受到负面影响。
类型
在应用程序开发阶段，采用强类型是一种很好的早期捕获错误的方法。如果在应用程序代码中明确说明类型信息，则可以避免由数据类型不匹配引起的逻辑错误。编译器和静态类型检查器可以根据类型信息进行验证，并在发生此类类型不匹配时使构建失败。只有在解决所有此类错误后，软件才能从单个开发人员的工作区推进到交付管道的其余部分。
Dojo 基于 TypeScript 提供显式类型和静态编译时类型检查。使用 Dojo 构建的应用程序可以从使用 TypeScript 而不是原生 JavaScript 中获益。
当使用 Dojo CLI 来搭建应用程序时，默认情况下，应用程序构建过程中会包含 TypeScript 编译阶段。开发人员可以从一开始就编写类型安全的应用程序代码。
模块化 - 单一职责原则
理想情况下，组件应该足够小，以至于它只实现一个职责。组件越简单、封装性越好，在长时间内，无论有多少开发人员，它就越容易理解和维护。具有大型代码库的复杂应用程序是通过许多此类更小、更易于理解的组件的组合构建起来的。
在单个组件中隔离职责在尝试降低复杂性时有很多好处
- 范围有限。假设组件维护一致的 API，则可以在不影响组件外部用户的条件下进行内部更改。相反，组件的详细信息将保留在其定义模块内部，这意味着它的定义不会与可能重叠某些命名约定的其他组件的定义发生冲突。
- 测试需求得到简化，因为单元测试只需要关注单个职责，而不是多个条件下的应用程序流的指数组合。
- 组件可以在多个位置重复使用，避免重复。错误修复只需要对单个组件进行，而不是对多个独立实例进行。
对于 Web 应用程序，隔离对最终用户有额外的益处。应用程序可以划分为多个层，允许用户在特定时间点仅加载他们感兴趣的层。这减少了资源大小和相关的网络传输需求，从而缩短了用户在开始工作之前所需的加载时间。