不要脱离实际环境

  有时，我们会因为读到一篇文章或一本书，或者看到一个感觉不完善的介绍而变得异常偏执。在每种情况下，人们只讨论一些技术、解决方案和选项的某些方面，而忽视了一个至关重要的问题：非功能性需求。

  诚然，功能性是非常重要的。毕竟，如果您不能展示您构建的系统实现了您想要的功能，那么谁会有兴趣呢？采取一种新颖、巧妙、更简单、更漂亮或更得体的方法来解决某种问题固然很好，但是如果您没有考虑非功能性需求，则您的解决方案可能无法取得实效。

  我们都碰到过这样的情况，许多解决方案虽然合理，但是当真正考虑将它们用于大型系统的实际环境，而管理这些系统的人员又非常忙时，它们就变得很荒谬可笑了。造成这些灾难的原因是不重视或忽略了系统的非功能性需求。

  非功能性需求是这样一种需求，它不一定解决“我想要我的系统实现这种功能”，而是解决“如何使这个系统能在实际环境中运行”。对于这些实际环境，您很少听到人们提及的一些问题是：

• 对在线系统的请求过多：用户太多了，全都在一块了！
• 部署应用程序的管理员负担过大：在实际环境中，管理员对每个应用程序都将部署多次，而在部署之后必须对每一个应用程序进行监视。
• 管理员会犯错误：毕竟，我们大多数都是普通人！虽然无差错地执行100 次手动部署步骤在理论上是可能的，但是实际环境中没有出现过。
• 会有恼人的脚本小子 (script kiddy) 和真正的破解高手攻击我们的系统：安全是多么重要啊！

  所以，什么是非功能性需求呢？我们可以找到许多很好的定义，不过，我们首先来看Software Characteristics的ISO 9126列表；除功能性（这是理所当然的）以外，这些特性包括：

  可靠性

  只显示系统可以做某些事情是不够的。如果一个系统不能可靠地运行（例如，在加载时，或者在系统故障时，等等），则它就不能满足客户的需要。

  有一些问题应该自问一下：

• 即使硬件出现故障，系统也可以可靠运行吗？
• 复制和故障转移方案是什么？
• 需要手动干预，还是系统可以自动进行故障转移？
• 实现可靠性会对性能造成负面影响吗？
• 实现可靠性的成本有多高？

  可靠性需要考虑的一些具体方面是：

  安全性：假设攻击者就在外面。如何知道系统用户就是他们所声称的，并只让他们访问经过授权的功能？如何保护我的系统不受攻击？考虑到网络攻击、机器攻击，甚至从您自己的系统内部发起的攻击。

  事务性：如何设计系统来保存工作单元的 ACID 属性？如果在设计中涉及多个独立的子系统（Web 服务和 SOA 就是这种情况），则这一点就显得特别重要。不要假设始终可以进行两阶段提交 (two phase commit)。

  可用性

  如果用户不能够从他们可用的渠道（例如 Web）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，但是常常被忽视，以致于整个项目处于危险之中。这里需要考虑的一些问题是：

• 您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？
• 系统是否根据模型-视图-控制器 (Model-View-Controller) 体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？
• 是否界面本来就有状态而功能无状态（反之亦然）？

  有效性

  如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。我们经常发现将有效性划分成两个子范围是很有用的，这两个子范围都应该加以考虑：

• 性能：这个系统的运行情况有多好？它只是平稳缓慢地运行吗？系统可以达到其响应时间目标吗？应用程序的设计是否符合性能要求？您利用缓存了吗？
• 可伸缩性：如果系统在小范围内运行看起来相当快，那么当扩展至每秒、每分钟或者每小时几千或成千上万个活动的时候呢？它的设计是否达到吞吐量目标？可以复制系统来实现线性扩展吗？是否存在瓶颈（例如公共数据库）？

  可维护性

  这是一个极其重要的需求，因为如果开发人员、管理员和操作人员不能够解决如何管理应用程序的问题，则它在首次发布之前就会夭折。假设您是一位管理员，您承担了解决此问题的任务，那么您如何配置它？如何监视它？如果您一件事情需要执行很多次（例如，安装许多应用程序），那么会怎么做呢？您是否有一个可复制的部署流程呢？您是否可以使重复的任务自动化，使之在大范围内可行呢？

  可移植性

  虽然列在最后，但它并非最不重要。例如，如何采用标准来提供某种形式的平台中立性呢？是否计划将应用程序迁移到您的最新和最高版本的应用服务器上呢？如果不打算这样做，则当供应商撤消对该版本的支持时您要怎么做呢？如果您的项目基于开放源代码，则也有类似的问题。如果每当某人有个更好的捕鼠器 (mousetrap) 您就必须重写整个应用程序，则没有人会问津。

  在完美的世界中，我们希望每篇文章、论文、红皮书、幻灯片和系统设计都率先解决这些重要问题。它们非常重要。差不多始终都要进行一些折衷，它们应该显式进行以便确定特定的设计是否符合您的需要。如果您阅读的文章没有解决这些问题，将这作为我们的警告——一些重要的东西往往会被忽视。如果您是一位作者，请考虑我们的恳求：不要忽视这些问题！