揭秘在预算内按时完成软件即服务 (SaaS) 应用程序的 10 个有效技巧，实现令人满意的投资回报。
以在线服务形式（而不是基于桌面应用程序的形式）提供的软件继续以指数级别增长。我参与过许多公司 SaaS 项目的开发。基于这些经验，我总结出 10 个软件开发的关键要素，这 10 个要素可以确定一个 SaaS 应用程序的成功，很多情况下，还能确定它的发行。这些技巧旨在为您的 SaaS 开发指明方向。
常用缩写
API：应用程序编程接口 DTD：文档类型定义 UI：用户界面 XML：可扩展标记语言
1. 让UXD成为最有价值的资产
随着 Internet 的出现，对用户体验的关注也逐渐被抛弃。但是，近几年来，有清楚的迹象表明，用户体验又重新成为成功软件的重要特征。这次回归的标志是术语 Web 2.0 的流行，该术语最终变得更有意义：富 Internet 应用程序（RIA）。在本文中，我有意将用户体验设计（UXD）放在第一位，因为用户体验是计算机用户选择一个应用程序最先考虑的特征。
图1和 图2展示了两个有趣的 UXD 技术。图 1 演示了页面保留（stay on the page） 的概念。因为这是一个使用 Adobe® Flex 构建的瘦 RIA 客户端应用程序，所以很明显没有任何页面。但是，这项技术仍然有效。用例场景：希望更改其个人帐户设置的用户。将显示一个叠加窗口，而不是保留应用程序的当前状态（或页面），允许用户做出必要的更改，然后关闭状态并返回手头的任务。
图 1. 称为页面保留的 UXD 技术示例
人与计算机之间的交互
在 Forrester Research 有关人与计算机交互的调查中，大部分被调查者提供的答案都将可用性作为他们选择一个应用程序的主要原因。在我经历的所有成功的 SaaS 项目中，可用性测试都放在初始程序设计过程之前。我还看到一些公司甚至进行抽样调查，让用户完成对静态映像文件的调查表。这是因为进行软件大修的成本非常高。在设计和原型制作阶段进行额外的调查可以为公司节省上百万的资金。开发团队还可以确定人与计算机交互趋势、特点、特征，以及市场对该阶段开发的喜好。
图 2显示了图 1 中窗口的关闭视图，但使用了两种模式。该用例更加具体：它假定用户希望更改 Company Information 值，因此选择对应的标题栏。窗口 1 显示了第一次出现时窗口的状态。图 2 显示了用户单击 Company Information 栏之后的窗口状态。该技术称为折页菜单（accordion menu），因为选择相应的标题栏时面板就像折页一样展开和收缩。这种行为增强了用户体验，因为在必须对许多设置进行分类时，它使用户能够更快更轻松地定位和更新一个或多个值。
图 2. 折页面板
2. 适应更改要求
如果说软件开发中有什么必然性，那就是客户端、顾客或产品所有者在完成所有设计、规划、图表和原型制作后，他们将更改项目的要求。大部分项目经理都经过传统的培训，限制更改是这种培训的一部分；这可能会影响产品第一个官方版本的发行。
软件开发的演变速度非常快，以至于在初始开发过程的整个生命周期中，您会发现核心项目管理方法会改变好几次。因此，每个项目都应该准备好实现新的开发方法或者现有方法的后备方法。
3. 采用开放标准
基于 SaaS 的公司必须考虑采用开放标准，这样在将来迭代时，与其他设备、平台、服务和 Web 应用程序的兼容所需的代码编写工作将更少，也将获得更多的用户。采用 SaaS 应用程序的消费者将使他们能够完成多项工作。例如，图 3 展示了一个跨平台应用程序 TweetDeck，它在一个界面中同时使用 Twitter 和 Facebook 开放 API。TweetDeck 很快将成为最流行的 Twitter 客户端之一，因为它允许 Twitter 用户同时查看其 Facebook 好友的更新状态而无需切换应用程序。
图 3. 流行的 TweetDeck 应用程序同时使用 Twitter 和 Facebook 的开放 API
社区的力量
当结束一个软件项目时，开发该软件的公司或个人常常会向开源社区投稿。这可能包括完成某项任务所需的定制代码库，或者一组可以修改并用于其它地方的可重用软件组件。对开源工具的这种持续贡献培育了这样一种环境 —— 技术可以快速持续地自由发展。
使用基于开放标准的工具可以大大降低公司的财务成本，因为没有许可证费用，资源的成本也很低，所以与从头构建相比，您所在的起点就更高。然后可以分配资源以修改源代码，以满足业务的需求和更改。例如，TweetDeck 的作者关注应用程序中的用户体验特性，而不是处理 Twitter 和 Facebook API —— 这会很繁琐。
试想一下：如果 Twitter 和 Facebook 对使用其 API 收费会发生什么？TweetDeck 可能必须每月向顾客收取使用费，以便公司能够支付使用 Twitter 和 Facebook API 的费用。也可能用户必须向 Twitter 和 Facebook 支付月费才能使用 TweetDeck 应用程序。这对 TweetDeck、Twitter 和 Facebook 都是不利的，TweetDeck 很可能不再是一个成功的 SaaS 应用程序。
4. 设计之前做好线框
从功能的角度看，线框（wireframe） 只是软件程序 UI 特定状态的形象概念，如图 4 所示。注意，不要设计细节。这样做的目的是避免被设计元素转移注意力，使关注点停留在业务功能方面。应用程序的业务工具确定了之后，设计团队就可以接手了；但在美化软件之前必须先设计好功能。
图 4. 线框提供了 UI 的形象概念
该方面与成功 SaaS 的第一个要素 UXD 关系密切。不同之处在于，要想 SaaS 能够成功，UXD 必须是整个软件开发生命周期（从概念到生产）的一部分。在线框制作方面，我发现有两个错误可能导致 SaaS 的失败：
团队进入设计过程的速度太快，创建应用程序的设计主题突然成为线框制作过程的一部分，因为股东希望软件看起来漂亮而不是有用。 在线框收集过程中遗漏了应用程序的关键状态（即只为部分应用程序制作了线框）。
有趣的是，第二个错误对于 SaaS 项目的危害最大。线框最有用的地方在于，您可以依赖它们展示对产品要求理解的不同。在开发开始前，它们可以很好的表现核心架构设计依赖关系。明白了这一点，就不难理解为什么说完整的线框制作流程可以为公司节省许多时间和资源。
完整的线框集可能包含 100 多个文档。每个线框都应该有一个至少一到两页的描述，以帮助股东在评审线框时理解他们眼前的内容。记住，这些线框在股东签名前需要修订。最好在线框制定期间确定差别，不要等到编写了功能代码之后。
注意：设计过程之后，定义 UI 的完整文档集往往称为图书（picture book）。
5. 为 SaaS 提供云基础设施
首先，傻瓜都知道网络基础设施对 SaaS 影响巨大。但是，Web 上大部分 SaaS 应用程序运行的基础设施硬件都不充足，无法根据需要扩展。作为开发人员，我们可以使用自扩展的云系统 —— 常常称为 Infrastructure as a Service (IaaS)，但这种高级技术的推广速度很慢。
该技术的采用范围不广很大程度上是因为缺乏该主题的知识。例如，Amazon Elastic Compute Cloud (Amazon EC2) 可以给运行 SaaS 应用程序的公司带来很多节省，但是对 Amazon Web Services (AWS) 基础设施知识的缺乏使许多公司回退到遗留系统，因为那才是他们所了解的。但是，ISP 提供带宽的不断增长为成功 SaaS 应用程序提供了保证，自动根据需要扩展资源的 SaaS 应用程序需要更高的网络性能。
6. 开始编写代码之前生成完整的设计文档
软件与公司的运行原理是一样的，成功 SaaS 公司的主要特征是开发过程的规划阶段非常完善。高质量的设计文档将作为负责执行设计的开发人员的路线图，并可以加速软件后续的代码编写工作。这就是为什么成功的 SaaS 应用程序往往都是在预算内按时完成的项目。
SaaS 应用程序超出时间并超过预算往往是由于项目架构设计原则缺少交流。要在整个大型 SaaS 应用程序中维护代码的一致性，关键是要建立完整的应用程序设计模式和转换集，并让整个开发团队有效的沟通。这些原则交流的一种有效手段是使用视皮层。
使用视皮层
经过 100 多年对人类思维和学习的大量研究表明，在学习过程中投入五感中的一种以上即可学习的更快。投入视觉和听觉将使学习者记住某个问题的效率提高近 6 倍。所以，在技术软件文档中，图表和流程图之类的视觉信号非常有效。
如图 5 所示，软件架构和微架构图对于建立和交流 RIA 客户端的基础非常有用，它为开发团队提供了组织代码编写时应该遵守的框架。从结构化角度看，这些图还建立了一组指南和预期。
图 5. 程序结构设计模式松散的高级视图
流程图对于传递事件流和序列非常有用。在大部分情况下，您越有创意，流程图就越有效。图 6 演示了一个充满创意的流程图，用于描述开源 Swiz Framework for Flex 如何实现反向控制 (IoC)、对象自省和依赖关系注入。
图 6. 开源 Swiz Framework for Flex 流程图
如果您曾经协助过或参与过方法模式的归档或创建，那么您应该熟悉图 7 所展示的图。它对于展示存在多种可能的过程或方法非常有用。例如涉及多个函数的过程，有些过程包含多个条件，如 if - else 和 switch 语句。功能描述图对于概述技术业务流程和软件非常方面。例如，描述向公司中央源代码控制存储库提交代码的流程就可以选择这种图。
图 7. 功能描述图，用于概述整个条件过程或方法
6. 开始编写代码之前生成完整的设计文档
软件与公司的运行原理是一样的，成功 SaaS 公司的主要特征是开发过程的规划阶段非常完善。高质量的设计文档将作为负责执行设计的开发人员的路线图，并可以加速软件后续的代码编写工作。这就是为什么成功的 SaaS 应用程序往往都是在预算内按时完成的项目。
SaaS 应用程序超出时间并超过预算往往是由于项目架构设计原则缺少交流。要在整个大型 SaaS 应用程序中维护代码的一致性，关键是要建立完整的应用程序设计模式和转换集，并让整个开发团队有效的沟通。这些原则交流的一种有效手段是使用视皮层。
使用视皮层
经过 100 多年对人类思维和学习的大量研究表明，在学习过程中投入五感中的一种以上即可学习的更快。投入视觉和听觉将使学习者记住某个问题的效率提高近 6 倍。所以，在技术软件文档中，图表和流程图之类的视觉信号非常有效。
如图 5 所示，软件架构和微架构图对于建立和交流 RIA 客户端的基础非常有用，它为开发团队提供了组织代码编写时应该遵守的框架。从结构化角度看，这些图还建立了一组指南和预期。
图 5. 程序结构设计模式松散的高级视图
流程图对于传递事件流和序列非常有用。在大部分情况下，您越有创意，流程图就越有效。图 6 演示了一个充满创意的流程图，用于描述开源 Swiz Framework for Flex 如何实现反向控制 (IoC)、对象自省和依赖关系注入。
图 6. 开源 Swiz Framework for Flex 流程图
如果您曾经协助过或参与过方法模式的归档或创建，那么您应该熟悉图 7 所展示的图。它对于展示存在多种可能的过程或方法非常有用。例如涉及多个函数的过程，有些过程包含多个条件，如 if - else 和 switch 语句。功能描述图对于概述技术业务流程和软件非常方面。例如，描述向公司中央源代码控制存储库提交代码的流程就可以选择这种图。
图 7. 功能描述图，用于概述整个条件过程或方法
6. 开始编写代码之前生成完整的设计文档
软件与公司的运行原理是一样的，成功 SaaS 公司的主要特征是开发过程的规划阶段非常完善。高质量的设计文档将作为负责执行设计的开发人员的路线图，并可以加速软件后续的代码编写工作。这就是为什么成功的 SaaS 应用程序往往都是在预算内按时完成的项目。
SaaS 应用程序超出时间并超过预算往往是由于项目架构设计原则缺少交流。要在整个大型 SaaS 应用程序中维护代码的一致性，关键是要建立完整的应用程序设计模式和转换集，并让整个开发团队有效的沟通。这些原则交流的一种有效手段是使用视皮层。
使用视皮层
经过 100 多年对人类思维和学习的大量研究表明，在学习过程中投入五感中的一种以上即可学习的更快。投入视觉和听觉将使学习者记住某个问题的效率提高近 6 倍。所以，在技术软件文档中，图表和流程图之类的视觉信号非常有效。
如图 5 所示，软件架构和微架构图对于建立和交流 RIA 客户端的基础非常有用，它为开发团队提供了组织代码编写时应该遵守的框架。从结构化角度看，这些图还建立了一组指南和预期。
图 5. 程序结构设计模式松散的高级视图
流程图对于传递事件流和序列非常有用。在大部分情况下，您越有创意，流程图就越有效。图 6 演示了一个充满创意的流程图，用于描述开源 Swiz Framework for Flex 如何实现反向控制 (IoC)、对象自省和依赖关系注入。
图 6. 开源 Swiz Framework for Flex 流程图
如果您曾经协助过或参与过方法模式的归档或创建，那么您应该熟悉图 7 所展示的图。它对于展示存在多种可能的过程或方法非常有用。例如涉及多个函数的过程，有些过程包含多个条件，如 if - else 和 switch 语句。功能描述图对于概述技术业务流程和软件非常方面。例如，描述向公司中央源代码控制存储库提交代码的流程就可以选择这种图。
图 7. 功能描述图，用于概述整个条件过程或方法
7. 抱住单元测试不放
神秘数据转换器案例
在编写执行某些数据计算和转换功能（显示 “Last week” 和 “yesterday”）的代码之前，我的同事编写了一个测试用例。在完成测试用例之后，他编写执行功能的代码并对其进行测试。奇怪的是，该方法在上午 12:01 a.m. 和 11:59 p.m 之间可以通过，但是在上午 11:59 到正午之间却神秘地失败。
这里有个大问题，如果不是进行持续、重复、每小时执行的测试，能发现这个 bug 吗？周期性的手动测试能够发现它吗？QA 团队能够发现它吗？真正的问题在于，很可能在未处理该 bug 的情况下将该应用程序直接交给客户，如果该应用程序投入生产，很可能会毁了 15 年的生意关系。
一般来说，SaaS 的领跑者往往是许多人构建的大型应用程序。大型应用程序的单元测试中，数据总是一致的：在后期执行单元测试的项目总是惨败。与此相反，成功的 SaaS 开发人员在编写代码之前运行单元测试。例如，如果我要编写一个名为 ServiceController 的类，我不会直接开始编写该类。相反，我编写根据类中的方法运行所有单元测试用例的类。接下来我甚至会进一步运行测试用例，尽管我知道它们将失败，因为我没有为该类编写任务代码。
这样做的目的在于，排除单元测试中出现 bug 的可能性，保证总是能通过单元测试。一般来说，很容易无意中犯这个错误。如果所有单元测试都失败，我就可以开始编写实际代码了。当我完成新类的编写时，我将再次运行单元测试。只要通过所有的测试用例，我就将向单元测试自动库添加新的单元测试类，在每次构建时运行。换句话说，我为应用程序创建的整个单元测试库都成为构建流程的一部分。实际上，在我每次开始构建项目之前，都将运行所有的单元测试，以确保应用程序代码的完整性没遭到无意破坏。
在编程的世界中，我发现只有几个开发人员严格遵守该过程。但是，他们都是行业内最受尊敬的、最具声望、身价最高的开发人员。如果您想知道提高身价的捷径，请坚持单元测试。
8. 不要只见树木不见森林
SaaS 应用程序可能出现的性能瓶颈要比桌面运行的 “胖” 客户端应用程序大的多。即使是老练的程序员也承认，在 SaaS 应用程序中，有时性能瓶颈很难预测，因为涉及的变量太多。成功 SaaS 应用程序和失败应用程序之间的不同在于加载测试和分析过程中开发团队对有害性能的响应方式。
一般来说，只有两种性能优化：对性能产生极大影响的优化和几乎没什么影响的优化。很难遇到位于两者之间的优化。这里常用的一个比喻是树木和森林。大部分情况下，开发人员花了很多时间提高性能，但只是在原地踏步，却没有解决运行应用程序时计算机处理器或内存完全占用的大问题。作为一名程序员，如果太关注树木，您将看不到森林。
防止被树木吸引眼球最简单的方法是分析您的应用程序。分析是成功 SaaS 项目的重要部分，因为它能够优化应用程序使用系统资源的方式，如图 8 所示。分析应用程序时，您能够看到应用程序的哪个部分占用了大部分资源，并实现设计模式以提高性能。例如，您可能会发现许多对象重新实例化没有必要的垃圾收集，这会导致应用程序停止后将继续占用内存，那么就有必要实现带代理的对象池。
图 8. 在 Eclipse 中分析应用程序
9. 学习其他成功的 SaaS 项目
从其他成功 SaaS 项目中学习最简单的方法是首先挑选一个乐于使用的 SaaS 程序。然后，找两个或三个所选软件的竞争对手，然后试用一下，写下吸引您注意的具体内容，以及为什么您喜欢或不喜欢某个应用程序。
在可用性和性能方面，很少有应用程序能够吸引我的注意，所以如果出现这种情况，我一定会花时间了解原因，因为我常常能从中学到一些东西。最近有一款任务管理应用程序吸引了我的注意，往往是因为它太乏味了。但是，该特定 SaaS 应用程序的可用性水平引人注目。
我花了近两个小时浏览该应用程序，测试它的限制和评估其大量特性的可访问性。我喜欢具有大量内置能的应用程序，但是我希望它们都是轻量级的。出于这个原因，我对 UI 设计很苛刻。如果界面的组织不够好，功能众多的应用程序只是一场噩梦，因为一半时间都在寻找您需要的功能。对该 SaaS 应用程序的评估让我得出结论，与我安装的其他任务管理应用程序相比，它具有独特而不落俗套的 UI 组织方式，我很喜欢。
10. 构建可用原型
如果用来构建原型的代码也用来创建最终产品，那么它还是原型吗？
答案是肯定的。在软件开发中，顾客通常希望在投资实际开发之前先看到对概念的验证。原型只是一个概念验证。聪明的 SaaS 开发人员会利用创建原型的时间。想想这段时间能做多少工作：
设计并布局架构基础。 通过构建定制 XML DTD 创建 SaaS 数据库模式，并使用 XML 作为原型的数据源。（模式稍后可以导入数据库引擎并在几分钟之后转换为实际内容）. 创建完整大小应用程序的组织包、界面和类结构，即使这些文件的作用只是声明最初实现的类名称和接口。
这种方法的优点很多，但是有两点对于 SaaS 的成功很关键：在构建实际产品时您已经领先很多；在此基础上构建原型时往往能够看到设计模式的冲突以及架构设计的不足。在实际开发产品之前，可以做必要的修改。
结束语
必须意识到，软件开发世界的变化日新月异，因此成功 SaaS 开发的关键要素最终也会发生变化 — 可能很快就会变化。跟上变化的秘诀是时刻更新自己的知识。