观点
只有代码才有价值？
即使是编写最好的代码也无法揭示它为什么要这样做。
Terry Coatta，Vitrium Systems
最近一次关于开发方法论的对话转向了开发过程中产生的各种工件的相对价值，与我谈话的人说：代码“一直是唯一重要的工件。只是我们现在才开始认识到这一点。” 我当时没有表达出来的反应是双重的。首先，我感到强烈的似曾相识感，因为它使我想起了我的本科时代以及关于代码是否是自文档化的许多激烈讨论。其次，我想到了最近经历中的几个例子，在这些例子中，仅仅代码本身不足以理解系统为何以特定的方式架构。
与演讲者所表达的观点相反，代码至上的观念在软件开发中有着悠久的历史。以我的经验来看，真正优秀的程序员总是倾向于代码是自给自足的观点。事实上，在不借助注释或设计文档的情况下，就能审视一段代码并感知其整体结构和目的的能力，通常是区分最佳程序员与其他程序员的非正式方式。用我本科时代的一个主题来解释：“如果你不理解我的代码，那不是意味着它需要注释，而是意味着你需要更多地学习编程。”
的确，与我合作过的最优秀的程序员确实拥有惊人的“代码思维”能力。在他们编写了 10,000 行代码的六个月后，你可以回去，指向这 10,000 行代码中的一行，并问他们为什么在那里。他们会毫不犹豫地告诉你。问题是，拥有这种能力的人很少见。在我大约 30 年的软件开发经验中，我只遇到过几个。软件开发的现实情况是，有更大一类程序员是优秀的，但没有那么优秀。除非你有幸拥有一个完全由编程忍者组成的开发团队，否则你的软件开发流程必须适应更广泛的软件开发人员。
最近的两个经历真正让我意识到了这一点。第一个是关于一段相对简单的代码。代码本身很容易理解，但代码无法传达的是这段代码存在的根本原因。第二个例子涉及使用代码以外的形式主义的价值——在这种特定情况下，是有限状态机。
我想到第一个例子是因为我最近在查看我们公司产品的代码库。我偶然发现了一段相当简单的代码，它是我们工厂模式的基本实现的一部分。每当工厂创建一个对象时，它都会将其存储到一个列表中。工厂有一个入口点，然后遍历此列表，并为列表中的每个对象调用我们的底层存储系统。这段代码是自文档化的，因为它完全清楚它在做什么。另一方面，完全不清楚它为什么要这样做。我知道存储子系统会自动处理对象创建，因此仅仅在工厂中实例化对象就应该足够了。
我去找了编写这段代码的开发人员，询问为什么要额外遍历列表。起初，甚至他都很难回忆起我们为什么要添加这段代码。最终，我们两人设法回忆起我们最初以直接的方式编写了工厂，但它没有奏效。尽管存储子系统确实自动处理了对象的创建，但我们遇到了数据库约束被违反的问题，因为我们工厂的工作方式是，你首先创建对象，然后初始化各种属性。不幸的是，存储子系统在创建对象后立即将其插入到数据库中。由于对象的属性在当时尚未设置，因此该插入违反了某些类型的约束，通常是要求某些属性为非空的约束。
因此，在工厂中额外遍历已创建对象列表是延迟将对象插入数据库的机制的一部分，直到属性设置完毕之后。这次经历让我认识到，如果你有编写良好的代码，你可以轻松理解代码在做什么。然而，即使是编写最好的代码也无法揭示它为什么这样做。那是因为“为什么”的问题不是以代码本身为中心，而是以代码运行的上下文以及系统开发过程中做出的设计决策为中心。传达这些想法的最佳方式不是代码，而是注释和设计文档。对我来说，这清楚地表明，不仅仅是代码才有价值。
我不会详细介绍第二个例子。我只想说，我们开始进行一些基于事件的编程。我从以前的经验中知道，有限状态机（FSM）在这种情况下运行良好，我们为各种组件创建了 FSM。在与开发人员合作的过程中，我立即清楚地意识到，与他们讨论 FSM 的最佳方式不是坐下来查看实现它们的代码，而是拿一张纸并绘制它们。虽然实现 FSM 的代码完全定义了该 FSM 的行为方式，但查看代码并不能真正让你直观地了解 FSM 的作用。图表可以。在这种情况下，图形形式主义增加了代码无法提供的价值。
我已经经历过足够多的类似经历，我根本不相信“只有代码才有价值”的观点。显然，代码是软件开发过程的核心价值产品。但它不是唯一有价值的东西，如果我们想维护和扩展我们的代码，我们需要相应地调整我们的软件开发流程。
最初发表于 Queue 第5卷，第6期—
在 数字图书馆 中评论这篇文章
© 版权所有。