Django開発者が犯したトップ10の間違い

このガイドでは、Django開発者の主な間違いを見て、それらを回避する方法を学びます。 この記事は経験豊富な開発者にとっても役立つ場合があります。なぜなら、非常に大きな設定のサポートや静的リソースの名前の競合などの間違いを犯すからです。

Djangoは、一般的な開発の問題の解決に役立つ無料のオープンソース、オープンソースのPythonフレームワークです。 これにより、柔軟で構造化されたアプリケーションを作成できます。 Djangoには、すぐに使用できる多くの最新機能が既にあります。 たとえば、私にとって、管理ツール、オブジェクトリレーショナルマッピング（ORM）ツール、ルーティング、テンプレートなどの機能は、開発ツールを選択する際の最初の候補になります。 アプリケーションの作成には多くの労力が必要であり、他の開発者と同様に私の仕事を楽しんで、日常業務にできるだけ時間をかけたくない。 Djangoは、アプリケーションの柔軟性を犠牲にすることなく、この点で非常に役立ちます。

Djangoのキラー機能は、モデルおよび管理者モデルのスキーマに基づいて自動的に（自動的に生成された）強力な構成可能な管理インターフェイスです。 あなたは魔術師のように感じます。 ユーザーは、管理インターフェイスを使用して、アクセス制御リスト（ACL）、行レベルのアクセス許可とアクション、フィルター、並べ替え順序（順序）、ウィジェット、フォーム、追加など、多くのものを構成できます。 URLヘルパーなど。 すべてのアプリケーションには管理パネルが必要だと思います。 メインアプリケーションがこのようなパネルを必要とするのは時間の問題です。 Djangoでは、迅速かつ便利に作成されます。

Djangoには、すべての主要なデータベースですぐに使用できる強力なORMもあります。 他のORMとは異なり、必要な場合にのみデータベースにアクセスします。 Pythonのソースコードから、言語の他のすべての機能とともに使用できる基本的なSQLステートメント（および関数）をサポートしています。

Djangoには、非常に柔軟で強力なテンプレートエンジンがあります。 多くの標準フィルターとタグが利用できますが、独自のフィルターとタグを作成することもできます。 Djangoは他のエンジンをネイティブテンプレートとしてサポートし、テンプレートを処理するための標準のショートカット機能を介して他のエンジンと簡単に統合するためのAPIを提供します。

フレームワークには、着信リクエストを解析し、ルーティングスキームに基づいて新しいURLを生成するURLルーターなど、他の多くの重要な機能もあります。 一般に、Djangoは一緒に作業するのが楽しく、助けが必要なときは、 ドキュメントを読んでください

間違い＃1.プロジェクトの依存関係にPythonグローバル環境を使用する

プロジェクトの依存関係にPythonグローバル環境を使用しないでください。依存関係の競合が発生する可能性があります。 Pythonは、複数のバージョンのパッケージを同時に使用する方法を知りません。 異なるプロジェクトが同じパッケージの異なる互換性のないバージョンを必要とする場合、これは問題になります。

通常、このような間違いは、Python環境の分離機能を認識していないPythonおよびDjango開発の初心者によって行われます。

環境を隔離するには多くの方法がありますが、最も一般的な方法は次のとおりです。

• virtualenv ：環境フォルダーを生成するPythonパッケージ。 環境をアクティブ化（および非アクティブ化）し、そこにインストールされているパッケージを管理するためのスクリプトが含まれています。 これが私のお気に入りで最も簡単な方法です。 通常、プロジェクトフォルダーに近い環境を作成します。
• virtualenvwrapper ：仮想環境の作成/削除/アクティブ化などのツールセットをグローバルにインストールし、このセットへのアクセスを提供するPythonパッケージ。 すべての環境は1つのフォルダーに格納されます（WORKON_HOME変数を使用して書き換えることができます）。 virtualenvwrapper
  
  
  
  代わりにvirtualenv
  
  
  
  を使用する利点はvirtualenvwrapper
  
  
  
  ません。
