Doug McCune谈Flex开发

Flex社区的摇滚明星及Flex for Dummies一书的作者Doug McCune在本文中探讨了Flex的前景并分享了其对用Flex构建客户化组件的一些想法。此外，他还谈到了Flex 4的一些新特性及这几年社区所发生的一些变化。

InfoQ首先问到Doug最近在忙什么呢：

我正在 Universal Mind开发一款名为SpatialKey（ spatialkey.com）的产品，这是一款用于空间分析和商业智能的Flex应用。我们的目标是将人们放在电子表格中的数据抽取出来进行深层次的分析，因此如果你的Excel文件有多达50,000个数据（假如是销售报表），那么你可以将该文件上传过来并使用SpatialKey以时间线的方式查看过去几年的数据，甚至还可以根据每天的小时数进行分组以了解白天和晚上的情况。

除了这个正式工作外，我还积极投身于一些有趣的开源项目当中。当前我正在为5月份将于印第安纳波利斯举办的360|Flex上的演讲做准备。我的演讲主题是“酷”，届时我会与大家分享自己在Flex和ActionScript方面的一些经验，帮助大家探索其中的乐趣。最近我在人脸识别和脸部追踪领域投入了不少精力，同时还在密切关注着人们使用Flash所做的增强现实（augmented reality）工作，我希望能实现出几个漂亮的增强现实实验。

由于此前Doug曾开发过很酷的用户界面以及像SpatialKey这样的应用，于是InfoQ问到在典型的商业应用中能否使用Flex这些酷酷的特性：

企业软件确实非常麻烦，但这种烦恼却是我们自找的。现在的RIA设计正经历着一场“UX革命“，围绕着”用户界面“这个主题出现了不少没什么意义的新名词，但RIA的确为我们带来了与以往不同的体验。在消费性RIA应用中我们看到了一些很棒且具有创新性的成果，同时用户界面也趋于简单和直观。但在企业软件中，这种趋势才刚刚开始，企业软件还是太复杂了。我们希望人们能像对待消费性应用那样对待企业应用，关注用户界面，简化一切，让一切都变得直观起来。我们未必非得使用让人摸不清头脑的软件来展现复杂的系统，但要想实现简单且优雅的解决方案也绝非易事。要知道，相对于拙劣复杂的软件来说，优雅简单的软件更难得。

同时我认为一场商业智能（BI）的革命正在蓄势待发，这会将上述直观软件的概念带到商业智能领域中来。所谓商业智能其实就是以某种方式从原始数据中抽取价值的一种方式。一般来说以图表、量表或其它标准UI元素的形式表现出来。但我认为从一个全新视角，以一个企业软件局外人的角度来考量BI问题更有利于创新。或许以传统的量表来表示销售特征（sales performance）并不是一种好办法，但企业开发者却并不想尝试新概念。我们需要创新了。

接下来，InfoQ问到相对于其他语言/框架来说，使用Flex构建客户化组件有哪些异同点呢：

坦白地说，除了ActionScript以外，我没有太多的经验使用其他语言进行客户化的组件开发。我的Web开发之路是从Flash和HTML开始的，但那个时候JavaScript框架还没有像现在这么流行，这也就意味着你必须从头开始构建任何客户化的AJAX组件。从那时候开始涌现出了大量的JavaScript框架，它们替你分担了AJAX开发中的很多痛苦，但在我开始学习UI组件开发并在AJAX和Flash之间进行抉择时，我发现使用JavaScript开发组件实在是不怎么样。但我倒是想尽快掌握过去几年JavaScript社区所积累的开发资源，尤其是IDE和组件库。

依我看来，官方对Flex SDK的开源使得Flex框架成为客户化UI组件开发的首选。我认为Adobe/Macromedia总是发布Flex框架的完整源代码（甚至在官方宣布开源前）会对该产品和开发社区产生深远的积极影响。Flex框架的大小可能会吓到大家，但实际上它并没有那么可怕，其文档做的真的是相当棒，也是深思熟虑的结果。

接下来InfoQ问到如果想要构建高质量的客户化组件，开发者需要从Flex框架的哪一部分开始着手呢？

Flex框架中的任何”小“组件都是绝佳的学习资源。之所以将”小“加上引号是因为所有的组件都是基于UIComponent类，而这个类本身却是Flex框架中规模最大的一个类，因为它负责整个验证过程。但Flex框架最好的一个地方还是其开源性，因此如果你想了解Adobe工程师是如何做的，你可以直接查看其源代码（这很简单，只需在Flex Builder中按住Control键，然后点击相应的类就行了）。看看Button类吧，这是一个很好的起点，通过它可以了解组件的一些基本概念，然后再看看ComboBox（继承了Button）和CheckBox（也继承了Button）里面增加了什么新玩意，这样你就能明白为什么要继承类，基于现有的组件能够构造什么功能。

