酷应用

敏捷软件开发宣言最初签署人Kent Beck：软件设计是一种人际关系活动

百家作者：InfoQ 2022-12-20 15:15:54

作者 | Shane Hastie

译者 | 平川

策划 | 丁晓昀

Kent Beck 是敏捷软件开发宣言的最初签署人之一（按字母顺序排在第一位的签署人），他在本周的 QCon 旧金山大会上发表了闭幕主题演讲。他演讲的题目是“整洁第一？（Tidy First？）”，这也是他即将出版的新书的名字。

首先，他介绍了自己的个人使命：帮助极客们在这个世界上获得安全感。关于这一点，他在一篇发表在 Facebook 的博文中解释过。

他谈到，最近重读了 Ed Yourdon 和 Larry Constantine 的著作《结构化设计》。按照他的说法，这本书里包含软件开发的牛顿定律；对于如今的编程来说，其中的概念和思想还和这本书刚出版时一样重要。书中介绍的耦合和内聚两个概念，即使在今天，也仍然是软件工程的一大挑战，就像这本书在 1975 年出版时一样。

他说，他花了 17 年的时间才学会如何解释软件设计中的内聚概念，以此为契机，他写了一系列三本书来探索软件设计。感兴趣的读者，可以在 Substack 上阅读。

他说：

软件设计是一种人际关系活动。

正是通过探索这些关系，软件系统才出现在了这个世界上。

第一个关系是希望探索的想法和将想法变成现实的行为之间的关系。这种关系是双向的，是不断发展的——想法定义了行为，行为的存在可以催生更多的想法（“现在我看到了这个，那么那个呢……”）。在思想和行为的背后是系统结构，也就是架构，它对可见行为有着深远的影响。

系统结构对行为有着深远的影响，对因行为改变而产生的想法也有深远的影响。结构影响行为，从而产生新的想法，催生行为更改需求，进而影响结构，不断循环。在“整洁第一”工作流中，我们得以暂停一下，问问自己是否需要更改结构，或者只需更改行为。如果更改影响了结构，那么要首先整理下结构——根据需要重构底层架构。不要试图同时更改结构和行为，因为那会导致系统陷入技术债务。

他说，在构建系统时，特别是在必须更改系统时，涉及两种视角，分别是等待者（waiters）和变更者（changers）。等待者有了想法，就会希望尽快更改行为，尝试新事物；变更者则必须维护代码，并整理结构，为的是可以安全地更改行为。

当有多个变更者负责同一产品的不同领域时，复杂性会进一步增加。等待者的动机和不同变更者的竞争性动机之间很可能出现关系紧张的情况。

软件设计技能就在于保持不同生产者以及变更者和等待者之间的良好关系。

通常，变更者在收到更改产品的请求时会面临这样的问题：“这段代码很乱——我应该先整理再更改吗？”这个问题的答案通常很教条：当然应该或者当然不应该——我们希望尽快更改，并且希望可以保证代码库不受技术债务的影响。遗憾的是，两者无法兼得。我们需要做出决策，而正确的答案只能是“视情况而定”。

为了说明等待者 - 变更者生态系统中的不同关系，他画了下面这幅图：

然后，他解释了为什么大量的前期设计在 20 世纪 90 年代是一个馊主意，而且直到今天仍然是一个馊主意。他说，瀑布式开发又回来了，有些组织再次尝试根据预先定义好的时间、成本和范围来定义软件开发的成功与否。他还解释了为什么增量迭代开发始终是构建软件系统最经济可靠的方法，而且如今更是如此。

他讨论了 Constantine 的对等概念：软件系统的实际成本是更改系统的成本。在系统的生命周期中，维护系统的成本将使初始开发成本在整体投资中的占比变得很小。然后，他展示了维护产品的成本如何与系统耦合的成本直接相关。对系统中一个元素的更改导致了对另一个元素的级联更改，进而又导致了对另一个元素的更改，诸如此类……

系统的总体成本可以看作是系统元素的耦合成本与解耦成本之和（他用了元素这个词，代码的实际性质和我们这里介绍的内容没有关系——那可以是函数、远程过程、微服务或任何其他相关的组件）。

系统的底层结构（架构、设计）是耦合 / 解耦问题中最重要的一个因素。

当考虑更改系统时，可能大多数情况下都是在没有多少级联耦合的部分进行，然而，在产品的生命周期中，可能有一些巨大的更改——其中耦合级联如此之大，以致更改成本变成了天文数字。在系统的使用周期中，这些巨大的更改很可能占了维护成本的绝大部分。