冷却信使

在软件设计评审中排除自我意识

尊敬的KV：

我最近被聘为一名中级Web开发人员，负责开发一个非常成功但已过时的Web应用程序的第2版。它将使用ASP.Net WebAPI实现。我们的架构师设计了一个分层架构，大致类似于Web服务 > 数据服务 > 数据访问。他指出，数据服务应该与实体框架ORM（对象关系映射）无关，并且应该使用工作单元和存储库模式。我想我的问题大概是从那里开始的。

我们的首席开发人员已经创建了一个解决方案来实现该架构，但是该实现没有正确应用工作单元和存储库模式。更糟糕的是，代码真的很难理解，并且实际上不符合架构。所以我看到了这个实现中出现了很多危险信号。我花了几乎整个周末来研究代码，并且在我的理解中仍然存在差距。

本周我们的第一个冲刺开始了，我感到有责任发声并尝试解决这个问题。我知道我会面临很多阻力，仅仅是因为首席开发人员编写了该代码，并且比其他方案更了解它。他可能看不到我将要传达的问题。我需要说服他和团队的其他成员，代码需要重构或返工。我感到担忧，因为我像是一个试图改变游戏规则的新手。我也不想被认为是万事通先生，即使我有时可能比我应该的更固执己见。

我的问题是，如何在不冒犯任何人的情况下，说服团队该实现存在实际问题？

~固执己见的人

尊敬的~固执己见的人：

让我从信的结尾倒着说。您在问我，Kode Vicious，如何在不冒犯任何人的情况下指出问题？您读过我以前的专栏文章吗？让我们从KV的基本规则开始：只有法律和其他有害的副作用才能使我在某些会议中保持在“正确”的暴力边缘。我愿意相信，如果我最终越界，我的同侪陪审团会宣告我无罪，但我不想把我的自由押在那上面。我会尽力为您提供不会让您入狱的解决方案，但我不能保证它们不会冒犯人。

试图纠正刚刚完成大量工作的人，即使最终这项工作不是正确的工作，也是一项艰巨的任务。相关人员无疑相信他已经非常努力地为团队的其他人创造了一些有价值的东西，走进去并吐口水，无论是字面上还是比喻上，都可能越过您的“冒犯”线——至少我认为是这样。我有点惊讶，既然这是第一个冲刺，并且已经编写了这么多代码，难道不应该在冲刺确定了需要什么、利益相关者是谁等等之后才出现软件吗？或者这是以前存在的代码片段，被引入来解决一个新问题？这可能并不重要，因为您来信的症结在于您和您的团队对相关软件的理解不够充分，以至于无法安心地使用它。

为了更安心地使用该系统，有两件事需要呼吁：设计评审和代码评审。这些实际上并不是同一件事，KV已经介绍了如何进行代码评审[“Kode Reviews 101.” Communications of the 52(10): 28-29. (2009年10月);]。现在让我们来谈谈设计评审。

软件设计评审旨在回答一组基本问题

1. 设计如何接收输入并将其转换为输出？

2. 构成系统的主要组件是什么？

3. 组件如何协同工作以实现设计设定的目标？

这一切听起来很简单，但魔鬼在于细节的层面。许多软件开发人员和系统架构师更希望除自己以外的所有人都将他们构建的系统视为黑匣子，数据输入，其他数据输出，无需提问。您显然对您正在使用的软件没有必要的信任程度，无法让首席开发人员蒙混过关，因此您应该呼吁进行设计评审，在那里您打开盒子的盖子，并探查内部的零件。实际上，问题2和3将是您弄清楚软件的功能以及它是否适合该任务的主要工具。

当我要面试求职者时，我总是会问他们关于他们工作过的系统的问题，同时我们在白板上绘制出框图：主要组件是什么？组件A如何与组件B对话？如果C失败会发生什么？我试图将他们对软件的心理图像转移到我自己的脑海中，当然既不会发疯，也不会有糟糕的回忆。有些软件最好留在您的脑海之外，但希望您正在使用的系统不会是这种情况。

请记住，如果您认为您没有获得足够的细节，那么这个人绘制的每个框都可以打开。就像古老的游戏节目“成交不成交”一样，您总是可以问，“蒙蒂，1号门后面是什么？”当然，您可能会发现那是一只山羊，但希望您发现那是一组您可以和团队理解的工作组件。

在设计评审中不要做的一件事是将它变成代码评审。您绝对不关心任何算法的内部结构，至少目前是这样。您可能只想查看的代码是粘合组件的API，但即使这些最好也保持抽象，以便细节量不会使您不知所措。请记住，目标始终是获得全局概览，而不是细微的细节，至少在设计评审中是这样。

回到冒犯的问题，我发现避免冒犯的唯一合法方法始终是将事情措辞为问题。通常称为苏格拉底方法，这可能是让人们向您解释，并且通常也向他们自己解释他们认为自己在做什么的好方法。苏格拉底方法可以以一种令人讨厌的迂腐方式应用，但由于您试图不冒犯人，我建议您遵守一些有用的规则。首先，不要一开始就用一连串无情的提问来轰炸对方。请记住，您正在尝试以协作的方式探索设计空间；这不是审讯。其次，给与您一起工作的人留出思考的空间。停顿并不意味着他们不知道；实际上，这可能是因为他们试图调整他们对系统的心理模型，这将在评审完成时对每个人都有好处。最后，尝试改变您提出的问题和您使用的词语。没有人愿意受到大量“然后会发生什么？”的轰炸。

最后，我发现在设计评审中，当我要做一些可能会冒犯人的事情时，例如扔椅子或白板笔，我尝试做一些不太明显的事情。我的个人风格是摘下眼镜，把它们放在桌子上，然后用非常平静的声音说话。这通常不会冒犯人，但它确实会引起人们的注意，从而使他们更加专注于努力理解我们都在试图解决的问题。

Kode Vicious，凡人称之为George V. Neville-Neil，为乐趣和利润而从事网络和操作系统代码方面的工作。他还教授与编程相关的各种科目课程。他的兴趣领域是代码探险、操作系统以及重写您的糟糕代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是、Usenix协会和IEEE的成员。Neville-Neil是《FreeBSD操作系统设计与实现》（第二版）的合著者，与Marshall Kirk McKusick和Robert N. M. Watson合著。他是一位狂热的自行车手和旅行者，目前居住在纽约市。

queue.acm.org上的相关内容

代码错觉
Stan Kelly-Bootle
https://queue.org.cn/detail.cfm?id=1317411

安全关键软件的验证
B. Scott Andersen和George Romanski
https://queue.org.cn/detail.cfm?id=2024356

拉撒路代码
George Neville-Neil
https://queue.org.cn/detail.cfm?id=2773214

最初发表于Queue vol. 14, no. 3—
在数字图书馆中评论本文

更多相关文章

Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全需求，存在许多针对加密哈希的标准，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。

Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者在财政紧缩和人工智能等变革性技术的背景下寻求优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者凭直觉地接受良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果，研究生产力差异，从而为该主题提供新的见解。低代码技术已明确显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。

Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在其快速前进的过程中，它容易受到时尚的支配，并且可能会忘记或忽略某些它面临的永恒问题的经过验证的解决方案。用例，最早于1986年引入并在后来普及，就是那些经过验证的解决方案之一。