抽象度の上下関係を明示する

↓まだ全然結論出てない2023/9/9

アプリケーションをボトムアップに眺めてみると、

variableやfunctionやclassといったものが最小単位で存在し、

それらの組み合わせで、fileやdirectoryやmoduleという集合を組み立てていく

functionの組み合わせでfunctionを作り、という形で組み立てる

そうすると、当然functionごとに扱う抽象度が変わってくる

この時、function同士を見比べた時にどちらが上位の抽象度を扱っているのかが即座に分かる表現になっていると良い

そしてこれはfunctionレベルの話だけではなく、fileやdirを見たときも同じ

以下のことが明確になっていれば良い

個々の関数が、個々の責務を担っている

それらがレイヤーに分かれている

レイヤーに分かれていることが、何かを見れば明確にわかる

例えば、AとBがあるときに、どっちが上位の概念なのかが、何かをみれば明確にわかる

評価を無視すれば無限に策は考えられる

関数ごとにコメントで番号を振る

名前で明示する

例えば、hogeUsecase, hogeRepositoryみたいな関数名にする

例えば、usecases/, repositories/のようなdirを作る

番号でも良い

ファイル内の定義場所を工夫する

1つのファイル内の上の方にある方が具体的

レイヤーが上のものを特定して、ipmort文を見ればわかる

その対象がファイルツリー上でフラットに並んでいたとしても

この中から、他の問題の解決にも繋がるような良いものを選択する

上に挙げたコメント等で番号を振るのは、メンテコストが高すぎなので、多くの場合で論外だろう、と容易に判断がつく

関数によっては、以下の2パターンにわかれそう

一部のレイヤーでのみ使われるもの

各feature内に入っているもの

レイヤーを横断的に使われる汎用的なもの

utility的なもの、汎用的なreact componentとかもこれ

PBFでcommon/とかに置くやつ

ただ、まあ実際はそこまで問題にならなさそう？

どんなプログラムにもエントリポイントが存在する

いや別にそれは関係ないか

何が嬉しいのか？

読む時に助かる

コードを読むときって、基本的に抽象度の高いものから徐々に下げていく

抽象度の高い状態で全体を見つつ、興味あるところは詳細を見ていく

その時に、どこから読めばよいのかのヒントが欲しい

実装の変更容易性を担保できる

そこを意識できてないと、こんなの実現できるわけ無いので。

また、できればその違反を静的に検出できるとかなり良い

1 file 1exportみたいなことを徹底すれば、なにか見えるかもしれない

あんまりやりたくないが

なんか前に、そういう強めの主張をしてる記事あったな

言葉が強くて批判されがちだけど、可能性は感じる

default exportとかは脇に置いておいて

コメントで、create, fetch, update, deleteを個々のファイルに分けるのは細分化しすぎ、という反応があるけど、それが問題とも限らない

ただ、

ファイルツリーでactionが一覧できることと、

1ファイルの中でactionが一覧できること

いやあるな

create/

repositories.ts

routes.ts

と

repositories.ts (中にcrud)

routes.ts (中にcrut)

だと、前者のほうが、関係ある者同士の結びつきが強い (良い)

これとこれは想定しているレイヤーが異なるよ、というのを何かしらで明示したい

レイヤーというのは、View、UseCase、Entity、Repository的なやつ

ファイル名で表現したり、

1ファイル内に全て書くなら、命名とかで伝わる？

極端なことを言えば、

ファイルツリーの階層で、依存関係を明示できる

流石にやらんが

言えばいいので

ただ、ファイルがフラットに並んでいると、その間の上下関係が、見るだけでは伝わらない

repositoryというのは、こういうもので〜、というのは流石に知ってないといけない

レイヤーが違うよ、というのが明確になっていないと変な修正が入る可能性がある

この関数は外部とアクセスしないんだよ！みたいな

この関数は抽象度高めなので、分岐させないんだよ！みたいな

レイヤーじゃなくてもある

A,B,Cがある時に、概念レベルではA←B←Cという依存関係で計算する、と設計したものは、論理的にはA→B→Cのように計算することもできてしまう

例えば

b = a + 1, c = b + 2のとき

a = b - 1, b = c - 2とできちゃうよね

登場人物がもっと多くなった時に、その複雑さをどうやって表現するか

まずFigJamで依存関係の方向を列挙したが、それをコードで上手く表現できてるかは微妙

実装的には正しいけど、コードだけ読んだ人がFigJamの図をパッとイメージできるかというとそうなってなさそう

特に、UseCaseとEntity(というかコアなビジネスロジック？)の違いをどうやれば伝えられるか

これらを同じファイルに書いたとき、抽象度の高い前者のみがpublicになる