Uncle Bob 说，函数的参数越少越好，最好的函数是那些没有参数的函数。我自己也有类似的感觉，但是一直没有想明白为什么。

直到前两天突然想起这事，特地去查了他写的书，有一句话让我豁然开朗：

函数和参数处在不同的抽象层级上。

这就好像人们买了一个产品，并不是开箱即用，而是要阅读说明书，对它进行大量配置，这是不人性的。

好的产品和好的函数是一样的，它们是完整的抽象，并不迫使用户去理解内部细节。

另一件与之相关的事情是，上周和朋友聊起我设计的新协议，其中有两个协议，功能不同，面向的用户也不同，但代码非常相似，有超过 90% 的代码是重复的。

我们聊起这两个协议要不要合并成一个。他第一反应是，当然要合并成一个了。但仔细聊过后，意识到，合并会造成更多问题。

从用户的角度来看，是应该要分开的，否则会产生认知上的负担。跟使用者的认知负担相比，代码层面的重复是完全可以接受的。

这和函数参数是同一个道理。

这实际上也解释另一些事情。

有些东西因为抽象层次低，所以非常灵活。从非常了解它的人看来，这可太牛逼了，能干 A，能干 B，能干 C…… 啥都能干。

但对于普通旁观者而言，因为它抽象层次低，很灵活，所以反而很难理解它究竟是什么。

这个时候，上层的应用就变得非常重要，因为应用的本质是更高层次的抽象，是更好理解的 —— 它就是用来干 XX 的，其他的干不了。

（如果到了应用这一层，还是很灵活，很多功能，不无脑，我觉得那会是失败的应用。）

随着我写这篇文章，我逐渐意识到，这个问题实际上是更为广泛的存在。

比如对于信息或者知识的传递，一个很基础很本质的东西，是不太好传递的。它似乎啥都是，又啥都不是，人们抓不住它。

于是人们对它进行一层又一层的抽象，最后有了我们看到的畅销书、短视频、小白科普文章。

“懂的人” 觉得，这些东西太肤浅太不严谨了，让人们越来越傻；

但对于大众来说，这就跟好用的产品一样，是更友好更容易理解的。细节的损失，甚至部分曲解，并不是一种缺陷，而是必要的，因为这就是抽象的意义。