无框架的高级治理 - 第 3 部分

引言

通过一个已完成且正在运行的无框架应用程序，我们现在可以回顾该系列 第一部分 中提出的反对无框架开发策略的论点。通过高治理的应用，无框架开发不仅是可行的，而且是一种可取的开发策略。但什么是“高治理”？高治理是指您利用经验和知识的能力；保持控制并做出明智决定的能力。通过使用框架，您选择将部分治理权交给第三方。这不是一个错误的决定，只要其好处能抵消治理的损失。但往往，尤其是在最不方便的时候，框架会阻碍开发。这是因为所有框架都基于假设，而所有假设都会泄露。因此，您不仅放弃了治理，还必须绕过因泄露假设而造成的障碍。

背景

本三部分系列文章的 第一部分 探讨了无框架应用程序开发的背景、动机和架构方法。 第二部分 介绍了无框架应用程序的实现。 第三部分 反驳了反对无框架应用程序开发的论点。

反驳

有了可运行的应用程序，我们就能更好地反驳那些反对采用无框架解决方案的论点，这也是本文的灵感来源。虽然框架确实承担了大部分繁重的工作，但通常会有更多的相关成本。开发人员的学习曲线成本增加，额外的专有扩展，透明度降低，供应商锁定，甚至更糟糕的版本锁定。放弃对编程模型的控制或为了适应专有框架而破坏架构，从长远来看都是代价高昂的。

数据绑定

反对直接 DOM 操作的论点是治理问题。数据绑定通常使用专有层来执行 DOM 操作，但代码通常对开发人员来说是不透明的。理想情况下，设计人员可以在不影响视图代码的情况下更改表示。但实际上，设计人员的知识仅限于有效的 HTML。他们不会插入声明式绑定扩展，因此开发人员仍然必须将数据绑定扩展添加到 HTML 中。

通过在 MVVM 中使用数据绑定，强制规定只有视图可以操作 DOM。MVP 则“更易泄露”，需要更严格的指南、纪律和代码审查来强制执行。但这并非技术问题，而是流程和治理问题。我们更倾向于高治理提供的透明度和易于调试，而不是不透明和在 HTML 中使用专有扩展。然而，通过高治理，我们保留了 MV* 职责范围的分离。

模板化

已经探索了各种模板策略——从将模板嵌入 HTML 到在服务器上托管模板。TodoMVC 使用流行的 Handlebars 模板引擎，它提供了标准的模板语法和过程。TodoTemplate 隔离了模板处理，以防止演示文稿泄露到视图中。

架构设计

将 jQuery（一个库）与应用程序架构进行比较是极具争议的。具有讽刺意味的是，MVP 架构不是专有的，并且完全开放、透明、可调试，易于教授和学习。奇怪的是，反对 jQuery 的论点却忽略了 MVP。很难找到对由分散的专有 MVVM 框架应用的不透明数据绑定内部机制的清晰而详细的解释。这些问题的出现源于低治理实践，这些实践加剧了对内部机制持续缺乏好奇心。

依赖管理

与之前的论点一样，依赖管理论点也似是而非地将风马牛不相及的事物进行比较。jQuery 的目的是操作 DOM，而 RequireJS 是支持依赖模块加载的事实上的选择。依赖管理是否“内置”并不重要，因为高治理将决定权留给开发人员，让他们自行决定适合其需求和目标的正确方法和工具。

单元测试

除非您打算编写自己的测试框架，否则您必须拥有一个单元测试库。这一事实证明了反对使用无框架的论点的不足，如下图所示。

图 30：选择您喜欢的测试框架：使用 QUnit 或 Jasmine 进行单元测试。

相反，支持依赖注入（DI）的论点则更难反驳。这是因为 DI 被 SOLID 设计模式广泛使用，其中“D”代表依赖注入，并且在测试驱动开发（TDD）中，DI 用于执行模拟。

混淆之处在于认为 SOLID 和 TDD 是开发构造，而实际上它们是流行的开发指南。它们不是开发应用程序的必需品。需求是应用程序的领域功能或方面，由架构表示。因此，DI 仅仅是 SOLID 和 TDD 指南的一个方面，对于应用程序的开发并非至关重要。

选择使用 DI 需要深思熟虑，因为这是一个影响应用程序架构的决定。这是因为 DI 要求暴露对象内部的依赖关系，而这些依赖关系必须反映在架构中。然而，暴露对象的内部依赖关系直接违反了面向对象编程（OOP）的封装原则。

在违反封装和对架构进行功能性更改之前，必须有一个有效的技术原因。单元测试和 DI 并非架构范式。它们不影响应用程序架构。它们是软件开发的辅助方法。只有领域知识才能驱动架构。

DI 解决的问题是当一个对象依赖于可互换的源时，例如由接口或抽象类定义的源。如今，许多开发人员严重依赖模拟实例来测试他们的应用程序，但测试不是领域知识，对架构没有影响。不幸的是，这些开发人员为了支持单元测试而故意破坏他们的架构并违反封装。

合规性和许可

支付卡行业（PCI）合规性是指遵守特定的信用卡处理数据安全标准。这个论点带有两个令人困惑和矛盾的方面。首先，该论点是针对 jQuery 的，作为一个库，jQuery 没有义务提供“全能”的功能集。其次，该论点忽略了真正的问题：PCI 合规性是应用程序的要求吗？如果不是要求，那么拥有它就违反了 YAGNI。

YAGNI 是“you aren't gonna need it”（你不会需要它）的首字母缩写。这意味着，如果 PCI 合规性不是一个要求，那么就没有必要将其添加到您的应用程序中。如果合规性成为要求，那么优秀的开发人员完全有能力应用诸如 stripe.js 这样的库，为他们的应用程序提供 PCI 合规的数据安全性。

换句话说，让需求指导开发，而不是框架。

人员配备

人员配备论点的明显荒谬之处，使得这个反驳显得毫无意义。这个论点类似于声称，由于 ASP.NET 程序员数量众多，因此很难找到 C# 开发人员。这两者并非互斥。然而，我们关注的不仅是优秀的开发人员，更是那些理解使用框架所带来的挫折、障碍、成本和好处的高治理开发人员。

一致性

不幸的是，这个论点混淆了合规性与一致性。一致性正是高治理的核心。我们坚信开发人员的知识、学习和推理能力能够持续地做出明智的决定。这就是为什么治理是开发中如此重要的一个方面。

安全性与兼容性

YAGNI 的反驳在这里也适用。需求决定了应用程序所需的安全性级别。开发人员有许多库、编程模式和加密技术可供选择。

总结

幸运的是，在高治理开发人员社区中，有许多库、模式和解决方案可供选择，这些开发人员乐于分享他们喜欢的工具、方法和成功的经验。这些开发人员避免了导致障碍的泄露假设、反模式和锁定。他们渴望低摩擦的学习、透明性、流畅的调试体验，最重要的是，推广高治理开发，它有利于常识性的决策和控制，而不是习惯和遵从的做法。

关注点

Joe Gregorio 是《零框架宣言》的作者，他在 YouTube 上有一个精彩的演讲，名为《停止编写 JavaScript 框架》。该宣言和演讲为无框架方法提供了坚实的基础和宣传。

历史

2016 年 6 月 14 日 《无框架高治理》初始发布。
2016 年 6 月 17 日 修正了语法错误。