最近，一位同事请求作者审查一些复杂的 UI 更改。其目的是通过在恰当的时机显示警告并在后台自动执行各种状态更改（例如“智能配置器”），使容易出错的表单更易于使用。需求已预先给出，因此同事处于执行模式，将这些需求转化为代码。

浏览拉取请求时，没有发现任何问题，但在实际使用新 UI 之前，作者并不准备批准更改。

然而，在自行测试之前，作者通过聊天信息询问了同事：“你对新的行为感觉如何？”。

作者去喝咖啡回来后，同事的回答如下：

“说实话，不太确定。

几分钟后...

感觉有点不对劲，好像有时我无法像用户一样进行所需的更改。

又过了一会儿...

实际上还有一个错误需要修复，稍后再回复你。这对我们的用户来说必须非常稳定！”

作者推测，同事在中间可能进行了一些反思和调整，因为这个简单的问题，让同事开始认真审视自己的代码以及最初的需求，并做出了改进：最终，一个有问题的需求被放弃，并在实际审查之前添加了多个提交。

后来，了解了同事的思考过程后，作者对代码的审查和批准变得更加轻松。

作者发现，这样一个简单的问题居然产生了如此大的影响，这非常值得注意。当然，同事的反应也很好，不应该被视为理所当然。他们承担了责任并开始工作，并能够批判性地审视需求和他们的解决方案。

无论如何，作者认为不时地询问工程师“他们对自己的作品感觉如何”是一个有用的技巧。作者认为这样做只有好处。 ∎