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.pymodels.pyurls.pymiddlewares.py 、 Scrapyの spiders.pyitems.pymiddlewares.py があります。

cover

(中略)詳細は書籍 自走プログラマー をご参照ください