• 仮想マシン ：アプリケーション専用の仮想マシン全体よりも優れた分離はありません。 VirtualBox （無料）、 VMware 、 Parallels 、 Proxmox （私のお気に入り、無料版があります）など、多くのツールが利用可能です。 Vagrantなどの仮想マシン自動化ツールと組み合わせると、これは非常に強力なソリューションになります。
• コンテナ ：近年、私はほとんどすべてのプロジェクト、特にゼロから始める新しいプロジェクトでDockerを使用しています。 Dockerは多くの機能を備えた素晴らしいツールです。 それを自動化するためのサードパーティ製ツールの束が利用可能です。 Dockerにはレイヤーキャッシングがあり、コンテナーを非常に迅速に再作成できます。 各コンテナには独自のファイルシステムがあり、プロジェクトは高レベルで分離されているため、グローバルPython環境を使用します。 Dockerを使用すると、新しいチームメンバーは、特にこのテクノロジーの経験がある場合に、プロジェクトの作業をより早く開始できます。

間違い2。requirements.txtファイルに依存関係のバインディングがない

新しいPythonプロジェクトはすべて、 requirements.txtファイルと新しいサンドボックスで開始する必要があります。 通常、 pip/easy_install



使用して、 requirements.txt



を忘れずにすべてのパッケージpip/easy_install



インストールしrequirements.txt



。 通常、プロジェクトをサーバーまたはチームメンバーのマシンに展開する方が簡単です（ おそらくより正確です）。

requirements.txtファイルでは、依存関係の特定のバージョンを固定することも重要です。 通常、パッケージの異なるバージョンは、異なるモジュール、関数、および関数パラメーターを提供します。 下位バージョンでも、依存関係の変更によりパッケージが破損する場合があります。 これは、ライブプロジェクトがあり、それを定期的に展開する場合、非常に深刻な問題です。バージョン管理システムがないと、ビルドシステムは常にパッケージの最新バージョンをインストールするためです。

本番環境では、常にパッケージをバインドしてください！ これには非常に優れたpip-toolsを使用します。 依存関係の管理に役立つ一連のコマンドを提供します。 このツールは、 requirements.txt



自動的に生成しrequirements.txt



。このファイルには、依存関係だけでなく、ツリー全体、つまり依存関係の依存関係が関連付けられています。

依存関係リストの一部のパッケージを更新する必要がある場合があります（たとえば、フレームワークまたはユーティリティのみ）。 pip freezeに頼ると、どのパッケージでどの依存関係が使用されているかがわからないため、更新できません。 pip-toolsツールは、バインドした依存関係に従ってパッケージを自動的にバインドするため、どのパッケージを更新する必要があるかを自動的に決定します。 また、 requirements.txt



使用されているコメントのおかげで、どのパッケージがどの依存関係から来たかを常に把握できます。

さらに注意するために、依存関係のソースファイルをバックアップできます。 ファイルシステム、Gitフォルダー、S3フォルダー、FTP、SFTPにコピーを保管します-どこでも、手元に。 比較的小さなパッケージのリストから除外するとnpmの多数のパッケージが破損する場合があります 。 Pipでは、必要なすべての依存関係をソースファイルの形式でダウンロードできます。 詳細については、 pip help download



コマンドを実行してください。

間違い＃3.クラスベースビューの代わりに昔ながらのPython関数を使用する

特にテストビューやユーティリティビューの場合は、 views.py



アプリケーションファイルで小さなPython関数を使用することをお勧めします。 ただし、通常、アプリケーションでは、クラスベースビュー（CBV）を使用する必要があります。

CBVは、一般的なWeb開発タスクを実装する抽象クラスを提供する汎用表現です。 専門家によって作成されたCBVは、一般的な行動パターンのほとんどをカバーしています。 よく構成されたAPIがあり、CBVはOOPのすべての利点を享受する機会を提供します。 コードはよりクリーンで読みやすくなります。 リストの作成、CRUD操作、フォームの処理などにDjangoの標準ビュー関数を使用することの難しさを忘れてください。適切なCBVをビューに拡張し、プレゼンテーション動作を構成する関数またはクラスプロパティをオーバーライドできます（通常関数はプロパティを返します。CBVの代わりにプレゼンテーション関数を使用すると、コードをスパゲッティに変えることができるロジックを追加できます。

たとえば、プロジェクトでさまざまなミックスインを使用して、基本的なCBV動作をオーバーライドできます：ビューコンテキストの作成、行レベルでの承認の確認、アプリケーション構造に基づいたテンプレートパスの自動作成、スマートキャッシュの統合など。

