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

发布于:2018 年 9 月 26 日 05:30

资深架构师 杨波,正在以案例项目驱动,原理+编程技术+工具结合落地微服务和云原生架构,立即查看 >>

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

阅读数:386 发布于:2018 年 9 月 26 日 05:30

更多 语言 & 开发、架构 相关课程,可下载【 极客时间 】App 免费领取 >

评论 (1 条评论)

发布
暂无评论