clojure - Clojure 的长文件是怎么回事？

Question

我已经学习 clojure 几周了，最近我开始阅读一些开源代码:clojure 和 clojurescript 编译器以及一些库，如 om、boot、figwheel。

我注意到一些 clojure 文件非常长，其中一些超过一千个 LOC。鉴于 clojure 的代码非常简洁且朴素，该代码意味着比其他某些语言中那么大的文件要多得多的代码。

来自面向对象的背景，通常每个文件有一个类，并且试图保持类简短(SRP)，我发现这有点奇怪。

我知道 clojure 代码主要由纯函数组成，它们比一些需要记住当前状态的可变类更容易推理，而且我发现我可以阅读和理解大部分一次运行一个功能。但这些函数中的大多数都经过精心设计，因此它们不会相互依赖:即使您可以使用 (filter odd?) ，但这并不意味着 filter 和 odd? 是相关的。但对于“日常”代码(LOB 应用程序、Web 应用程序等)来说，很难保持这些函数的独立性(至少这是我在 OO 编程方面的经验)。

我还看过一些 clojurescript 应用程序(om、reagent 等)的演示，它们在同一文件中声明所有组件。我不知道这是否是因为它只是一个演示，在现实应用程序中你会有一个 product.clj 和一个 category.clj 或者这只是 clojure方式:每个命名空间/模块/有界上下文有一个文件。

我认为，如果我打开一个文件夹并看到 product.clj、category.clj、order.clj 等，我可以一目了然地了解该文件夹的内容，比仅仅拥有 components.clj 或 core.clj 更好。

所以，我的问题是:

1. “每天”的 clojure 代码都有这些很长的文件是很常见的吗？或者只是因为我正在阅读库代码并且“正常”代码更加“模块化”，我的意思是:更多的文件和更少的长度。
2. 拥有这样的长文件实际上会让人更难以一眼理解应用程序的内容吗？就像我上面的产品/类别/订单示例，或者通过某些 clojuresque 属性，这不是问题。
3. 如果长文件是“clojure 方式”，那么如果每个人都接触同一个文件，您如何处理团队中的冲突、重构、编程？

Answer 1

1:我查看了我现在正在处理的相当大的非库 clojure 项目并运行了这个:

ls **/*.clj | xargs wc -l | awk '{print $1}' | head -n -1 > counts

打开一个repl并运行

user> (float (/ (reduce + counts) (count counts)))
208.76471

我看到在一个有 17k LOC 的项目中我们的 clojure 文件平均有 200 行。我找到了一个有 1k LOC 的。

2:是的，一有空闲时间我就会开始分解那个长的。一些非常长的代码(例如 clojure.core)由于 clojure 的一次性设计和自引导的需要而非常长。例如，他们需要建立拥有许多命名空间的能力，然后才能这样做。对于其他精美的库，很可能他们对大文件有其他一些设计原因，尽管根据我的经验，通常是“欢迎拉取请求”的情况。

3:我确实在一个拥有一些大文件的大型团队中工作，我们使用 git 处理合并冲突，不过因为更改往往发生在函数内，对我来说，这些更改比其他语言中出现的频率要低得多。我发现这根本不是问题。