并非所有摩擦都相同

Source: Dev.to

Introduction

最近有很多文章在庆祝“摩擦的消亡”，赞扬 AI 消除了写代码的摩擦并提升了开发速度。但摩擦总是坏的吗？

Friction in Software Development

从我的个人视角来看，当火箭撞到避难所的墙壁时，墙壁提供的摩擦是好的摩擦。我们来考虑一个不那么戏剧性的例子。

Git 出现后，改变了我们管理源代码的方式。任何人都可以在本地创建分支，使得分支变得轻松且成本低廉，合并也很容易。多个开发者可以并行地在同一代码上工作。许多由中心化版本控制系统强加的摩擦被移除，从而提升了更改能够进入主代码库的速度。

为了重新获得对这些更改的可视性和控制，我们引入了一个新的有意的摩擦点：Pull Requests（合并请求）。有了 PR，变更在合并之前就变得可见。其他人会对其进行审查，进行讨论，CI 检查也可以运行。PR 故意放慢最终步骤，以便我们重新获得可视性和控制。

Good vs. Bad Friction

• 坏的摩擦 因为需要付出额外的努力而减慢我们的速度：编写样板代码、搭建环境、重复性工作。消除这种摩擦会提升速度。
• 好的摩擦 是有意引入的，用于保持控制、安全或正确性。例子包括 PR、部署门禁、受控发布、功能标记（feature flags）以及类型检查等。

有趣的是，当“坏”摩擦消失、速度提升时，我们往往需要引入新的“好”摩擦，以防止事情失控。

AI and the New Friction Landscape

我们正目睹 AI 大幅降低了写代码的摩擦，从而提升了开发速度。然而，风险并未消失。我们现在需要找到方法，引入新的、更精细的摩擦，使我们能够在这种新速度下工作，同时重新获得可视性和信心。

Conclusion

并非所有摩擦都是一样的。有些摩擦阻碍进展，而另一些摩擦提供了关键的安全保障。随着工具的演进——尤其是 AI 的介入——我们必须在消除不必要的摩擦和引入有目的的摩擦之间取得平衡，以保持开发既快速又可靠。