どの様な話？
プログラムの一部分が結果として出来るには、必ず原因（複数も有り）が必要です。*1
また、典型的な原因として、「大データへの読み書き＆保全」が有ります。*2
「大データへの読み書き＆保全」は、相独立した部分に分ける事も可能だと思いますが、1つの部分部分はそれほど小さくならないと思います。
そして、「原因が、複数の独立・直交した部分原因に分かれる」のを管理するのは、因果ダイアグラムの独壇場だと思います。
「fat」を恐れる
1つのクラスに何でもかんでも入れるのはダメだ言われています。ましてや、utilsクラスや、toolsクラスなんてもってのほかだと言われています。
これはごもっともだと思います。
しかし「fat」を止めて、分ける事に意味は有るのでしょうか？
以下の理由で意味に乏しいと考えます。それは、
- いくら分割しても、原因は付いて回る
- 原因を同じくする、分割されたプログラムの部分たちは、テストの観点からは、分割されていない（も同然）。字面だけ分割しても、分割されていない。分割したと見えるのは幻想で、誤謬だから
です。
いくら1つのRDB更新や、仮想DOMが上手く行っても、全体が壊れていたら、意味が無く、なぜ全体が存在するかと言うと、同じ原因で責務を跨いでいるからです。
原因部分テストと原因悉皆テスト
smallなテストは、大抵、原因部分テストになると思います。largeなテストをして初めて、原因悉皆テストになると思います。
原因部分テスト（のみ）では、男女を分けて分析すると違う曲線に回帰するかの如く、誤って誤りを正しいとしてしまう事が多々有ると思います。
出版バイアス
原因部分テスト＝原因悉皆テストとなる様な、（一種）病的な例のみ、
- うまく行く事例
として出版され、そうでは無い大多数の事例は無視されるので、smallテストの（のみの）異様な持ち上げが出来していると思います。
結論
いくら分割しようとも、共通の原因が分割された複数箇所にある以上、テストの観点からは意味が有りません。
しかし、分割は良い側面も有り、そうする様に勧める事は、止まる余地が有りません。
これからも『「fat」を恐れる』事でプログラミングが嫌いになる人は存在し続けることでしょう。
