干净的代码、肮脏的代码、人性化的代码

封面照片由Dan Wayman在Unsplash上拍摄

上周，Dan Abramov 发表了一篇非常个人化且令人谦卑的博客文章，题为《再见，干净的代码》。

我在自己的时间线上看到了一条关于此事的推文。作为“整洁”代码、TDD 等理念的长期支持者，我自然感到担忧。以下是我当时的回复。

我不喜欢推特，因为在推特上很难找到争论的细微差别。所以在这篇文章里，我会解释一下我所说的“人为代码”是什么意思。

责怪代码比责怪我们自己更容易

我认为丹在博客中记录他职业生涯中非常个人化的经历是非常棒的。

许多成为团队领导的程序员都会有和他类似的经历。比如，你的同事写了一些你不喜欢的代码，所以你重写了它，因为你希望你的代码库尽可能完美。然后，一切都乱套了。你冒犯了你的同事，让团队其他成员感到尴尬，你的老板不得不介入并解决问题。

有时候，你会突然意识到，作为团队领导意味着要从背后指挥。你的团队进步的速度永远取决于团队中最慢的人，你的工作是帮助每个人进步，而不仅仅是你自己。

很多人在丹关于他博文的推文下回复了同样的评论。这种经历在科技界如此普遍，难道不有趣吗？

人类代码

我们正在深入理解“人性化代码”的核心。人性化代码是以人为本的理念编写的代码。

我不确定是谁最先说出这句话的，但我第一次听到它是在SoCraTes 2019 非会议上。（如果您知道，请告诉我是谁说的！）

计算机科学中最难的两个问题是人，以及让人们相信人是计算机科学中最难的问题。

这句话说得真好，不是吗？我是一名软件顾问，帮助企业解决软件问题。我遇到的最大问题几乎总是源于对项目方向和结构的分歧，从而引发人际关系问题。

巧妙的代码

这里的另一个问题是“干净”是什么意思？它不是指最短的代码，也不是指抽象最智能的代码。

就拿人们经常误解的缩写词 DRY（不要重复自己）来说吧，然后又发明了其他缩写词，比如 WET 或 AHA。我们不需要这些缩写词。DRY 本身就很好。这个话题值得单独写一篇博文来讨论，但现在我只想说，还有一个术语可以帮助理解这个问题。

这就是“聪明代码”这个术语。我喜欢这个词，因为它让人联想到孤狼般的形象，一个“10x”程序员，试图证明自己比周围的其他人都优秀。这种行为是有害的。聪明代码之所以有害，是因为它需要花费不成比例的时间来阅读和维护。聪明代码就像一颗定时炸弹。

顺便说一句，我这里不做任何评判，因为当我独自工作时，巧妙的代码是我的默认模式。但当我与他人结对时，我写的代码要好得多。与他人合作是阻止巧妙代码出现的好方法。

这就是“干净的代码优于聪明的代码”这一理念的由来。

但...

干净的代码就是脏代码！

软件工匠社区中的许多人很久以前就决定不再使用“干净”这个词来描述我们的代码。

问题在于，说“干净”就等于暗示某些代码“脏”。这会让人感到羞耻。尤其对于初学者来说，这类词很容易让人产生“冒名顶替综合症”，觉得自己的代码不够好。

如果您遵循人类代码原则，那么您要避免任何可能引起同事负面反应的事情，其中​​包括使用“干净”这个词。

Tobias Goeschel是第一个向我介绍“清晰代码”这个概念的人，他将其视为“干净代码”的改进。当我与他讨论这篇文章时，他提醒我，“干净”还存在一个更深层次的问题，那就是“干净”与“脏”之间虚幻的二元区分。我们编写的所有代码都涉及权衡，相信总有一种正确的做事方式是没有帮助的。

就像 DRY 代码也不是非此即彼的一样。人们讨厌 DRY 是因为他们认为它非此即彼——要么 DRY，要么不是——但实际上，DRY 只是朝着代码质量的正确方向轻轻一推。

是的，我关心代码质量。但我也关心人。

让我们停止互相评判。让我们携手合作，打造出更优秀的软件。🤗