级别： 初级 Doug Phillips, 顾问软件工程师, IBM, Software Group
2009 年 8 月 26 日 
在尝试设计最佳解决方案时，保持事务的简单性可以帮助您控制成本、节省时间并避免出现长期问题。问题在于，虽然您已经意识到这点，但是当处于项目中期时，您已经脱离了对项目的控制，因而很容易忽视这些最基本的原则。本文将解释简单性设计背后的原理，以及为什么它的简单性优点常常优于主张 “越大越好” 的方法。
来自 IBM WebSphere Developer Technical Journal。
简单的就是最好的
我一直认为，如果可以令事务简单到所有人都可以使用它，那么人们都会去使用它。当我们试图找到一些新颖的方法来通过技术提供方便时，这个道理就变得越来越明显。在我的工作中，我的职责范围从应用程序架构设计到详细的规范设计，再到实际的应用程序开发。我尝试从简单性观点来审视所有这些内容。为了提供一个健壮的、令人满意的设计，有人认为您需要绘制一幅复杂的图表，包含集成的系统和多个复杂的、彼此连接的组件，如果不这样做的话则不会有任何意义。应用程序和系统架构师如今具备从 Internet 和 intranet 基础设施设计到多层冗余硬件和软件终端等广博的知识。当然，在一些位置应用这些技术是有意义的；银行业和 Internet 商务都是非常好的例子。但是，当用户实际应用这种技术并进行交互时，我发现整体架构中往往缺乏简单性。
在从头开始设计任何产品时，不管是 Web 应用程序还是简单的纸质盘子，最重要的一点是要考虑谁将会使用这个产品。如果您并没有认真考虑用户在使用该产品时的实际情况，而是关注复杂的架构图、一些花俏的东西和其他迎合管理团队的因素，那么这个产品很难获得成功。面对大量现有的架构设计和那些宣称可以帮助您减轻负担的规范，您很快会觉得不知所措。在我看来，大部分这类规范都尝试将所有可能的解决方案集中到一起 —— 这很好，但是却会导致这些规范变得庞大、笨拙，有时无法理解，而最终的结果是无法在实践中实现。如果您希望产品能够有用并且所有人都可以使用，那么最好保持简单性。
现在我将举例说明我的观点。
想想您每天都使用的东西，但是您可能认为是理所当然的：您的电子邮件。电子邮件有多简单？将您的想法写入到所选的电子邮件应用程序中，不管您使用的是 Gmail、Yahoo Mail、Hotmail、IBM® Lotus® Notes 还是其他应用程序，然后将它发送给您的朋友或同事。他们读取信件然后进行回复、删除，或者将邮件转发其他其他人。所有电子邮件客户机基本上都执行相同的操作：它们获取您写的文字并发送给一个服务器，后者再转发给其他人。电子邮件的创始人 Ray Tomlinson 提供了世界上最简单的架构设计之一，自从 1971 年以来很少进行过修改。即使是 @ 符号也一直沿用至今。归根结底：如果您希望所有人都使用您创建的东西，那么就必须提供足够的简单性，使所有人都能够使用。
“改进” 并非总是有益的
我发现如今的许多应用程序都试图将所有功能集中在一起，以至于最初的架构师也感到困惑。我曾经遇到过一个项目，该项目将需求渐变（scope creep）作为一种常见实践。我们的应用程序从一些小的但是非常有用（并且简单）的内容入手。有两名架构师/开发人员参与到这个高可视性项目中，再加上我和另一名同事。完成项目后，该项目可以按照预期的那样工作，并且没有多出任何多余的内容。由于具备简单的设计和易用性，因此该项目很快便流行起来。任何人都可以使用该系统并且在第一次运行时几乎没有遇到任何问题。当然，随着该应用程序的日益流行，它的可见性和效益也得到了增长。每个人都希望从中获益。团队成员很快增长到 18 名，并且增加了大量新需求。尽管提出了警告，但是这个项目仍然变得复杂起来 —— 它包含了大约 100 种新功能，数据量是原来的 4 倍，以及数不清的冗余服务 —— 人们实际上都不再使用该应用程序。问题出在哪了？
确实，它提供了有关人员要求具备的所有新数据和功能，但是问题在于 “每个人” —— 使用应用程序的人们 —— 不需要、不希望或者不要求提供所有这些内容。最终，我们被要求为应用程序编写一个帮助内容，因为用户再也无法像之前那样轻松地查找内容。曾经非常简单和实用的内容经过一段时间后变得非常复杂和不切实际。如果应用程序在一开始就保持简单性或是针对每组需求进行细分，那么上述错误就完全可以避免或得到缓解。
想象一下，如果电子邮件没有保持简单性的话，如今会是什么样子？当然，每个人都可以对电子邮件进行一些改进，并且这些改进可以帮助它随时间不断演变。但是，电子邮件的初衷一直未曾改变，这就是它至今保持流行和有用性的原因。
简单性的好处
遵循简单性设计实践会带来明显的好处，但是人们在考虑到这点时已经为时已晚。下面展示了在制定应用程序设计决策时应当首先考虑的三点建议：
-
简单性意味着容易修复
受到破坏的部件越少，对出现的任何问题进行故障排除所需的时间就越短。当然，我之所以从事这个职业，部分原因是因为人们无法修复已构建的内容。设计有时候会变得非常复杂，以至于没有人能够理解为什么有些东西可以持续工作。我常常将组件细分为更小的、更加可管理的组件来解决问题。大多数情况下，我认为那些可以从应用程序中移除的内容都会增加流程的开销。如果必须设计一个复杂的应用程序的话，那么尝试将各个组件保持独立。这绝对会起到长远帮助，并在发生问题时使您和其他人可以更轻松地解决。
-
简单性通常可以加快速度
和人类一样，应用程序需要服从信息流。它们采取各种步骤从一个位置到达另一个位置。包含的步骤越多，花费的时间越长。当然，您可以对应用程序使用更快速的硬件，但是，如果通过减少步骤的数量就可以获得相同效果的话，干嘛还要付出额外的金钱和时间。我在设计应用程序时，会尽量快速地从 A 步骤移动到 B 步骤。目前的应用程序常常会遍历一个常见总线或流程。就算在某些情况下存在这样的需求，也不要仅仅因为您认为这是最新的、最好的设计架构就将所有数据都通过总线。相反，想想在理论上和实践中是否有可能直接进入到另一个流程来节省时间和资源。如果您拥有一辆汽车的话，那为什么不自己驾驶汽车而是要站在路边等公车呢？
-
简单性可以节省资源
如果数据模型很小的话，那么它们在内存中占用的空间会更小。如果流程中涉及的步骤不多，那么就可以节省 CPU 周期以及设备中的电池电量。如果由于没有包含关键数据而避免了使用冗余系统的需求，那么就不要实现冗余系统。如果您知道最终只会使用一个或两个选项的话，那么何必要在架构中包含所有远程选项呢？通过为您已知的一个或两个需求提供 “刚刚好” 的功能，就可以节省 CPU 和内存资源，这些节省下来的资源可以更好地服务于应用程序的其他部分甚至是另一个项目。这种实践的附带好处就是可以显著地降低解决方案的成本。
简单设计举例
一些新项目和应用程序都着重考虑了简单性，它们并不一定会变得极其流行。相反，我们可以分享它们带来的简单性设计理念，并且可以从每个项目中吸取到应用此概念的经验：
-
Apple iPhone
去年年底，我决定看看当前到底流行什么，我将自己的 RIM Blackberry 换成了 Apple iPhone。我需要为这两者开发 Web 应用程序，并且已经对 Blackberry 感到很熟悉。熟悉 iPhone 的过程十分有趣。实际上没有手册可供参考，手机正面只有一个按钮，并且预加载的应用程序也很少，比如 Contacts、Settings、Photos、Mail、Maps 和其他一些简单程序。我一开始觉得自己做了个错误的决定。我很喜欢 Blackberry，因为它受到技术痴迷者的热捧，并且几乎可以提供所有功能！当然，我必须反复研究它提供的多个菜单层，但是这正是它的魅力所在！
是的，我严重低估了 iPhone 的潜能。把玩了几分钟后，我有了一些新的认识。首先，我根本不需要对它使用菜单。简单、直观的设计仅通过一些屏幕和手指操作就可以满足我的所有需求。其次，iPhone 为我提供了完整的手机功能：打出和接听电话，接收电子邮件和 SMS 消息，以及浏览 Internet。它真的非常简单。即使是设置屏幕也只显示了两三个页面，提供了开关机按钮和水平滚动条。Apple 将简单性概念提升到一个全新的高度。当操作系统的 3.0 版本发布后，即使是更新也非常微小，只是添加了首版中缺少的几个基本功能。该设备实际上可以完成很多功能 —— 那么何必要把这个可以提供丰富功能的设备复杂化呢？这是我在这里举的主要例子。
-
Twitter
这里再举一个好例子，它非常简单，任何人都可以使用它。Twitter 中的第一个简单性元素就是您能够作为数据输入的信息的数量，该数量被限制为最多 140 个混合数字和字母的字符。大多数数据设计师对这个数量限制感到无法理解 —— 即使是电子邮件也不会有这样的限制！即使一个标准的旧式字符串值也至少有 255 个字符。当然，这个限制在 Twitter 和 Short Message Service (SMS) 标准（160 个拉丁字母数字符合字符和 70 个双字节，后者是手机中使用的另一个简单的常见设计）之间提供了互操作性，但是正是这一限制提供了出色的易用性。
设计师是正确的。Twitter 中包含两个人员列表，您需要从其中一个获得更新，而另一个列表中的人员从您这里获得更新，当然，您可以将您的更新公开化。这就是奥妙所在。任何人都可以使用 Twitter。它很简单 —— 同样提供了速度 —— 但是它也非常强大，如果在正确的上下文中使用的话。由于它只占用很少的资源，因此可以在几乎任何手机上使用 Twitter。Twitter 再一次演示了一个简单性应用程序，它只完成设计中提供的功能 —— 不多不少 —— 这就是它的魅力。
-
IBM WebSphere sMash
作为一个 Web 开发平台，WebSphere® sMash 的一个独特之处就在于它的简单性。如果需要快速获得一个强大的 Web 应用程序并希望以一种简单的方式实现，WebSphere sMash 就是您的选择。由于它只占用很少的内存，并提供了简单的开发方法，因此成为了开发和运行 Web 应用程序的最快速、最简单的方法之一 —— 基本上只需要几分钟的时间。
首先，并不存在实际的应用程序 “安装”。如果您安装了 Java™，那么只需要将 WebSphere sMash 解压到任意目录。您为 WebSphere sMash 开发的每一个应用程序都是独立的，因此不会与其他应用程序或配置产生冲突，这有助于简化故障排除过程。希望创建一个名为 “MyNewApp” 的新应用程序？那么只需要输入 zero create MyNewApp。首先转到 MyNewApp 目录然后输入 zero start。没有比这更简单的操作了。仅有的几个配置文件全部为纯文本文件，因此可以根据需要进行修改。提供了对流行语言（Java、PHP 和 Groovy）的支持，其中已经包含了以开箱即用方式提供 REST 功能所需的基本内容。
对于目前超过百万的下载量，WebSphere sMash 的流行加快了下载速度。我已经改为使用 WebSphere sMash 完成许多新的 Web 应用程序开发，并不仅仅是因为它缩短了产品的完成时间，还因为它提供了易于使用的特性和 Web 开发所需的可扩展能力。我可以根据自己的需要保持简单性，并在更复杂的场合下添加组件来满足具体的场景要求。随着越来越多的人加入到 WebSphere sMash 社区中来，我希望它能够参考 Twitter 和 iPhone 的例子并保持适度的简单性。
目前为止，一切都非常完美。
 |
|
结束语
我知道许多架构师都会这样说，“我理解你的意思，Doug，但是我真的没办法简化我的设计。我需要提供很多的功能”。我建议您再研究一下您的设计，看看是否还有可能进行瘦身或降低复杂性。大多数较大型的设计至少可以被划分为多个更小的解决方案。尤其是在今天，随着 SOA 和 REST 服务的出现，真的没有必要再将所有内容集中到一块。只需要将您的应用程序分解为多个独立的组件，您就已经迈出了重要的一步。您可能会惊讶地发现，有许多种方法可以使您的设计变得更容易使用、更容易进行故障排除、运行得更快，以及节省更多的资金 —— 这正是我们追求的最终目标。
参考资料 学习
获得产品和技术
关于作者 | 
| | Doug Phillips 是 IBM 技能专家精英组（也称为 IBM Web Enablement and Support 团队）的一名顾问软件工程师。他曾在 IBM 的多个组织中工作，目前，他使用 IBM 中间件和 Linux 设计和开发内部和外部 WebSphere Portal 应用程序。Doug 获得了 WebSphere、Lotus、Rational 和 DB2 认证。 |
对本文的评价
| 
