技術

Django開発者が犯す間違いトップ10

このチュートリアルでは、Django開発者がよく犯すいくつかのよくある間違いと、それを回避する方法について説明します。このチュートリアルは、熟練したDjango開発者であっても役立ちます。管理できないほど大きな設定を維持したり、静的アセットで名前の競合が発生したりするなどの間違いは、Djangoに最初に挑戦した新しい開発者だけに限定されないためです。

Djangoは無料のオープンソースPythonWebフレームワークであり、一般的な開発の課題を解決し、柔軟で適切に構造化されたアプリケーションを構築できます。 Djangoには、すぐに使用できる多くの最新機能があります。個人的には、管理、オブジェクトリレーショナルマッピングツール（ORM）、ルーティング、およびテンプレート機能により、Djangoが最初の選択肢になりました。これは、アプリケーションに多くの作業が必要であり、開発者ができる限り仕事を楽しんでいる間、費やしたいからです。これらの基本的な反復タスクにできるだけ時間をかけないでください。 Djangoを使用すると、柔軟性を損なうことなく、これらすべてを実行できます。

Djangoのキラー機能は、モデルのスキーマと管理パネルモデルから自動的に（自動的に？）構築される強力な構成可能な管理インターフェースであり、ウィザードのように感じさせます。ユーザーは、管理インターフェースを介して、アクセス制御リスト（ACL）、行レベルのアクセス許可とアクション、フィルター、順序、ウィジェット、フォーム、追加のURLヘルパー、その他想像できるあらゆるものを構成できます。すべてのアプリケーションに管理パネルが必要だと思います。まだの場合は、基本的なアプリケーションに管理パネルが必要になるのは時間の問題です。 Django adminを使用すると、すばやく柔軟に作成できます。

Djangoには強力なORMがあり、すべての主要なデータベースですぐに使用できます。怠惰なため、他のORMとは異なり、必要な場合にのみデータベースにアクセスします。 Pythonソースコードから使用できるすべての主要なSQL命令（および関数）をサポートし、Pythonの機能により非常に快適に感じられます。

Djangoのテンプレートエンジンは、非常に柔軟性があり、同時に強力です。あなたは多くの標準を使うことができますフィルタとタグまた、プロジェクト用の新しいカスタムフィルターとタグを作成します。 Djangoは、他のテンプレートエンジンとDjangoテンプレートをサポートし、テンプレート処理用の標準ショートカット関数を介して他のテンプレートエンジンを簡単に統合するためのAPIを提供します。

Djangoには、着信リクエストを解析し、ルータースキーマから新しいURLを構築できるURLルーターなど、他にも多くの大きな機能があります。全体として、Djangoフレームワークは快適な体験であり、助けが必要なときはいつでも、ドキュメンテーション。

間違いその1：プロジェクトの依存関係にグローバルシステムPython環境を使用する

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

この間違いは通常、Pythonの環境分離機能について知らない新しいPythonおよびDjango開発者によって引き起こされます。

環境を分離する方法はたくさんありますが、最も一般的な方法は次のとおりです。

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

あなたが私に尋ねるなら、私はvirtualenvを好みますプロジェクトの依存関係の分離と管理のためのPythonパッケージとDockerコンテナ。

間違いその2：プロジェクトの依存関係を`requirements.txt`に固定しないファイル

すべての新しいPythonプロジェクトは、 Requirements.txt ファイルと新しい隔離された環境。通常、すべてのパッケージはpip/easy_installを介してインストールしますただし、requirements.txtに追加することを忘れないでくださいファイルも。これにより簡単になります（可能より適切な場合）プロジェクトをサーバーにデプロイするか、チームメンバーが自分のマシンでプロジェクトをブートストラップするため。

javascriptにクラスはありますか

さらに、それは同じように重要ですピン requirements.txt内の依存関係の特定のバージョンファイル。通常、パッケージのバージョンが異なれば、モジュール、関数、および関数パラメーターも異なります。依存関係のマイナーなバージョン変更でさえ、パッケージを壊す可能性があります。プロジェクトが稼働中で、定期的にデプロイをスケジュールしている場合、これは非常に深刻な問題です。バージョン管理を行わないと、ビルドシステムが常に最新バージョンのパッケージをインストールするためです。

