===========================
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      # コマンドラインからの入力をチェックする処理をまとめる

:index:`フレームワーク` の制約がある場合は基本的に従いましょう。
たとえばDjangoの ``views.py`` 、 ``models.py`` 、 ``urls.py`` や ``middlewares.py`` 、
Scrapyの ``spiders.py`` 、 ``items.py`` 、 ``middlewares.py`` があります。

.. omission::


関連
=========

* :doc:`../ライブラリ/99-フレームワークの機能を知ろう`