一个设计人员对于一个成熟的产品要花很长时间才能意识到这个应用程序的用户界面的各个部分并不是一致的稳定可靠。在应用程序不断改进的数年中，会有一些极其重要但又异常脆弱的组件被开发出来，很多其它功能依赖它们。我把程序里这样的一个特征描述为恐怖地下室：黑暗，陈旧，神秘，性能不稳定但对整个程序操作至关重要的代码之躯就躺在里面。恐怖地下室难以清理，不好维护——有些东西只有团队中最资深的、最中坚的工程师才能处理的了，其他人唯恐避之不及。

　　当我作为Microsoft Money项目的主要设计师时，必然的就发现了它的恐怖地下室：用于查看和修改账户交易的复杂的支票登记控制模块。登记控制模块最初是在1990年由传奇的微软工程师Doug Klunder开发出来。为了在当时的PC机上获得最大的效能，我相信他或多或少的使登记系统直接的在磁盘上对交易数据进行了读写操作。在这种情况下，这个特殊的UI控制系统整个的、独自的承担起了对整个交易数据进行校验的任务；在这里你看不出有表示层，业务逻辑层和磁盘存储层之分。

　　这给我们的工作带来了各种各样奇怪的限制。例如，对于任何一个用来创建账户交易的会话，你都要在后台的某个地方实例化一个隐藏的登记控制器。当用户在对话框里输入数据时，会话程序必须小心的把数据拷贝给登记控制器，告诉它保存数据，然后推测保存操作何时能完成。

　　每一次新的版本，登记控制器就会挂上一些新的功能（投资，在线银行，本地化），每一次都会增加程序的复杂度。四年后当我加入这个团队时，这个登记控制器已经变得不可思议的错综复杂了，整个团队里只有一、两个人能够和愿意碰它。

　　恐怖地下室有个突出的特征，任何其上的工作都会花费不可预料的时间周期；任何的bug修改或功能改进都会导致不可计算的成本代价。就拿Microsoft Money的登记控制器的例子来说，一个简单的改变交易数据列顺序的动作就可能需要一天，甚至数周的时间。你无法对这个事情进行预估。

　　当我第一次向人透露这个事实时，隔壁Microsoft Word项目组的的朋友向我分享了他们的应用程序里恐怖地下室的故事：一个叫FormatLine的程序的故事。在文档里给出一个点和一个列宽，FormatLine可以设计出这个点的下一行上的文字的布局。据我听到的，这个程序已经发展出来好几个功能点，每个功能上都有数千行的代码。被指定去深度了解FormatLine的开发人员抱着既尊敬又惶惶不安的心情，就像探险者深入危机重重的矿井进行勘探一样。

　　地下室的比喻并不只是用来描述人们对于一个程序蹑手蹑脚的胆怯特征——它同时也反映出这种情况的出现对于一个应用程序来说是与生俱来的。就像一个建筑物的地基，在没有付出重大的技术代价的情况下，你是不可能把这些代码替换成更加稳固的东西的。大多数情况下，恐怖地下室会被留下来自行其事，直到应用程序对于寄居的平台慢慢脱离关系，应用程序迁移到一个更新的、稳健的基础上。

　　为了防止你的UI的某个关键的稳固的部分逐渐演变成一个恐怖地下室，你需要在你开发的过程中重构你的代码，这会使得修改活动缓慢而不剧烈。在进行UI修改时，你需要评估一下这对程序基础部分的稳定的牵连有多深。

　　上周，一个在Cozi公司的开发人员来我这里给我出了一个难题。我最初的设计是对Cozi公司的这个家庭日历的UI做一项有趣的修改，这样能够帮助优化这些陈旧的界面，对用户数据以及广告效果都有好处。不幸的是，在经过了几周的工作后，开发人员发现要想让新的UI在这个可以无限滚动的日历页面上正确的现实是极度复杂的。这个无限滚动的特征本身十分精致，想要对其做任何修改都十分的复杂，因为它需要在各种浏览器里都能正确的工作。虽然我们可以花时间慢慢的使这项新特征稳定下来，达到可以接受的质量水平，但我们的日历UI很有可能变得更加脆弱——下一次我们增加新特征时将会面临新的压力，事情也许会在无法预知（和无法承受的开销）的情况下无法收拾。我们的日历UI将会变成一个恐怖地下室。

　　我们可不愿让这种事情发生。像Cozi这样专注于家用产品的公司，能够让他们的日历UI能得到持续的改进是至关重要的。为了给以后的产品改进提供一个安全的道路，我们最终认定目前不是做这种修改的好时机。也许等到有一天跨浏览器兼容不再是个头疼的问题（也许是某天我们放弃对IE7、IE8的兼容支持），我们再做行动。而目前，我们还是有个干净、光线较好的地下室的。