clojure的長文件有什麼用？

Question

我一直在學習clojure幾個星期，最近我開始閱讀一些開源代碼：clojure和clojurescript編譯器以及一些類似om，boot，figwheel等庫。

我注意到一些Clojure的文件是很長的，他們中的一些千餘LOC。鑑於clojure的代碼非常簡潔而低級，該代碼意味着比其他語言中的文件大得多的代碼。

從OO背景的，你通常有每個文件一類和你儘量保持你的類短（SRP）我發現有點怪異。

我知道clojure代碼主要由純函數組成，它們比一些需要保持當前狀態的可變類更容易推理，我發現我可以閱讀和理解大多數一次一個的功能。但大多數功能設計得非常好，以至於它們不依賴於彼此：儘管您可以使用(filter odd?)，但這並不意味着filter和odd?是相關的。但對於「每一天」的代碼（LOB應用程序，網絡應用程序等）來說，很難保持這些函數的自包含性（至少這是我的OO編程經驗）。

我也看到的，他們在同一個文件中聲明的所有組件clojurescript應用程序（OM，試劑等）的一些演示。我不知道這是因爲它只是一個演示，在實際生活中的應用，你就會有一個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的合併衝突，不過因爲變化往往在函數中出現，對我來說，這比在其他語言中少得多。我發現這根本不是問題。

Answer 2

1. 它們往往會隨着您的發展而變長。假設你需要一個函數foo來執行數據結構K上的過程[ab ...]。首先（def）函數的簽名並繼續執行輔助函數ab ...因爲它們可能都是純函數和函數你需要foo是複雜的，命名空間往往會變長。

2. 有時候，但repl是一個非常有用的工具，爲了理解一個新庫的主要功能，我經常在函數中使用clojure.repl/source，並在其輔助函數上反向工作。我發現很多時候Clojure圖書館的文檔都不是神祕或不存在，但是社區中很多人喜歡說Clojure的功能來源是自我記錄。

3. 我沒有在大型團隊中工作的經驗，但Arthur Ulfeldt是正確的大多數變化發生在一個函數中，我通過閱讀Github的Blame特性的pull請求的差異來收集它。

Answer 3

1. 它是務實（Clojure的或不），以避免依賴關係。對抽象事物進行命名和分類會讓我們的智力感覺良好，但在將所有零件縫合在一起時，它會放棄。爲什麼要做三個文件？
2. 只需閱讀代碼，就可以瞭解應用程序/庫的全部內容？有「什麼」，還有「如何」。如果你想深入後者，最好有一個關於前者的線索。如果您正在閱讀代碼以獲取有關應用程序目的的線索，我不確定是否將其分割爲更多文件會使其更容易。想想你的榜樣，如果沒有其他的東西，這些東西都不會存在。
3. 大團隊的困難是共享最新的知識，而不是文件或行，謝謝git。也許讓每個人都在同一個文件中畢竟是件好事？ 不，大文件在clj或其他方面不是問題。單元< - >文件是一個完全javartificial概念，幫助編譯器，而不是男人。拆分fg緩衝區。

Answer 4

除了別人給出的答案之外，這裏還有兩個。

1. 這可能是一些文件很長，因爲Clojure中它是最簡單的使用每個命名空間的一個文件，所以，如果你想都在同一個命名空間的定義，它更容易把它們放在一個文件。在＃2中給出了讓定義駐留在相同名稱空間中的一個原因。

2. Clojure編譯器不允許命名空間之間的某些種類的循環依賴（命名空間之間的其他循環依賴很好）。避免非法循環依賴的一種方法是將相互依賴的定義放入相同的名稱空間中。如果你這樣做，將其他有問題的定義放入單個命名空間也是有意義的。請參閱＃1瞭解其他答案。

（我自己的味道是幾個較小的文件，雖然許多Java類文件不小。另外：代碼功能，通常不如自文檔作爲筆者認爲這可能保持甚至當筆者和稍後閱讀代碼的人是同一個人。）