博士

やあ、ロボ子。今日はファイル構造について話すのじゃ。

ロボ子

博士、ファイル構造ですか。なんだか奥が深そうですね。

博士

そう、ファイル構造は単なる整理術ではないぞ。プロジェクトのメンテナンスのしやすさに大きく影響するのじゃ。

ロボ子

メンテナンスのしやすさ、ですか。具体的にはどのような要素が関係してくるのでしょうか？

博士

変更の容易さ、構造が目的を明確に伝えること、そして明確な知識の境界じゃな。これらが揃うと、コードは格段に扱いやすくなるぞ。

ロボ子

なるほど。ファイル構造には、タイプ別のグループ化とコンテキスト/プロセス別のグループ化という2つの方法があるそうですね。

博士

そうじゃ。タイプ別は、例えば「クラスの種類ごとにファイルを整理する方法」じゃな。特定の種類のファイルを簡単に見つけられるのがメリットじゃ。

ロボ子

でも、記事によると「コードが実際に何をしようとしているのかというコンテキストが失われる」というデメリットもあるんですね。

博士

その通り。プログラミング言語の観点からは整理されていても、ドメインの観点が抜け落ちてしまうのじゃ。

ロボ子

コンテキスト/プロセス別のグループ化は、ドメインロジックを反映した構造とのことですが、具体的にはどういうことですか？

博士

例えば、プロジェクトマネージャーからの指示を直接ファイル構造に反映できるのじゃ。システムの構造を理解しやすくなるのが利点じゃな。

ロボ子

記事では、Deep Linkingモジュールのファイル構造の例が挙げられていますね。AndroidとiOSでサブドメインが分かれているのが興味深いです。

博士

そうじゃ。それぞれのサブドメインが、ベンダー固有の実装を反映した内部構造を持っているのがポイントじゃな。

ロボ子

ファイル構造の選択は、チームの目標や規模によって変わってくるんですね。

博士

その通り。技術的なタスクが多いならタイプ別、ドメインの明確さが重要ならコンテキスト/プロセス別を選ぶと良いぞ。

ロボ子

勉強になります！ ちなみに博士は、どちらのファイル構造がお好みですか？

博士

私はもちろん、コンテキスト/プロセス別じゃ！ なぜなら、お菓子を隠す場所を構造化できるからな！

ロボ子

博士、お菓子ですか…（呆）。