打造企业Flex团队

目录

• 选择角色
• 行动号召
• 延伸阅读

如果时间和资源充足，打造一个一流的Flex团队看起来不是什么难事。然而，Flash平台是一头不寻常的怪兽——吸引着来自非常不同的背景的开发人员，从旧Flash Pro能手到头发斑白的Java老兵。集中一致的技能来形成高效且井然有序的团队可能是一项艰巨的任务。

本文既适用于希望在企业范围内组建一个团队的经理，也适用于渴望提升他们的技能以适合大型、复杂项目的开发人员。我将介绍Flex社区内一些通用的技能，展示如何结合使用这些能力来为您的新项目打造牢固的基础。在这之后，我将介绍您的团队在运作期间必须做出的一些与工具、自动化和最佳实践相关的关键决策。

注意：此规模的项目一定会受到许多外部因素的影响。这些因素包括组织内现有的基础设施、品牌/样式指南、支持的工具和框架、当前的流程，以及上游系统等等。尽管所组建的开发团队会为工作建议最佳工具，许多决策仍需要得到在政治上会满足团队构建最佳产品之所需的经理的支持。诚然，甚至在团队内，也需要不断访问产品负责人，他们可从业务角度明确地判断团队是否和何时发现自身进入僵局。没有这些流程，团队的生产力和项目本身将受到影响。

选择角色

尽管每个可能的团队成员拥有独特的专长和兴趣，但也都存在固有的知识缺陷。出色的团队应该突出所有这些优点，而改进缺点。集中正确的元素来最充分利用该平台，涉及到在整个团队协调这些优势，确保拥有富有挑战、相互尊重且充满刺激的气氛——进而不仅创建了有效的产品，还改进了团队的个人和集体能力。

以下是在打造团队时要重点关注的一些关键技能区域：

注意：这些技能绝不应相互排斥，事实上，很可能您有团队成员表现出了其中的许多特征。

• 可视化人员

任何业务线应用程序都会需要非常多的数据表格、自定义itemRenderer和图表组件。尽管任何有能力的Flex开发人员可能使用过表格和itemRenderer，但如果团队中至少有一位专家，将会获得长期的回报。您的数据可视化专家的眼光将超越普通的表格和图表。结合优秀的用户体验（UX）团队（我稍后将介绍），可视化人员可以创建一些真正独特的体验，使您的应用程序迅速从竞争者中脱颖而出。这种增值很容易被您的最终用户量化，并在不久之后产生效益。

• 管理人

管理人员专门负责自定义控件（比如数据驱动的容器和布局）的细粒度管理，组件生命周期属于管理人员的职责范围。管理人员通常知道所有主要控件的内部工作原理——它们可以轻松地绑定数据——他们可能也会兼任可视化人员的某些职责。如果仔细地审视新功能区域，组件专家（尤其是拥有数据驱动设计经验的专家）将会创造奇迹。

• 播放人员

播放人员是您常任的Flash Player专家，广泛参与过所有支持平台上的Flash工作。因此，您的播放人员通常会理解Flash Player自身内的特征，以及如何最佳地利用该指示来为团队服务。同样属于这一职责范畴（但常常贯穿整个团队）的是应用程序配置和性能测试，预防内存泄漏，以及改进CPU使用。

• 科学家

您团队中的每个人应该熟悉面向对象编程（OOP）且理解抽象、多态性和松散耦合的价值。尽管很重要，但设计模式没有像对OOP的牢固理解和从给定问题领域映射对象模型那么重要。也就是说，在最低限度上，每个成员应该牢固理解模型-视图-控制器（MVC）架构和依赖注入（DI）。科学家将通过重构低效的代码，以及通常找到困难问题的“干净”解决方案，“减掉您应用程序的赘肉”，从而带来增值。科学家常常可以轻松地可视化问题区域，创建图表来描述复杂的交互性——在培训新成员时也很有用。科学家可能无需拥有扎实的Flex背景，但应该能够将软件工程最佳实践应用到应用程序中。

• 协调人员
  协调人员是您的服务专家。协调人员专门负责Flex与服务层（整合服务集合，客户端通常通过它通信，它通常会抽象下游应用程序）之间的通信。这涵盖从简单的HTTP和XML请求到更有效的二进制传输协议，比如AMF（用于Flash Remoting）和RTMP（实时消息传送协议）。如果由于存在大量的并发用户，应用程序必须处理大量实时数据并处理并发性问题，对消息以及Adobe LiveCycle Data Services (LCDS)的熟悉将大有帮助。如果协调人员拥有服务层基础架构的第一手经验将很有帮助，他或她也将从理解实现的特征也很有帮助。确实，Negotiator很可能具有面向服务的背景。