アプリケーション名とビュークラス名に基づいてビューのテンプレート名を標準化するDjango Template Namesパッケージを作成しました。 私は毎日それを使用し、名前を選択するときに多くの時間を節約します。 CBVにmixinを挿入するだけです- class Detail(TemplateNames, DetailView):



-これで動作し始めます！ もちろん、私の機能を再定義して、モバイルレスポンシブテンプレート、ユーザーエージェント用の他のテンプレート、または他の何かを追加できます。

間違い4.「脂肪」表現と「薄い」（スキニー）モデルの記述

アプリケーションロジックがモデルからビューに転送される場合、これはビューにモデルに属するコードが含まれていることを意味します。 つまり、アイデアは「厚く」なり、モデルは「薄く」なります。

そして、「厚い」モデルと「薄い」ビューを書く必要があります。

モデル内のロジックを小さなメソッドに分割します。 これにより、これらを繰り返し使用したり、多数のソース（管理ユーザーインターフェイス、フロントエンドユーザーインターフェイス、APIエンドポイント、多数のビュー）から使用したりできます。 これには数行のコードのみが必要で、大量の行をコピーする必要はありません。 次回ユーザーにレターを送信する機能を作成するときは、電子メール機能を使用してモデルを展開し、コントローラーにロジックを作成しないでください。

これにより、コードをユニットテストに便利に使用できるようになります。これは、電子メールロジックを1か所でテストでき、各コントローラーでテストできないためです。 この問題の詳細については、 Django Best Practicesをご覧ください。 解決策は簡単です。「厚い」モデルと「薄い」ビューを作成します。 次のプロジェクトでこれを開始するか、現在のプロジェクトをリファクタリングします。

間違い5。巨大で遅いファイル設定

新しいDjangoプロジェクト設定ファイルにも、これらの設定の多くが含まれています。 また、実際のプロジェクトでは、特に開発、本番、およびステージング環境で異なる構成が必要な場合、ファイルは700行を超えて維持が難しくなります。

構成ファイルを手動で分割して個別のローダーを作成できますが、私は共著者である優れた、十分にテストされたPythonパッケージDjango Split Settingsをお勧めします。

このパッケージには、パスのワイルドカードをサポートし、構成ファイルを同じコンテキストにインポートするoptional



とinclude



2つの機能があります。 このため、以前にアップロードしたファイルで構成エントリを宣言することにより、構成を簡単に作成できます。 このパッケージは、Djangoのパフォーマンスにまったく影響を与えず、どのプロジェクトでも使用できます。

