1. 開発前に全体を考える

プロジェクト全体の構想をある程度練る。アカウント機能はいるのか。機能A、機能B...など。それらに伴い、それぞれのApplicationを大きくしすぎない（views.pyなどが冗長になり、みづらい。アカウント機能と、サービスAが同じアプリにいるのは見栄えがよくない）

2.settings.pyを切り分ける

manage.py自体は、

manage.py

#!/usr/bin/env python
"""Django's command-line utility for administrative tasks."""
import os
import sys


def main():
    """Run administrative tasks."""
    #os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'zissyu_navi.settings.production')
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "<project_name>.settings")
    try:
        from django.core.management import execute_from_command_line
    except ImportError as exc:
        raise ImportError(
            "Couldn't import Django. Are you sure it's installed and "
            "available on your PYTHONPATH environment variable? Did you "
            "forget to activate a virtual environment?"
        ) from exc
    execute_from_command_line(sys.argv)


if __name__ == '__main__':
    main()

のようにあり、この

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "<project_name>.settings")

の箇所で、参照するsettings.pyを指定している。

一つのsettings.pyに、DEBUG=TrueやDEBUG=Falseとしてもいいが、毎度書き換えるのは面倒臭いし、ミスの原因になる。そのため、開発環境用と、本番環境用にそもそも、分けてしまう。

そうすることで、python manage.py runserver時に、manage.pyの箇所を変えるだけで良い。例えば、python dev.py runserverやpython production.pyなど。

なお、ファイル構成を

- settings
    - base.py
    - dev.py
    - production.py

とすることで、共通する部分（base.py）を開発環境・本番環境用ファイルでimportすることで違う点を明確にできる。（imageディレクトリやメールサーバー設定など。）

3. `.env`を最初から作っておく

環境の切り分けは後々聞いてくる。だったら、はなからやる。

4. docker、docker-composeで開発する

DBやwebサーバーなど、本番環境と同様の環境を構築すると良い。
特に、DBの違いはデプロイ時の障害になりがち。

5. test.pyを使う

開発して終わりでなく、動くことを担保する。testプログラムを上手に書ける大人でありたい。

6. `templates`や`static`ディレクトリは上手にまとめる。

以下の構成を考えてみます。

- project
    - appA
    - appB
    - manage.py
    - template
        - base.html
        - appA_main.html
        - appA_sub.html
        - appA_landing.html
        - appA_form.html
        - appB_main.html
        - appB_sub.html
        - appB_landing.html
        - appB_form.html

templatesディレクトリが冗長になり、プロジェクトが大きなると、管理が面倒です。
下記のように、アプリごとの親ディレクトリを作るべきです。

- project
    - appA
    - appB
    - manage.py
    - template
        - base.html
        - appA
            - main.html
            - sub.html
            - landing.html
            - form.html
        - appB
            - main.html
            - sub.html
            - landing.html
            - form.html

7. Classベース開発

views.pyなどで、関数形式だと書きやすい反面、保守性がさがり、読みづらいコードになります。せっかくDjangoにあるClass（TemplateView,View,FormView,ListViewなど）を使って開発しましょう。慣れるまで、大変ですが、短いコードで書けます。

とりあえず、思いつく限り書きました。今後また思うところがあれば改善していきます。
ぜひ、コメントください。

最終更新日

2021/2/27
2021/08/08

新規Djangoプロジェクトの開始時に役立つこと