• 创作者
  您的创作者是团队的框架讨论和最佳实践的执行者。创作者熟知所选的一个（或多个）框架的所有功能，了解自定义和扩展它来适合大型模块化应用程序的方式。通过使用他们的专家经验，您可以最充分地利用微型架构，在整个项目中同时实现明确性和一致性。良好的框架使用也将减少冗余的代码，改进应用程序对新开发人员的可访问性。
• 构建者
  构建者将管理您Flex应用程序的自动编译。随着项目规模的增大，构建脚本的复杂性也会增加。依赖关系管理、资源配置、代码优化、自动化单元测试和代码覆盖率报告都属于构建者的职责范畴。一些团队选择将此职责转交给服务器团队，因为他们常常更加熟悉自动化的构建管理。
• 架构师
  架构师通常在所有区域都拥有扎实的技能，但框架、OOP和服务专家将有所帮助。架构师将审视整个团队（或多个团队），并建立整个项目的核心模块/包结构对应关系。与框架专家合作，架构师将提供一种可靠且一致的方法来在各种模块之间通信。他们将创建一个强大且可靠的开发环境，其中每个开发人员可轻松构造、重新处理和重新构建各种模块，而不会影响其他团队中的工作。他们也将与服务团队紧密合作来创建一个一致且可靠的API，爷爷可使用它进行交互。

此外，您的全明星开发团队中还将有一个强大的用户体验（UX）组件。这里不会介绍UX的细节，因为仅仅全面的概述就需要一篇文章的篇幅，不过有两个主要角色需要着重说明一下：

• 设计/UI：创意设计师
  创意设计师的工作是开发应用程序所依靠的详细的插图。创意设计师常常会在Photoshop或Illustrator中完成此作品，并将它传递给集成者。
• 设计/UI：集成者
  集成者是创意设计师与团队剩余成员之间的桥梁。在过去，这是通过Flash创作工具（包含在Creative Suite中）来实现的，可视地构造随后会编译并提供给团队的资产和皮肤。然而，，随着Spark和Flex 4中新的皮肤模型的出现，该流程现在围绕Flash Catalyst进行了改进。在本质上，该工作流包括导入插图、调整它，以及将它转换为然后会到处到一个封装的XML格式的组件，开发人员可轻松将该格式集成到他们的环境中。顺便说一下，这个迅速成长的角色也通过Expression Blend广泛应用到了Silverlight中，是两种平台相对于HTML5的一项巨大优势。

注意：Web模式的UI团队可能无法直接适应富Internet应用程序（RIA）。而网站通常是静态的（除了高度动态的启用了Ajax的Web应用程序），Flex应用程序是多状态的，并且无需重新加载页面即可处理操作。可以需要一定的培训指导来将现有的Web团队过渡到RIA设计。

行动号召

组建团队只是第一步。新组建的团队将面临着许多关键决策，尽管每个人都将拥有自己的偏好和观点，但为解决一些问题做好准备也没有坏处。

以下是团队面临的一些比较重大的决策：

• 标准

您的团队将需要在编码标准上达成一致，而且可以想象，一致性至关重要。尽管这在处理新团队时很容易做到，但在不断添加新成员时很容易被忽略。这些决策不仅仅在于类和包命名约定。它们包含标准方法，从模块加载和通信战略、框架使用、单元测试覆盖率——一直到您团队使用的IDE选择和用于归档的Wiki。可以采用一些工具来确保新代码符合您的自定义标准——Flex PMD就是最常用的工具。

除了编码，标准可以采用客户端/服务器API、XML模式、构建管理、用户体验和文档的形式。这些标准应该具有良好的定义并在所有实践和交付结果上良好地执行，以确保整个项目上的一致性。

• 源控制

每个开发人员都拥有自己最喜爱的源控制风格——从CVS一直到Git。但是，您很可能会整合一个拥有自己的动机的服务器团队，而且最优秀的解决方案可同时涵盖客户端和服务器。在选择提供商时请留意分支和合并：项目越大，这些因素就会越重要。

可能影响决策的另一个因素是与集成源控制的丰富多样的工具。这些工具包括IDE集成（大部分主流提供商拥有Eclipse和IntelliJ插件）、代码评审软件和项目管理工具。具体来讲，后者有助于平复经常试图跟踪项目开发进度的BA的心情。

• 自动化测试