常にパッケージを本番用に固定してください！個人的には、と呼ばれるとても素敵なツールを使用しています pip-tools これは私がこれを行うのに役立ちます。依存関係の管理に役立つ一連のコマンドラインツールを提供します。 requirements.txtを自動的に生成しますこれにより、依存関係だけでなく、依存関係の依存関係を含む依存関係ツリー全体が固定されます。

依存関係リストから一部のパッケージのみを更新したい場合があります（たとえば、Django / Flask /任意のフレームワークまたはユーティリティのみ）。「pipfreeze」を使用した場合、どの依存関係がどのパッケージに対応しているかわからないため、依存関係をアップグレードできません。ただし、pip-toolsを使用すると、固定した依存関係に応じてパッケージが自動的に固定されるため、更新が必要なパッケージが自動的に解決されます。ボーナスとして、requirements.txtのコメントでパッケージをマークする方法により、どのパッケージがどの依存関係からのものであるかも正確にわかります。ファイル。

特に注意するために、依存関係のソースファイルもバックアップすることをお勧めします。ファイルシステム、Git管理フォルダー、S3フォルダー、FTP、SFTPなど、どこにでもコピーを保存しますが、手元に置いておきます。場合がありますリストにない比較的マイナーなパッケージがnpmで多数のパッケージを壊しました。 Pipは、必要なすべての依存関係をソースファイルとしてダウンロードするためのツールを提供します。詳細については、pip help downloadを実行してください。

間違いその3：クラスベースのビューの代わりに古いスタイルのPython関数を使用する

アプリケーションのviews.pyで小さなPython関数を使用することをお勧めする場合があります。特にテストまたはユーティリティビュー用のファイルですが、通常、アプリケーションではクラスベースビュー（CBV）を使用する必要があります。

CBVは、専門家によって構築され、すべての一般的な動作をカバーする一般的なWeb開発タスクを実装する抽象クラスを提供する汎用ビューです。それらは驚くべき構造化APIを備えており、CBVを使用すると、オブジェクト指向プログラミングのすべての利点を利用できます。それはあなたのソースコードをより明確で読みやすくします。リスト、CRUD操作、フォーム処理などにDjango標準ビュー関数を使用する手間を忘れてください。ビューに適したCBVを拡張し、クラスのプロパティまたは関数をオーバーライドするだけです（通常、関数はプロパティを返し、そこに任意のロジックを追加できます）ビューの動作を構成する（CBVの代わりにビュー関数を使用する場合）ソースコードからスパゲッティを作成します。

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

名前の付いたパッケージを作成しました Djangoテンプレート名、アプリケーション名とビュークラス名に基づいてビューのテンプレート名を標準化します。私は毎日それを使用し、名前を発明するための私の時間を大幅に節約します。ミックスインをCBVに入れるだけで— class Detail(TemplateNames, DetailView): —動作を開始します！もちろん、私の関数をオーバーライドして、モバイルレスポンシブテンプレート、ユーザーエージェント用のさまざまなテンプレート、またはその他の必要なものを追加できます。

間違いその4：ファットビューとスキニーモデルを書く

モデルではなくビューでアプリケーションロジックを記述するということは、モデルに属するコードをビューに記述し、それを「ファット」にし、モデルを「スキニー」にすることを意味します。

あなたは太ったモデル、細い見方を書くべきです。

モデルのロジックを小さなメソッドに分割します。これにより、大量のコードをコピーして貼り付ける代わりに、数行のコードで複数のソース（管理インターフェースUI、フロントエンドUI、APIエンドポイント、複数のビュー）から複数回使用できます。したがって、次にユーザーにメールを送信するときは、コントローラーでこのロジックを記述する代わりに、メール関数を使用してモデルを拡張します。

これにより、これが行われるすべてのコントローラーで繰り返しではなく、1つの場所で電子メールロジックをテストできるため、コードの単体テストが容易になります。

C ++の使い方

あなたはで問題についてもっと読むことができます Djangoのベストプラクティス事業。解決策は簡単です。ファットモデルとスキニービューを作成するので、次のプロジェクトでそれを実行しましょう（または現在のプロジェクトをリファクタリングします）。

