18:モジュール名のオススメ集¶
「モジュールを分けましょう」と指摘されても、具体的にどんな名前で分割すべきなのでしょう。 ここでは失敗例と、オススメのモジュール名を説明します。
具体的な失敗¶
.
├── common.py
├── utils.py
└── main.py
モジュールの分割が少なく、一部のモジュールが大きくなりすぎるのは問題です。 「商品を購入する関数はどこにある？」と疑問になったときに、探すのが難しくなります。 また、1つのファイルが大きすぎるとエディターが遅くなる問題や、複数人で開発したときに変更が衝突しやすくなる問題もあります。
ベストプラクティス¶
モジュールは、意味でまとめられるときに積極的に分割しましょう。
さらに、モジュールが大きくなった場合はパッケージ（__init__.py のあるディレクトリー）にまとめると良いでしょう。
たとえば、商品（item）の一覧や購入をするプログラムのパッケージとモジュールの構造は以下のようになります。
.
├── api # 外部APIにアクセスする処理をまとめる
│ ├── __init__.py
│ ├── item.py # 商品に関するAPI処理をまとめる
│ └── user.py # ユーザーに関するAPI処理をまとめる
├── commands # コマンドラインツールのサブコマンドをまとめる
│ ├── __init__.py
│ ├── list.py # 商品の一覧を表示するコマンドの入出力を扱う処理をまとめる
│ └── purchase.py # 商品の購入をするコマンドの入出力を扱う処理をまとめる
├── consts.py # バックエンドAPIのホストなど定数をまとめる
├── main.py # ツールのエントリーポイントのmain関数を置く
├── models.py # 商品やユーザーのデータを永続化するクラスをまとめる
├── purchase.py # 商品を購入する処理をまとめる
└── validators.py # コマンドラインからの入力をチェックする処理をまとめる
フレームワーク の制約がある場合は基本的に従いましょう。
たとえばDjangoの views.py 、 models.py 、 urls.py や middlewares.py 、
Scrapyの spiders.py 、 items.py 、 middlewares.py があります。
（中略）詳細は書籍 自走プログラマー をご参照ください