综合测试在现代软件开发中必不可少。自动化测试，结合优秀的质量保证（QA）团队，可确保新更改不会暗地里破坏过去的工作。尽管FlexUnit（未与Flash Builder捆绑）良好地提供了单元测试（必不可少），但自动化的UI测试可转化为一项竞争优势。就像代码重构或API更新可能破坏单元测试一样，更新的设计也可能破坏明确定义的单击路径和交互。尽管如此，您也可以通过大量选项来管理UI测试，FlexMonkey和QTP是其中最常见的两个

尽管Flex中的自动化单元测试得到了良好支持，但集成测试没有这么好的运气。事实仍然是，Flex中的自动化集成测试是一片富饶之地，每个团队可以自行确定收益是否高于成本。常常，QA部门和开发人员自身所执行的手动集成测试就足够了。

要考虑的最后一个方面是性能和负载测试——也就是分别测量应用程序的响应能力和容量。取决于业务需要，这可能是单个开发人员的工作范围，或者更确切地说是整个团队的职责。流行的工具包括HP的LoadRunner和WebORB的CloudPuncher。

• 构建自动化和依赖关系管理

几乎每个项目（尤其是敏捷项目）都会从持续集成获益。要支持这样的工作，构建自动化必不可少——换言之，专门分配一个服务器来定义构建和部署最新的应用程序版本。此流程将必须知道项目具有何种结构，以及存在哪些依赖关系，才能从脚本进行构建。

您团队中在用于构建和依赖关系管理（DM）的系统上一定存在一些竞争产品。两种主要的竞争产品是Ant（使用lvy进行依赖关系管理）和Maven（使用Flexmojos，构建Flex和AIR应用程序的事实Maven插件），二者都来自Java领域，都具有自己的优缺点。请记住，目标在于实现强健且灵活的解决方案，无论您采用何种方法，请确保每个人都在正常工作并知道所需的职责。

• 框架

尽管费时费力的框架辩论充斥着Flex世界，但一个（或多个）框架的选择无疑是一项重要决定。除了在应用程序内提供标准化的通信方法，框架的选择还会直接影响您团队的产出——同时包括容量和内容。Cairngorm 2（至少为vanilla版本）等旧有提供程序（尽管在社区中具有很高的知名度）在单元测试上已变得声名狼藉，而且随着您的应用程序开始扩展，它们会变得更难管理。另一方面，PureMVC（尽管非常便携）很容易使您的开发人员陷入花费过量开销来提供您应用程序从不需要的丰富功能的困境。

尽管如此，支持控制反转（IOC）的更现代的框架（比如Robotlegs和Parsley）是成熟且经过战争考验的提供程序，可在管理客户端架构方面增添大量价值。无论您的决策是什么，团队都需要识别、列出并遵守一种一致的方法。

• 服务

您围绕客户端/服务器通信的许多决策都将基于组织内的现有标准、来自架构师的发现，或同时基于二者。不过，Flash Remoting（通过二进制AMF协议在客户端与服务器之间发送强类型对象）一定是您将采用的唯一产品，而且这可以通过许多工具（主要为BlazeDS或WebORB）来实现。更加全面和强健的解决方案将利用LCDS，后者使用RTMP协议（因此使用Flash消息功能）和一种发布者/订阅者模型来将数据推送回连接的客户端。

• 集成

对客户端团队和服务器团队的处理绝不简单。鼓励团队在项目早期就一个API达成一致，这是确保每个人在服务端将提供的功能和交换期限上达成一致。完成之后，一个全面的API可确保客户端团队依照规则执行，无论服务处于何种状态。Flex中对服务层的快速模拟常常会避免服务器团队在同时处理他们自己的部分时的任何生产力损失。

• SDK选择

如果启动一个新项目，您可以接受使用过时的Flex 3的唯一原因是您的团队缺乏Flex 4的经验。第四版Flex中改进的皮肤和布局机制的生产力提升使这一决策变得很简单。除非拥有针对Flex 3的成功的业务案例，否则您的团队应该使用Flex 4和Spark。您也会从Flash Catalyst获益——它尽管很年轻，但仍然是一个富有前景的工具。Flex 4.5最近刚发布，它不但改进了RSL加载和移动支持，还首次公开了可设置皮肤的DataGrid。

延伸阅读

Flex对现代和大胆的开发人员都富有吸引力。为这个迅速发展的平台组建一个井然有序的专业人员团队，可在社区中获得丰富多样的工作背景和经验。如果专注于涵盖平台的关键区域，您将创建一个可利用Flex提供的最佳功能的可靠产品。请在开发过程中尽早留意阻碍和困难，您将可以在可预见的未来安全地发布、支持和维护您的应用程序。

关于更多信息，请访问Adobe的Flex相关产品的完整列表。

本作品依据Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License授权。

查看原文：Forging an enterprise Flex team