最小構成の例を次に示します。

 from split_settings.tools import optional, include include( 'components/base.py', 'components/database.py', 'components/*.py', # the project different envs settings optional('envs/devel/*.py'), optional('envs/production/*.py'), optional('envs/staging/*.py'), # for any local settings optional('local_settings.py'), )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

間違い6。オールインワンアプリケーション、不適切なアプリケーション構造、リソースの不適切な割り当て

Djangoプロジェクトは、いくつかのアプリケーションで構成されています。 Djangoの用語では、 アプリケーションは少なくとも__init__.py



およびmodels.py



を含むPythonプロジェクトmodels.py



。 Djangoの最新バージョンでは、 models.py



不要になり、 models.py



だけ__init__.py



十分です。

Djangoアプリケーションには、Pythonモジュール、Django 固有のモジュール （ビュー、URL、モデル、管理パネル、フォーム、テンプレートラベルなど）、静的ファイル、テンプレート、データベース移行、管理コマンド、ユニットテストを含めることができますモノリシックアプリケーションを、単純なロジックを備えた小さな再利用可能なアプリケーションに分割する必要があります。

アプリケーションの目的を1つまたは2つの短い文で完全に説明できる必要があります。 例：「ユーザーがアカウントをメールで登録およびアクティブ化できるようにします。」

プロジェクトフォルダーにprojectという名前を付け、アプリケーションをproject/apps/



配置することをお勧めします。 次に、すべてのアプリケーションの依存関係を独自のサブフォルダーに入れます。

例：

• 静的ファイル： project/apps/appname/static/appname/
  
  
  
  
• テンプレートタグ： project/apps/appname/templatetags/appname.py
  
  
  
  テンプレートタグproject/apps/appname/templatetags/appname.py
  
  
  
  
• テンプレートファイル： project/apps/appname/templates/appname/
  
  
  
  

すべての静的フォルダーは1つにマージされるため、アプリケーション名は常にサブフォルダーの名前のプレフィックスとして追加します。 また、2つ以上のアプリケーションにjs/core.js



がある場合、 settings.INSTALLED_APPLICATIONS



の最後のアプリケーションが以前のすべてのアプリケーションsettings.INSTALLED_APPLICATIONS



オーバーライドします。 プロジェクトでこのようなバグに遭遇し、チームメンバーがカスタム管理SPAパネルを実装し、そのようなファイルを提供したために、別の開発static/admin/js/core.js



再定義することに気付くまで、約6時間デバッグしました同じ名前。

多くのリソースとPythonモジュールを含むポータルアプリケーションの構造の例を次に示します。

 root@c5b96c395cfb:/test# tree project/apps/portal/ project/apps/portal/ ├── __init__.py ├── admin.py ├── apps.py ├── management │ ├── __init__.py │ └── commands │ ├── __init__.py │ └── update_portal_feeds.py ├── migrations │ └── __init__.py ├── models.py ├── static │ └── portal │ ├── css │ ├── img │ └── js ├── templates │ └── portal │ └── index.html ├── templatetags │ ├── __init__.py │ └── portal.py ├── tests.py ├── urls.py └── views.py 11 directories, 14 files
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この構造のおかげで、アプリケーションをいつでも別のPythonパッケージにエクスポートして、再び使用できます。 PyPiでオープンソースパッケージとして公開したり、別のフォルダーに移動したりすることもできます。 このプロジェクト構造のようなものが得られます：

 root@c5b96c395cfb:/test# tree -L 3 . ├── deploy │ ├── chef │ └── docker │ ├── devel │ └── production ├── docs ├── logs ├── manage.py ├── media ├── project │ ├── __init__.py │ ├── apps │ │ ├── auth │ │ ├── blog │ │ ├── faq │ │ ├── pages │ │ ├── portal │ │ └── users │ ├── conf │ ├── settings.py │ ├── static │ ├── templates │ ├── urls.py │ └── wsgi.py └── static └── admin ├── css ├── fonts ├── img └── js 25 directories, 5 files
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、実際のプロジェクトはより複雑になりますが、そのような構造は単純化され、多くの側面をより透明にします。

間違い＃7. STATICFILES_DIRSとSTATIC_ROOTはDjango開発の初心者を混乱させます

静的ファイルは、アプリケーションを使用しても変化しない資産です。 たとえば、JavaScript、CSS、画像、フォントなどです。Djangoでは、展開中にパブリックディレクトリに「蓄積」します。

開発モード-python python manage.py runserver



-Djangoは、 STATICFILES_FINDERSを設定して静的ファイルを検索します。 デフォルトでは、 STATICFILES_DIRSにリストされているフォルダー内で要求されたファイルを見つけようとします。 見つからない場合は、 django.contrib.staticfiles.finders.AppDirectoriesFinder



で検索し、プロジェクトにインストールされている各アプリケーションのstatic



フォルダーをチェックします。 このスキームにより、独自の静的ファイルが付属する再利用可能なアプリケーションを作成できます。

本番環境では、nginxなどの個別のWebサーバーを介して静的データを配布します。 彼は、Djangoプロジェクトのアプリケーションの構造や、静的ファイルが配布されているフォルダーについては何も知りません。 幸いなことに、Djangoはcollect static managementコマンドSTATICFILES_FINDERS



python manage.py collectstatic



STATICFILES_FINDERS



を提供します。このコマンドはSTATICFILES_FINDERS



を通過し、 static



アプリケーションフォルダーとSTATICFILES_DIRS



にリストされたフォルダーからすべての静的ファイルを指定したSTATICFILES_DIRS



します。 STATIC_ROOTディレクトリに。 これにより、開発モードのDjangoサーバーと同じロジックを使用してリソースを静的データの形式で解決し、Webサーバーのすべての静的ファイルを1か所で収集できます。

実稼働環境でcollectstaticを実行することcollectstatic



忘れないでください！

間違い8。実稼働環境のデフォルトSTATICFILES_STORAGEおよびDjangoテンプレートローダーを使用する

実稼働環境の資産管理について話しましょう。 「資産が期限切れになることはありません」というポリシーを使用すると、最高のUXを提供できます（リソースは期限切れになりません）（詳細については、 こちらを参照してください）。 つまり、すべての静的ファイルは、ブラウザで数週間、数ヶ月、または数年もキャッシュされる必要があります。 つまり、ユーザーはリソースを1回だけダウンロードする必要があります。

クールなアイデアであり、静的ファイルを含むフォルダーのnginx設定のほんの数行で実装できます。 しかし、キャッシュの関連性をチェックするのはどうですか？ ユーザーがリソースを1回だけダウンロードした場合、メニューのロゴ、フォント、JavaScript、またはテキストの色を更新したらどうしますか？ この問題を解決するには、展開ごとに静的ファイルごとに一意のURLと名前を生成する必要があります！

これを行うには、 ManifestStaticFilesStorageをSTATICFILES_STORAGE



として使用し（注意、ハッシュはDEBUG=false



モードでのみ有効になっている）、 STATICFILES_STORAGE



コマンドを実行できます。 これにより、実稼働サイトからのリソース要求の数が減少し、はるかに高速になります。

Djangoのクールな機能は、キャッシュされたテンプレートローダーです。 再起動せず、レンダリングのたびにテンプレートファイルを解析します。 テンプレートの解析は非常に高価な操作であり、多くのコンピューティングリソースが必要です。 デフォルトでは、Djangoテンプレートはすべてのリクエストで解析されます。これは、特に数千のリクエストを短時間で処理できる本番環境では不適切です。

cached.Loader構成セクションで、問題の解決策の良い例と詳細を見つけることができます。 ブートローダーは、ファイルシステムから解析済みテンプレートをリロードしないため、開発モードでは使用しないでください。 テンプレートを変更するたびに、 python manage.py startapp



を使用してプロジェクトを再起動する必要があります。 開発中、これは煩わしいかもしれませんが、実稼働環境には理想的です。

間違い＃9.ユーティリティまたはスクリプト用の純粋なPython

Djangoには優れた機能管理チームがいます。 プロジェクトのユーティリティ用に、純粋なPythonでのスクリプト形式で自転車を発明する代わりに、それらを使用してください。

また、 Djangoのカスタム拡張機能のコレクションであるDjango Extensionsパッケージも確認してください。 おそらく誰かがあなたのチームを既に実装しているのでしょう！ 多くの一般的なターゲットチームがあります。

間違い番号10。サイクリング

DjangoとPythonには、何千もの既製のソリューションがあります。 まったくユニークではない何かを書く前に、検索エンジンに頼ってください。 おそらくすでに適切なソリューションがあります。

複雑にする必要はありません。 最初のグーグル！ 見つかった品質のパッケージをインストールし、構成し、展開し、プロジェクトに統合します。 そして可能であれば、オープンソースに貢献してください。

Djangoが自分で始めるためのパッケージのリストは次のとおりです。

• Django Macros URL ：マクロを使用すると、DjangoアプリケーションでURLパターンを簡単に記述（および読み取り）できます。
• Django Templates Names ：CBVテンプレートの名前を簡単に標準化するのに役立つ小さなミックスイン。
• Djangoの分割設定 ：複数のファイルとディレクトリにDjango設定を配布できます。 設定を簡単にオーバーライドおよび変更します。 ファイルパスでワイルドカードを使用し、構成ファイルをオプションとしてマークします。

繰り返してはいけません（DRY）！

私はDRYコンセプトのサポーターなので、 Djangoスケルトンを作成しました。これは、すぐに使用できる便利な機能を備えた便利なツールです。

• docker-composeによって管理される開発/生産用のDockerイメージ。コンテナーのリストを簡単に調整できます。
• 実稼働環境にデプロイする単純なFabricスクリプト。
• ベースおよびローカルソースの設定を含むパッケージDjango Split Settingsの構成。
• Webpackプロジェクトに統合-collectstaticコマンドを実行すると、Djangoはdistフォルダーのみを収集します。
• プロダクションのキャッシュされたDjangoテンプレート、ハッシュされた静的ファイル、デバッグ用の統合ツールバー、ロギングなど、すべての基本的なDjango設定と機能が構成されます。

これは、次のプロジェクトですぐに使用できる、すぐに使用できるDjangoスケルトンです。 時間を大幅に節約できることを願っています。 Webpackの基本構成は最小限ですが、SASSを使用して、事前構成された.scssファイルをインストールして処理します。