この記事のポイント

  • settings設計の崩壊パターンをレビュー視点で読み取れる
  • 環境別・責務別に分割管理する設計技法を学べる
  • 実務での設定整理文化を体系化できる
  • PlantUMLで整理モデルの構造を可視化できる

そもそも設定ファイルとは

Pythonにおける設定ファイル（settings）は、アプリケーション起動時に読み込まれる環境定数・構成情報・外部接続先などをまとめた仕組みです。

典型的なsettings.py 

DATABASE_URL = "postgres://localhost:5432/db"
API_KEY = "abcd1234"
TIMEZONE = "Asia/Tokyo"
DEBUG = True
  • 実行時挙動を決定する構成情報
  • プログラムコード本体と分離されるべき領域
  • 環境差分の管理・保守性の起点になる

なぜこれをレビューするのか

設定設計は「実行環境の安全弁」であり、レビューアーは以下を読み解く必要があります。

レビューアー視点

  • 環境依存差分が整理統制されているか
  • 設定肥大化が進行していないか
  • 依存モジュールがsettings直読みに依存しすぎていないか
  • 環境注入パターンが統一されているか
  • 機密情報管理が設計として分離されているか

開発者視点

  • ひとまず1ファイルに全て書く誘惑
  • フィールド追加が容易すぎる油断
  • 複数環境管理が後追いになる
  • モジュール直読みに依存しやすい

設定管理崩壊の典型設計臭

崩壊しやすいパターン
  • settings.pyが巨大ファイル化（数百行超過）
  • 環境ごとの差分が条件分岐だらけ
  • 誰が何を利用しているか可視性消失
  • 機密情報が直書きされる
  • テスト環境切り替えが面倒
  • 環境変数依存とsettings.py混在

崩壊例：典型的肥大化

肥大化settings.py 

DATABASE_URL = "postgres://localhost:5432/db"
API_KEY = "abcd1234"
DEBUG = True
TIMEZONE = "Asia/Tokyo"
EMAIL_SERVER = "smtp.example.com"
EMAIL_USER = "[email protected]"
EMAIL_PASSWORD = "pass1234"
PAYMENT_API_URL = "https://payment.example.com"
PAYMENT_API_KEY = "secret123"
LOG_LEVEL = "INFO"
RETRY_COUNT = 5

@Reviewer
設定責務が全て1ファイル集中し肥大化が進行しています。分割整理を検討してください。

崩壊構造モデル：全集中型設計臭

UML Diagram

良い設計整理アプローチ

肥大化を防ぐには以下の段階整理が有効です。

① 分割モジュール設計

② 環境別レイヤ抽出

③ 初期化統合レイヤ設計

  • ローダー層（loader.py）で統合
  • 環境変数や外部注入管理

④ 機密情報分離

  • secrets.py / vault連携など機密経路分離

⑤ 利用層は依存注入型へ整理

  • 直接settings参照せず、呼出時引数渡しへ整理

改善例：分割整理構造

ディレクトリ構成 

settings/
  __init__.py
  common.py
  database.py
  mail.py
  payment.py
  production.py
  development.py
  test.py
  loader.py

共通部分

settings/common.py 

TIMEZONE = "Asia/Tokyo"
LOG_LEVEL = "INFO"
RETRY_COUNT = 5

機能別

settings/database.py 

DATABASE_URL = "postgres://localhost:5432/db"
settings/mail.py 

EMAIL_SERVER = "smtp.example.com"
EMAIL_USER = "[email protected]"
EMAIL_PASSWORD = "pass1234"
settings/payment.py 

PAYMENT_API_URL = "https://payment.example.com"
PAYMENT_API_KEY = "secret123"

統合レイヤ

settings/loader.py 

import os
from settings import common, database, mail, payment

class Settings:
    def __init__(self):
        self.database_url = database.DATABASE_URL
        self.mail_server = mail.EMAIL_SERVER
        self.payment_api_url = payment.PAYMENT_API_URL

SETTINGS = Settings()

改善構造モデル：分離統合後

UML Diagram
「読む責務」「変更する責務」を分ける文化

レビューアーは集中読み出し構造が整理できているかを常に確認すると健全性を保ちやすくなります。

良くない実装例: ケース1（環境条件分岐）

settings.py 

if os.getenv("ENV") == "production":
    DATABASE_URL = "postgres://prod-server/db"
else:
    DATABASE_URL = "postgres://localhost:5432/dev"

@Reviewer
環境条件分岐をコード内部で処理しています。環境別設定ファイル分離を検討してください。

問題点

  • 条件分岐肥大化の温床
  • 変更影響範囲が拡大

良くない実装例: ケース2（直接参照依存）

db_client.py 

from settings import DATABASE_URL

class DBClient:
    def __init__(self):
        self.url = DATABASE_URL

@Reviewer
設定値を直接参照しています。依存注入型に整理してください。

問題点

  • import依存が強結合化
  • テスト用差替え困難

改善例：注入整理版

db_client.py 

class DBClient:
    def __init__(self, database_url: str):
        self.url = database_url
app_entry.py 

from settings.loader import SETTINGS
from db_client import DBClient

db = DBClient(SETTINGS.database_url)

観点チェックリスト

まとめ

設定管理は「崩壊進行が最も見えづらい設計臭」を持っています。
レビューアーは「分離文化・注入文化・初期化統制文化」を継続指導することで、長期保守性の高い構成を維持できます。