本文讨论以图表方式表示 Angular 应用程序。它是一个初步步骤,而不是关于如何以可视化方式指定或记录 Angular 应用程序的完整论文。或许这将导致我尴尬地发现其他人已经有了完整的解决方案。
我对这个想法的兴趣源于两个正在进行的项目
- 我在日常工作中参与了下一代版本 Desk.com 支持中心代理应用程序的开发,以及
- 我的业余时间在为 Manning Publications 编写一本名为 Angular In Depth 的书
1: 大型复杂 Angular 应用程序
第一个项目涉及作为多人前端团队的一部分,开发一个大型复杂的 Angular 应用程序。我发现(而且我认为其他团队成员也遇到过)其中一个问题是,我们难以熟悉应用程序的不同部分,因此我的添加或更改不会破坏应用程序或在未来造成问题。
对于 Angular 应用程序来说,有时很难追踪事件的发生位置。指令使你能够封装行为并以声明式方式使用该行为。这很棒。除非你遇到了嵌套指令或多个指令同时运行,而这些指令是其他人精心编写的。那个人可能对所有事物之间的关系和协同工作方式有一个清晰的愿景。但是,当你初次接触它时,追踪这些部分并将它们记住,以便你开始添加功能,可能是一项挑战。
如果我们能够以可视化的方式表示 Angular 应用程序的复杂部分,那不是很好吗?一些能够让你一目了然地了解依赖关系的东西。
2: 书籍项目
上面的第二个项目——书籍项目——涉及尝试编写关于 Angular 如何在幕后工作的文章。我认为大多数 Angular 开发人员在某个时候都将 Angular 的某些部分视为魔术。我们也都在抱怨文档,特别是那些使用术语来描述其他术语的描述,而这些术语的描述基于对该链中第一个项目的理解,而这种理解定义模糊。
在在线示例、文档或入门应用程序中使用 Angular 指令和服务并没有什么问题。但是,如果我们也能理解幕后发生的事情以及原因,这将对我们作为开发人员有所帮助。了解 Angular 服务是如何创建和管理的可能不是编写 Angular 应用程序的 *必要* 条件,但可以提高编写和质量,我认为,更好地理解这些细节可以提高编写和质量。
可视化表示
在试图更好地理解 Angular 幕后工作并编写相关内容的过程中,我开始大量依赖于关键概念和流程的可视化表示。我所做的可视化表示并不完美,但仅仅是尝试在图表中表示一个流程,就具有很好的澄清效果。
以可视化方式表示软件概念并不新鲜。UML、流程图,甚至业务流程建模符号 (BPMN) 都是用于可视化类、概念、关系和功能的方法。
虽然这些绘图技术很有用,但似乎至少在 Angular 世界中,我们缺少一种适合描述、记录或指定 Angular 应用程序的完整的可视化语言。
我们可能不需要重新发明轮子——显然不需要完全全新的东西——但当我在处理一个(对我来说)新的复杂应用程序区域时,如果能使用定制的可视化词汇表来表示它,将会有所帮助。
以图表方式表示前端 JavaScript 开发
我每天都在使用 Angular,因此我特别考虑如何表示 Angular 应用程序,但这可能也是整个 JavaScript 社区中的一个问题:如何以图表方式表示前端 JavaScript 开发,以便我们能够清楚地可视化我们的模型、控制器和视图,以及 DOM 与我们的 JavaScript 代码之间的交互,包括事件驱动的异步回调。换句话说,一种用于客户端 JavaScript 开发的可视化领域特定语言 (DSL)。
我没有一个完整的答案,但为了自圆其说,我开始使用一些图表来大致表示 Angular 应用程序的部分。以下是某种程度上我用来获得第一个版本的顺序
- 我做的第一件事是写出对问题的详细描述以及我对 Angular 可视化 DSL 的期望。我还定义了一些简单的缩写,用于标识不同类型的 Angular “对象”(指令、控制器等)。然后我开始绘制图表。
- 我确定了需要更好地理解的代码区域,选择了一个文件并将其放在图表上。我想做的是以一种可以让我查看该文件并记录它,而无需同时追踪它连接到的所有内容的方式绘制图表。
- 当第一个项目在图表上时,我转到它所依赖的某个东西。例如,从指令开始,这会导致关联的视图或控制器。我绘制了第二个项目并添加了关系。
- 我不断添加项目和关系,包括嵌套指令及其视图和控制器。
- 我继续进行,直到图像变得有意义,我能够看到完成任务所涉及的各个部分。
由于我正在处理一个特定的工单,我知道我需要解决的问题,因此并非所有信息都必须包含在每个可视化元素中。结果很粗糙,而且 *太* 冗长,但它确实做到了
- 向我展示关键部分及其关系,特别是嵌套指令。
- 包括有关方法或 $scope 属性所在位置的有用信息。
- 提供每个项目所在的目录的指南。
它并不漂亮,但这是结果
它表示代码中一个相当复杂的部分,而拥有图表至少在四方面有所帮助
- 通过进行创建图表的过程,我以有序的方式学习了所涉及的各个部分——而且我不必尝试在进行的过程中记住整个结构。
- 我得到了我需要的总体视图。
- 在开发过程中,它非常有用,尤其是在工作被打断,我不得不几天后才回来继续工作的时候。
- 完成工作后,我将其添加到我们的内部 WIKI 中,以便在未来更容易地了解该区域。
我认为下一步可能是通过添加以下内容来定义和扩展可视化词汇表
- 用于标识指令、控制器、视图等的独特形状或图标。
- 标准化如何表示不同类型的关系,例如 ng-include 或指令引用的视图。
- 标准化如何表示异步操作。
- 添加模型的表示。
正如我在开头所说,这很粗糙,离完整还很远,但它确实为我证实了拥有针对 JavaScript 开发定制的绘图约定的潜在价值。特别是,它验证了对健壮的可视化 DSL 的需求,用于探索、解释、指定和记录 Angular 应用程序。
关于 David Aden
我在高科技行业工作了 20 多年,其中大部分时间都在从事与 Web 相关的项目。目前,我正在合著 Manning Publications 的《AngularJS in Depth》(http://www.manning.com/aden/),这让我在工作之余非常忙碌。白天,我在 Salesforce 工作,负责开发 Desk.com 支持代理的下一代 Angular 版本。
关于 Robert Nyman [名誉编辑]
Mozilla Hacks 的技术布道者和编辑。发表关于 HTML5、JavaScript 和开放 Web 的演讲和博客文章。Robert 坚信 HTML5 和开放 Web,自 1999 年以来一直在从事 Web 前端开发工作——在瑞典和纽约市。他经常在 http://robertnyman.com 上写博客,喜欢旅行和结识新朋友。
4 条评论