@Rays
2018-09-22T13:21:08.000000Z
字数 1644
阅读 1267
文化&方法
摘要: Michael Feathers因其著作《高效操作遗留代码》(Working Effectively With Legacy Code)一书而广为人知。他发现错误中存在着一些值得关注之处,但他也承认大部分开发人员并未投入时间去关注这些错误。在他看来,很多错误解决机制就是采取某种程度上的放弃。在 Explore DDD 2018大会上,Feathers做了主题演讲,探讨消除错误如何驱动软件系统的设计。
作者: Thomas Betts
正文:
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