Django 作成したアプリケーションが、アンチパターン に合致するか確認する

Python アンチパターンについて、検索したところ、以下の Little Book を見つけました。
この中に、Django の アンチパターンのページがあり、気になったので自分のアプリケーションのアンチパターンへの合致具合を確認してみました。
The Little Book of Python Anti-Patterns — Python Anti-Patterns documentation
結果を以下に記載します。

---

アンチパターンのカテゴリについて

以下、5つに分かれています。
一通り眺めてみて、個人的に対処が必要だと判断したものについて、実施したことを記載していきます。

• Maintainability

• Security

• Correctness

• Performance

• Migration to 1.8

---

詳細

Maintainability

• Importing django.db.models.fields
  from django.db.models import fields と import し、
  

      class Person(models.Model):
          first_name = fields.CharField(max_length=30)
          last_name = fields.CharField(max_length=30)
  

  field 配下の、Field で、Model の Field を定義するのではなく、from django.db import models と import して、
  

      class Person(models.Model):
          first_name = models.CharField(max_length=30)
          last_name = models.CharField(max_length=30)
  

  と記述できるため、この記載のほうが、無駄 import が少なくなるので、推奨されるべきだ。ということかと思います。

Security

サーバ公開時には、実施しておくべき項目が記載されています。

• ALLOWED_HOSTS setting missing
  Django では、DEBUG = False の場合、ALLOWED_HOSTS 設定を適切に設定する必要があり、この設定を Production 環境では有効にすべきという、ニュアンスの内容が記載されています。
  Blog の Host 設定は、DEBUG = False で、ALLOWED_HOSTS も設定しているため、特に設定変更は実施しませんでした。

• SECRET_KEY published
  settings.py に、SECRET_KEY を記載すると、SCM の パスワードが割れたりした場合、アプリケーションが乗っ取られるので、 SCM とは別に、外だしして管理すべきとのことが記載されています。
  自アプリケーションの settings.py は、外だししていなかったので、テキストファイルに記載し、その内容を読み出すようにしました。
  

  with open('/etc/secret_key.txt') as f:
      SECRET_KEY = f.read().strip()
  

• Same value for MEDIA_ROOT and STATIC_ROOT
  英文の意味があまり理解できておりませんが、
  MEDIA_ROOT と STATIC_ROOT は異なる値にする必要があります。
  同一パスだと、MEDIA_ROOT が、STATIC_ROOT の FallBack 先として使用されるため、セキュリティの問題を引き起こす可能性がある的なニュアンスのことが記載されています。

あまり意識したことがありませんでしたが、Blog は、Mezzanine を使用しており、デフォルトでパスが分かれていることが確認できたので、特に対処しませんでした。

• Same value for MEDIA_URL and STATIC_URL
  セキュリティリスクがあるため、MEDIA_URL と、STATIC_URL は同じ URL にしないほうよい。という内容です。
  Same value for MEDIA_ROOT and STATIC_ROOT にも関係しますが、
  設定 | Django documentation | Django
  に該当する記載がありました。
  上記ドキュメントからは、以下がリンクされています。
  Django におけるセキュリティ | Django documentation | Django
  セキュリティ関連記述でどちらも一読しておいたほうがよいと感じました。

Correctness

• Not using forward slashes
  Django は Windows 環境でもパス文字列として、/を認識するので、\ を使用しなくてもいいです。
  これは、Linux 環境で稼働させているということもあり、該当しませんでした。

• Not using NullBooleanField
  True と False のみが取り得る値のフィールドの場合は、BooleanField を使用すべきで、NullBooleanField は、Null を値としてとる場合のみ使用したほうがよいという内容になります。
  これは、該当しませんでした。

Performance

• Inefficient database queries
  Django の Model は SQL を隠蔽化するため、何も考えずに、Cars.objects.all() 等を記載していると、パフォーマンスが出ないので、
  values() や、values_list() を使い、取得項目を制御したほうがパフォーマンスが出ます。
  該当記述は特にはなかったですが、今後意識したいポイントではあります。

Migration to 1.8

下位の Version から、Django 1.8 に Version Up する際の注意点が記載されています。
これは、アンチパターンから外れる気がしましたので、割愛します。
過去に Version Up した際似たような事象に遭遇していたので、その記事のリンクを貼り付けておきます。

• Django 1.8からsettings.pyのTEMPLATESが非推奨になって警告が出力される。 | Monotalk

• Django 1.8以上で、settings.py に TEMPLATE_DEBUG に相当するOptionを指定する | Monotalk

項目としては、以下の4つが記載されています。

• TEMPLATE_DIRS deprecated
• TEMPLATE_DEBUG deprecated
• TEMPLATE_LOADERS deprecated
• TEMPLATE_STRING_IF_INVALID deprecated

---

まとめ

Django アンチパターンに作成したアプリケーションが合致するか確認してみました。
アンチパターンからの気づきは多く勉強になります。
静的解析ツール好きとしては、アンチパターンって静的解析ツールのチェック項目にしやすそうに思うので、何かで実装されてたりしないかと期待してしまいます。
Python 側はまだ眺めていないですが、勉強になりそうなので、後日そちらも見てみようと思います。
以上です。