下载掌阅APP，畅读海量书库
立即打开
当我还是一名物理学专业的本科生时，我为 F = ma 这样的简单方程式着迷，因为它如此简单，却能解释世界。后来我成为一名程序员，之后又成为一名计算机科学研究人员，我又为形式化方法领域着迷，因为形式化方法如此简单，却能表达软件的本质。
在获得博士学位后的30年里，我主要在研究Alloy，这是一种用于描述软件设计并对其进行自动分析的语言。对我来说，这个研究是一段令人兴奋和满意的旅程，但随着时间的推移，我逐渐意识到软件的本质并不在于任何逻辑或分析。真正让我着迷的不是困扰大多数形式化方法研究者的问题，即如何检查软件的行为是否完全符合其规范，而是设计问题。
我这里指的“设计”，与在其他设计学科中的意义是一致的，即创造某些组件以满足人类的需求。正如建筑师克里斯托弗·亚历山大（Christopher Alexander）所说，设计就是创造一种适应场景的形式。对于软件来说，这意味着决定软件的运行方式应该是什么：它能提供什么样的操作，以及给出什么样的响应。这些问题没有正确或错误的答案，只有更好或更坏的答案。
我想知道为什么有一些软件看起来如此自然和简洁，一旦你掌握了基本操作，就总能得到符合预期的响应，并让你可以高效地组合使用软件中的功能。我想指出为什么有些软件看起来有问题：杂乱无章、充斥着不必要的复杂性、不按预期且以不一致的方式运行。当然，我想一定有一些基本的原则和一些软件设计的理论可以解释这一切，不仅可以解释为什么有些软件是好产品，而有些软件不是，而且可以帮助你在出现问题的第一时间解决问题，甚至避免问题的出现。
我开始寻找可行的理论。在我自己的子领域，即在形式化方法、软件工程和编程语言中，存在这样一种名为“内部设计”的理论，即代码结构的设计。程序员拥有丰富的设计语言，以及用于区分好设计和差设计的完善标准，但在面向用户的软件设计中，没有这样的语言或标准能够决定软件作为一种形式在应用场景中为用户带来什么样的体验。
代码结构的设计非常重要，它主要影响软件工程师说的“可维护性”，可维护性表示随着用户需求的演变而变更代码的难易程度。代码结构的设计还影响软件性能和可靠性。但是，决定一个软件是否有用，是否满足用户需求的关键之处在于软件的设计，它塑造了软件的功能及其和用户交互的方式。
可维护性、性能和可靠性这些大问题曾经在计算机科学中很重要。在软件工程领域，它们出现在软件设计、规格说明和用户需求的研讨会上；在人机交互（human-computer interaction，HCI）领域，它们渗透到用户界面和用户行为计算模型的早期工作中。
但随着时间的推移，这些大问题变得不那么流行，并逐渐消失了。软件工程的研究范围越来越窄，消除缺陷（无论是通过测试还是更复杂的方法，如程序验证）成为软件质量的代名词。但是这种方法并不能实现目标，因为如果软件设计有错误，无论做多少消除缺陷的工作都无法修复整个系统，除非回到最初修复设计本身。
人机交互的研究转向了新型交互技术、工具和框架，转向了小众领域和其他学科，如民族学和社会学。软件工程和人机交互都热情地接受了经验主义，这在很大程度上是因为人们误以为这样会使这些研究赢得尊重。研发人员想要发现有效可行的具体方法，于是转向了那些更容易评估、不那么耗时费力的项目，这阻碍了他们在更大、更重要问题上的进展。
令人疑惑的是，尽管人们对设计的兴趣似乎已经减弱，但设计的话题却无处不在。这实际上并不矛盾。这些话题几乎都是关于设计过程的，无论是关于“设计思维”（“迭代设计过程”的一种好听的说法），还是关于敏捷开发。只要审慎地应用这些设计过程，而不是将其当作万能灵药，这些设计过程无疑是有价值的，但它们在很大程度上是与内容无关的。我的意思不是贬低它们，而是描述事实。例如，基于设计思维，你可能会结合自己对问题的理解来制订解决方案，或者交替使用头脑风暴（发散）和多中择优（收敛）的方法。但在我读过的有关设计思维的书中，没有一本书深入讨论任何特定的设计以及如何使用发散和收敛这两种方法进行设计。设计思维可以独立于任何特定领域，这可能是其具有广泛吸引力和适用性的关键，但这也是它对软件设计这种特定领域面临的深层挑战没有任何洞见的原因。
当我开始做Alloy研究时，我的目标是创建一种适于自动分析的设计语言。我对已有的建模和规范语言持批评态度，因为它们缺乏支持的工具，这导致它们只能写下代码设计。这种负面的论断并非完全没有道理。毕竟，如果你不能用它做任何事情，为什么还要费心地构建一个复杂的设计模型呢？我认为，设计师的努力应该得到立即的反馈，通过各种令人吃惊的情况，让他们能够对自己的设计产生更深入的思考。
我不认为我错了，Alloy的自动化也确实改变了设计建模的体验，但我低估了写下代码设计的价值。事实上，在形式化方法研究人员（他们渴望通过在现有的设计中发现缺陷来证明工具的有效性）中这并不是一个严格保守的秘密，即大部分缺陷在工具运行之前就被检测到了！仅仅把设计转成逻辑就足以揭示出严重的问题。软件工程研究人员迈克尔·杰克逊（Michael Jackson）认为，逻辑本身并不重要，重要的是它们的使用难度。他曾开玩笑地说，如果只是要求设计师简单地使用拉丁文记录设计，那么软件系统的质量可能就会得到提高。
设计的清晰有助于事后发现设计缺陷，这也是优秀设计的关键所在。在过去30年教授编程和软件工程的过程中，我越来越相信，在开发软件时，成功的决定因素不在于使用了最新的编程语言和工具，或者遵循了管理流程（敏捷或其他方式），甚至不在于如何构造代码，而在于知道自己想要做什么。如果你的目标很明确，设计也很清晰，即你清楚地知道设计应该如何满足目标，那么你的代码也会很清晰。如果出了问题，我们也会很清楚如何解决。
正是这种清晰性将优秀的软件与其他软件区分开。1984年，当苹果公司的麦金塔（Macintosh）电脑问世时，人们立刻就知道如何使用文件夹来整理文件，以前操作系统的复杂性似乎消失了，比如Unix，它在文件夹之间移动文件的命令很复杂。
但这种清晰性到底是什么，又是如何实现的呢？早在20世纪60年代，人们就认识到概念模型的核心作用。软件设计的挑战不仅是将软件的概念模型传递给用户，以使用户的心智模型可以与程序员保持一致，而且是将概念模型当作设计主题本身。有了正确的概念模型，软件就会易于理解，从而易于使用。这是一个非常好的想法，但似乎没有人去遵循它，所以直到现在，概念模型仍然是一个模糊但鼓舞人心的概念。
我确信概念模型是软件的本质。大约在8年前，我就开始试图弄清楚概念模型可能是什么，我想给出它们的具体定义，这样我就可以指出一些软件的概念模型，并将它们与其他软件以及用户的心智模型进行比较，并在讨论设计时给出明确的重点。
这看起来没那么难。毕竟，对概念模型看似合理的切入点可能就是对软件行为进行描述，即适当抽象以去除非主要和非概念性的方面，比如用户界面的细节。在概念模型中找到合适的结构是更困难的，这已得到证明。我有一种想法，即概念模型应该是由概念组成的，但我不知道概念是什么。
例如，在Facebook这样的社交媒体软件中，我觉得应该有一个与“喜欢”相关的概念。这个概念当然不是一个功能或操作，例如通过点击一个按键，表示喜欢一个帖子。这样的例子太多了，它们只表现了概念模型的一部分。这个概念当然也不是一个对象或实体，因为这个概念似乎表示对象或实体与喜欢之间的关系。对我来说很重要的一点是，喜欢概念似乎与任何特定类型的事物无关，你可以喜欢帖子、评论、页面等。在编程术语中，这个概念是“泛型的”或“多态的”。
这本书是我探索至今的成果。在广泛应用的软件中存在的数十个设计问题的驱动下，我开发了一种新的软件设计方法，并在此过程中对这一方法进行了改进和测试。令人高兴的是，每个软件的失败或遇到的挫折都成为我丰富案例库的契机，当我的分析深入揭示出软件设计师面临的复杂问题时，我对他们有了更多的同情和尊重。
当然，软件设计的问题还没有得到解决。但正如我的朋友克尔斯滕·奥尔森（Kirsten Olson）的明智建议那样，一本书应该是开启对话，而不是结束对话。在对本书主题进行多次讨论的过程中，我激动地发现，它似乎比我以前的任何一个研究主题都更能引起观众的共鸣。我怀疑这是因为软件设计是我们都想讨论的话题，但我们还不知道如何进行讨论。
所以，对于作为研究人员、软件设计师和用户的读者，我把这本书作为我们对话的开场白，并希望这是一场富有成效和愉快的对话。