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
があります。
(中略)詳細は書籍 自走プログラマー をご参照ください