間違いその5：巨大で管理しにくい設定ファイル

新しいものでさえ Djangoプロジェクト設定ファイルたくさんの設定があります。実際のプロジェクトでは、設定ファイルは700行以上の構成になり、特に開発、本番、およびステージング環境のすべてにカスタム構成が必要な場合は、保守が困難になります。

構成ファイルを手動で分割してカスタムローダーを作成することもできますが、十分にテストされた優れたPythonパッケージを紹介したいと思います。 Djangoスプリット設定、私が共著したこと。

パッケージは2つの機能を提供します— optionalおよびinclude-パスのワイルドカードをサポートし、同じコンテキストで構成ファイルをインポートします。これにより、以前にロードされたファイルで宣言された構成エントリを使用して構成を簡単に構築できます。 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を含むPythonパッケージですおよびmodels.pyファイル;最新のDjangoバージョンでは、models.py不要になりました。 __init__.py十分です。

DjangoアプリケーションにはPythonモジュールを含めることができます。 Django固有のモジュール（ビュー、URL、モデル、管理者、フォーム、テンプレートタグなど）、静的ファイル、テンプレート、データベース移行、管理コマンド、単体テストなど。モノリスアプリケーションを小さなものに分割する必要があります。再利用可能なアプリケーション単純なロジックを使用します。アプリの目的全体を1つか2つの短い文で説明できるはずです。例：「ユーザーがメールでアカウントを登録してアクティブ化できるようにします。」

aws認定ソリューションアーキテクト試験

プロジェクトフォルダを呼び出すことをお勧めしますprojectアプリケーションをproject/apps/に配置します。次に、すべてのアプリケーションの依存関係を独自のサブフォルダーに配置します。

例：

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

すべての静的フォルダーが1つのフォルダーにマージされ、2つ以上のアプリケーションにjs/core.jsがある場合は、サブフォルダーのアプリケーション名の前に必ずプレフィックスを付けます。ファイル、settings.INSTALLED_APPLICATIONSの最後のアプリケーション以前のものを上書きします。私はかつて現在のプロジェクトでこのバグを抱えていて、別の開発者がオーバーライドしたことに気付くまで約6時間のデバッグを失いましたstatic/admin/js/core.jsチームはカスタムSPA管理パネルを実装し、同じ方法でファイルに名前を付けていたためです。

これは、多くのリソースとPythonモジュールを持つポータルアプリケーションの構造例です。

 [email protected] :/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でオープンソースパッケージとして公開したり、別のフォルダーに移動したりすることもできます。

最終的に、次のようなプロジェクト構造になります。

 [email protected] :/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開発者を混乱させる

STATICFILES_DIRS？ STATIC_ROOT？

静的ファイルは、JavaScript、CSS、画像、フォントなど、アプリの使用によって変更されないアセットです。Djangoでは、デプロイプロセス中にパブリックディレクトリに「収集」されるだけです。

開発モードの場合— python manage.py runserver —Djangoはを使用して静的ファイルを検索します STATICFILES_FINDERS 設定。デフォルトでは、要求された静的ファイルを、 STATICFILES_DIRS 設定。失敗した場合、Djangoはdjango.contrib.staticfiles.finders.AppDirectoriesFinderを使用してファイルを見つけようとします。これはstaticを検索します。プロジェクトにインストールされているすべてのアプリケーションのフォルダー。これにより、独自の静的ファイルとともに出荷される再利用可能なアプリケーションを作成できます。

本番環境では、NginxなどのスタンドアロンWebサーバーを使用してスタティックを提供します。 Webサーバーは、Djangoプロジェクトのアプリケーション構造や静的ファイルが分散されているフォルダーについて何も知りません。幸い、Djangoには、python manage.py collectstaticをウォークスルーする静的管理の収集コマンドSTATICFILES_FINDERSが用意されています。アプリケーションからすべての静的ファイルをコピーしますstaticフォルダとSTATICFILES_DIRSにリストされているフォルダで指定したディレクトリに STATIC_ROOT 設定。これにより、Django開発モードサーバーと同じロジックを使用して静的ファイルリソースを解決でき、すべての静的ファイルがWebサーバーの1か所に配置されます。

実行することを忘れないでくださいcollectstatic実稼働環境で！

