haskell-jp / questions #104 at 2023-08-23 18:50:36 +0900

Haskellのライブラリをどのくらいの粒度でパッケージ分割したらいいのかの基準が自分の中でまだ整理が付いていないのですが、良い資料をご存知の方、もしくは考えをお持ちの方はいらっしゃいますか？

以前、いわゆる「Internalモジュール」パターンは間違っていて、Internalモジュールが作りたくなったらパッケージ分割の合図だろうといった旨の↓の記事を見まして。
記事の内容には完全に同意なのですが、すると、究極的にはなるべく細かく分割するのがよいのではないかと思うようになってしまいました。
分割を止める基準、つまりトレードオフの「分割すべきでない」側の壁がどの辺りにあるのかが分からなくなっています。

http://nikita-volkov.github.io/internal-convention-is-a-mistake/

個人的にはもっと重要な理由が生じない限り分けない方がいいと思いますね。
さーっと読んだだけですが、その記事に書いてあることを採用してもPVPをちゃんと守れる以上のメリットが見当たらず、パッケージを分ける面倒くささに見合うと思えないので。

ありがとうございます
なんとなく、パッケージの中で使われない部分はコンパイル時間を増大させるだけの無駄になってしまうということで、管理の面倒くささ（コスト）が許す範囲であればいくらでも細分化すべきくらいの勢いでも良いのかなと考えていたのですが、そうでもないっぽいですね…

依存関係がなるべく小さくなるように分ける、という基準は、コンパイル時間が短くなる、コンパイルがしやすくなるといった、パッケージを使う側にとって大きなメリットがあるのでお勧めです。

なるほど、依存に着目するのは確かによさそうです！依存の数の最小化問題（逆に、これ以上依存が減らせないのであればそこで分割を止める）って考えれば割と機械的に考えられそうです