在Flex刚发布时并没有太多的资料讲述如何开发客户化的组件。那时我们只能凭借有限的文档来学习，然后深入到Flex源代码中，剩下的就靠自己了。时过境迁，现在已经有很多的资料讲解组件开发了，同时还有一些优秀的介绍和展示。每次观看客户化的Flex组件开发的展示时，我都感到这一切变得越来越棒了。Deepa Subramaniam在MAX上的演讲非常不错，该演讲涵盖了Flex 3组件的生命周期以及Flex 4新的组件架构（ 可以在线观看该视频）。

之后Doug谈到了客户化组件开发中的一些常见错误：

对于很多人来说，最大的问题是没有真正理解组件的生命周期。掌握这些内容需要花不少时间，但这不仅对理解Flex很有帮助，同时也能加深对底层Flash Player工作方式的理解。我在Flex大会上做过演讲，但很多人都表示我没有真正理解某些无效路由（invalidation routines）的使用方式（确实如此）。要想理解好该主题，首先需要实践，接下来就需要阅读大量代码，只有这样才能真正明白。尤其是invalidateProperties和commitProperties方法的使用，很多人都在这上面栽过跟头（当然我也不例外）。

人们在创建自己的客户化组件时所遇到的另一个大问题是他们没有花足够的时间阅读底层的源代码，这样就无法真正理解基类的工作方式。如果想要继承List或是其他一些类，那么你可能都不用管List类的底层实现方式（其底层非常复杂）。你无需了解Flex框架的每行代码，但却必须深入到Adobe代码中来解决遇到的问题。如果不想深入到底层源代码来调试，那么你将面对一个又一个问题，永无止境。

InfoQ接下来问到Flex 4的哪些方面令你拍案叫绝呢：

就像很多做过客户化组件开发的开发者一样，在Flex 4的组件架构计划刚发布时，我着实深吸一口气，说到“耶，这种方式好多了”。当前Flex 3的代码基已经非常强大了，但在进行客户化的组件开发时，你会接连不断的遇到同样的问题。Flex 4的代码基建立在Flex 2和3之上，取其精华、弃其糟粕。因此对于组件开发来说，Flex 4所采取的不同方式令我感到非常高兴。

我猜想Flex开发者和那些专注于组件开发的人肯定会静静等待，他们想看看Flex 4到底要如何变化，他们何时才能一试身手。Adobe很惊异地看到社区对于他们（Adobe）所作的工作已经是血脉喷张了。我可以从Adobe的源码控制仓库中检出最新构建的Flex 4 SDK以及最新的代码，这其实就是Adobe内部的工程师所使用的代码。这太爽了，但我觉得这对于Flex开发者来说还是有些为时过早了，因为还需要很长时间才能发布Flex 4，同时代码也会有比较大的变化。我当然希望在未来的6个月内，随着Flex 4的不断成熟，Flex开发者（当然也包括我自己）可以真正使用这些新组件。

接下来，InfoQ向Doug问到对于即将到来的Flex 4，其最关注的是什么：

我最关注Flash Catalyst及工具所生成的代码。凭借Catalyst，设计者可以拖拽漂亮的控件并组装成可运行的Flex应用而无需编写代码。但这对我却并不适用。我一向都认为再棒的工具所生成的代码也不如优秀的程序员手写出的代码质量好。无论是代码生成器还是所见即所得编辑器，他们都会产生丑陋的代码，而这些代码需要由经验丰富的程序员手工修改。另一方面，我曾经为一个咨询公司工作过，生成的那些丑陋代码意味着更多的事情（但这些却并不是我们想做的）。我打心里希望Catalyst到Flex Builder（反之也是）的流程能让设计者到开发者之间的工作平滑过渡，但我必须承认这么说要求有些高。或许我真的应该保持沉默，除非看到更棒的Catalyst之后再给出合理的评价。到那时我可能会感到震惊，因为结果比我想的要好的多。

然后InfoQ问到在过去的2年中，Flex开发和社区都有哪些变化：

这两年的发展实在是太快了。大约2、3年前Flex社区还是一片荒芜。大家都是从那时开始学习的，每个人都想展示一下自己的能耐。很幸运，我从一开始就走对了路。我觉得大体上（只是我个人看法而已）随着使用Flex的人的不断增加以及很多人都开始全职开发Flex之后，这一切才走上正轨。与此同时社区也发生了翻天覆地的变化。那时每个人都是从flexcoders的邮件列表上了解彼此。现在有这么多人在学习Flex，我可没法计算到底有多少人。当然这是件好事，因为这意味着Flex的受众已经很广泛了，但我却有点怀旧了。

最后，Doug给其他Flex开发者一些建议：

做好玩的东西。多做试验。让我震惊、嫉妒乃至于产生竞争欲望的东西越多越好。做一些酷酷的东西，让其他开发者夜不能寐，流连忘返。

请访问Doug的博客http://dougmccune.com来了解更多信息。

查看英文原文：Doug McCune on Flex Development