間違いその8：デフォルト`STATICFILES_STORAGE`、本番環境でのDjangoテンプレートローダー

`STATICFILES_STORAGE`

本番環境の資産管理について話しましょう。「アセットは期限切れにならない」ポリシーを使用すると、最高のユーザーエクスペリエンスを提供できます（詳細については、こちらをご覧ください）。ここに）。つまり、すべての静的ファイルは、Webブラウザーによって数週間、数か月、さらには数年もキャッシュされる必要があります。つまり、ユーザーはアセットを1回だけダウンロードする必要があります。

これはすばらしいことです。静的ファイルフォルダーのNginx構成で数行で実行できますが、キャッシュの無効化についてはどうでしょうか。ユーザーがアセットを1回だけダウンロードする場合、メニュー内のアイテムのロゴ、フォント、JavaScript、またはテキストの色を更新するとどうなりますか？これを回避するには、デプロイごとに静的ファイルの一意のURLとファイル名を生成する必要があります。

を使用するだけでそれを行うことができます ManifestStaticFilesStorage としてSTATICFILES_STORAGE （注意してください、ハッシュはDEBUG=falseモードでのみ有効になります）そしてcollectstaticを実行します上記の管理コマンド。これにより、本番Webサイトへのアセット要求数が減少し、Webサイトのレンダリングが大幅に高速化されます。

キャッシュされたDjangoテンプレートローダー

もう1つの優れたDjango機能は、キャッシュされたテンプレートローダーです。これは、すべてのテンプレートレンダリングでテンプレートファイルをリロードおよび解析するわけではありません。テンプレートの解析は非常にコストのかかる操作であり、多くのリソースを使用します。デフォルトでは、Djangoテンプレートはすべてのリクエストで解析されますが、これは特に、短時間で数千のリクエストを処理できる本番環境では問題になります。

チェックしてください cached.Loader 良い例とこれを行う方法の詳細については、構成セクションを参照してください。ローダーはファイルシステムから解析されたテンプレートを再読み込みしないため、開発モードでは使用しないでください。 python manage.py startappを使用してプロジェクトを再起動する必要がありますテンプレートを変更するたびに。これは開発中に煩わしい場合がありますが、実稼働環境には最適です。

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

Djangoはと呼ばれる非常に素晴らしい機能を提供します管理コマンド。車輪の再発明やプロジェクトユーティリティ用の生のPythonスクリプトを書く代わりに、それを使用するだけです。

また、チェックしてください Django拡張機能パッケージ。Djangoのカスタム拡張機能のコレクションです。たぶん誰かがすでにあなたのコマンドを実装しています！すでに多くの一般的なタスクコマンドがあります。

ScalaとJavaの違い

間違いその10：車輪の再発明

DjangoとPythonには、すぐに使用できる何千ものソリューションがあります。ユニークではないものを書く前にグーグルを試してみてください。おそらく、すでに存在する機能豊富なソリューションがあります。

物事をシンプルにするようにしてください。グーグルファースト！高品質のパッケージを見つけたら、インストール、構成、拡張、プロジェクトへの統合を行います。もちろん、機会があればオープンソースに貢献します。

まず、Django用の私自身のパブリックパッケージのリストを次に示します。

DjangoマクロのURL マクロを使用して、DjangoアプリケーションでURLパターンを簡単に記述（および読み取り）できます。
Djangoテンプレートの名前は小さなミックスインで、CBVテンプレート名を簡単に標準化できます。
django-split-settings Djangoの設定を複数のファイルとディレクトリに整理できます。設定を簡単に上書きおよび変更できます。設定ファイルのパスでワイルドカードを使用し、設定ファイルをオプションとしてマークします。

繰り返しないでください（DRY）！

私はDRY方法論が本当に好きです。だから私は作成しました Djangoスケルトン箱から出してすぐにいくつかの本当に素晴らしい機能を備えた便利なツールとして：

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

これは、次のプロジェクトで最初からすぐに使用できるDjango Skeletonであり、プロジェクトをブートストラップすることで多くの時間を節約できることを願っています。 Webpackの基本構成は最小限ですが、.scssを処理するように事前構成されたSASSもインストールされています。ファイル。