Michael Feathers 希望消除错误能驱动设计

Michael Feathers 因其著作《高效操作遗留代码》（ Working Effectively With Legacy Code ）一书而广为人知。他发现错误中存在着一些值得关注之处，但他也承认大部分开发人员并未投入时间去关注这些错误。在他看来，很多错误解决机制就是采取某种程度上的放弃。在 Explore DDD 2018 大会上，Feathers 做了主题演讲，探讨消除错误如何驱动软件系统的设计。

针对领域驱动设计（DDD）大会的主题，Feathers 在演讲一开始就给出了对“领域”（Domain）的五种定义。他在这些定义中发现了一个共性，即领域就是一种范围，一些领域是随意构造的，也有一些是人们创造的。正因为领域是随意构造的，因此人们可以重新塑造和扩展领域。虽然人们可以直接使用 DDD 模拟并适应不断变化的业务流程，但为了更好地应对乃至消除错误，Feathers 建议应对领域做尽可能类似的更改。

Feathers 指出，领域扩展可能会导致一些不和谐因素，因此必须慎重。Feathers 就此举了两个例子，一个是在可选日期中输入了二月三十日，另一个是在编程语言中允许对数组赋以负的索引值。对于前者，人们非常易于理解简单域模型是如何允许这种非法情况的发生。但是对于负的数组索引值，情况则恰恰相反，对此应抛出一个错误。一旦这样的技术可用，并被人们按有效的语法采纳，那么我们就会意识到领域扩展对此类情况是非常有用的。

Feathers 提及，他探索错误的部分灵感来自于 Joe Duffy 博客中对微软的Midori 操作系统研究项目的论述，尤其是对错误模型l 的分析。Duffy 提及，“错误模型试图回答的一个基本问题就是，'错误’是如何传递给程序员和系统用户的？”这个看似简单的问题，自然导致了“如何定义错误”的挑战。Feathers 沿此思路继续推理，最终得到人们希望知道的是“为什么我们会存在错误？”。换句话说，如果“错误”只是一个用于指代我们领域中不匹配概念的用词，那么我们应该怎么做？

演讲进而从领域的概念延伸到如何实际处理错误。在遇到错误时，人们主要存在三种做法。第一种做法是简单地返回空值。这种做法消除了对任何错误原因的解释，需要人们对空引用做额外的检查工作，并且混淆了人们仍在处理错误的事实。另一种做法是抛出异常。这种做法也许要优于返回空值，因为它可以给出了问题的一些相关信息，但它仍需要调用者去处理异常情况。第三种做法是将错误作为领域的一部分。Feathers 认为，“错误就是我们领域的一部分，因为错误可能会发生在我们的工作中”。很显然，Feather 提倡采用第三种做法。

扩展领域意味着提出问题，“我们真正希望会发生什么？”。不应只是告诉他人错误的相关信息，而应引入一些新概念去提供可操作信息。一个例子就是使用空对象模式返回 ItemNotFound对象，其具体实现取决于具体的情况。

在演讲中的最后，Feathers 给出了 Erlang 的设计理念，并按英式风格概括为“保持冷静，任其崩溃”。计算是与现实世界紧密联系的，因此在现实中计算可能会产生失败。Erlang 通过将现实情况囊括在领域之中，扩展了应用的领域。如果一种语言的整个领域可以使用这种方式扩展，那么即便是更小的系统，都一定能受益于涵盖错误的领域扩展。

查看英文原文： Michael Feathers Wants Error Elimination to Be a Design Driver