软件开发：外观漂亮和运行良好 到底哪一个更重要

除此以外，开发者的本能反应是希望关注技术问题。我们是技术人员，不是吗？这是我们想做的事情，因此我们才这样做。许多程序员宁愿花两天时间调试存在于一个N层应用程序中的间断数据并发问题，而不愿用两个小时处理一个UI排版错误列表并进行纠正。我常常为这种事情感到内疚。

讽刺的是，终端用户往往不像他们的经理那样十分关注外观问题。对他们而言，功能主导一切。在我以前工作的几家公司中，我们使用一个通过VT100应用访问的陈旧应用程序。

80 x 40 ACSII模式，你知道那种程序，它的窗口的边角为加号，边缘为连字符和竖划线（|）。我从未听到某个同事这样说：“哇，如果这是一个Web应用程序，那么我们就能看到公司标记或有圆角，那就太好了！”相反，大家都抱怨它运行缓慢或存在记录锁定问题。

在我进行开发时，我直觉地了解这个事实，但从没有下意识地应用它。因此，我常常把软件原型交给终端用户，而不是让向我们提出要求的经理进行实际的日常测试。我为这个满足用户所有需求的技术优良的系统付出心血、汗水，度过不眠之夜，我可无法忍受听到关于图表或占位符图形的颜色的抱怨。

在我的上一份工作中，经理坚持认为在提供一个难看但工作正常的原型前，向客户提供一个漂亮但功能并不完善的原型。虽然从开发周期的角度看，我并不赞同他的做法（我的编码方法是使应用层次与外观无关，因此开发特性并不依赖于外观，它似乎总是在改变），现在我从商业角度看待这个问题。当我们的客户让技术人员或终端用户进行测试时，我的“特性第一，外观第二”的方法非常棒。

用户会对功能要求做出调整，既然外观并非与特性密切相关，做出改变应该会很容易。但是，对于让经理进行测试的客户来说，事实会变得一团糟。

我会恳请他们忽略外观而关注特性。我会问他们：“这确实能够满足你的需要吗？”并得到这样的回应：“我预想是那样，但这段正文好像太大一点。”然后，在正式发布的前两天，真正的用户会注意到这个问题，各种未确定的要求也随之出现，正式发布不得不延迟。

这确实是一种极其糟糕的境地。虽然我喜欢放弃外观，为客户提供一个运行良好的应用程序“初稿”，但这一做法并不总是可行。在我前面的几个项目中，我一直着重考虑由谁进行初步测试工作，我发现这点十分重要。

责任编辑：德东

查看本文国际来源