この記事のポイント

  • グローバル変数のスコープ責任をレビュー視点で整理できる
  • 依存構造の崩壊要因と防止策を理解できる
  • 初期化タイミング管理の考え方を学べる
  • PlantUMLで依存構造の肥大化・整理イメージを可視化できる

そもそもグローバル変数とは

Pythonにおける「グローバル変数」とは「モジュールスコープで定義された共有変数」を指します。

典型的なグローバル変数 
# config.py
DATABASE_URL = "postgres://localhost:5432/db"
  • モジュールインポート時に読み込まれる
  • 他モジュールからimportで参照可能
  • モジュール単位のシングルトン相当として利用されがち

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

グローバル変数は便利で強力ですが、設計崩壊の起点になりやすい強い設計臭を放ちます。レビューアーは以下を読み取る必要があります。

レビューアー視点

  • どこで誰が初期化責任を持っているのか
  • 依存スコープが適切に限定管理されているか
  • 再代入（可変性）が暴走可能性を孕んでいないか
  • テスト時に状態が汚染・干渉しないか
  • 複数モジュール間での参照が逆流していないか

開発者視点

  • 早期実装ではとにかく外部に置けば便利に見える
  • importだけで共有できる手軽さに依存しがち
  • 初期化順序の危険性を軽視しがち
  • テスト実行時の状態不安定化に気づきにくい

グローバル変数の危険な設計臭

典型的な設計崩壊症状
  • 初期化時点の不確定性
  • 変更責任の所在不明化
  • 依存逆流（呼び出し元が参照元を操作）
  • テスト汚染（状態共有による副作用連鎖）
  • フラグ変数化（動的可変構成情報）

崩壊例を順に見ていきます。

良くない実装例: ケース1（初期化責任曖昧）

config.py 

DATABASE_URL = None

def init_config():
    global DATABASE_URL
    DATABASE_URL = "postgres://localhost:5432/db"

@Reviewer
初期化責任が曖昧です。呼び出し漏れで状態不定リスクがあります。構成情報は不変型で確定初期化を推奨します。

問題点

  • 初期化忘れで実行時エラー
  • 初期値依存処理が暗黙化

良くない実装例: ケース2（可変状態汚染）

feature_flag.py 

FEATURE_ENABLED = False

def enable_feature():
    global FEATURE_ENABLED
    FEATURE_ENABLED = True

def disable_feature():
    global FEATURE_ENABLED
    FEATURE_ENABLED = False

@Reviewer
状態変更責務が分散し副作用が暴走しやすい構造です。設計責任を移譲してください。

問題点

  • 呼び出し順依存発生
  • テスト環境間干渉

グローバル設計崩壊の依存構造モデル

UML Diagram
  • 全レイヤからアクセス集中
  • 状態汚染と循環依存が誘発される

グローバル依存整理の設計アプローチ

グローバル変数を適切に制御するには以下の整理技法が有効です。

① 不変化設計（Immutable化）

  • 初期化時点で確定固定
  • 再代入経路を設けない

② Config Objectパターン導入

  • コンストラクタ引数渡しで依存注入
  • 可視スコープを限定管理

③ シングルトン管理型導入

  • ラッパー管理下で状態可変性制御
  • 直接代入経路を排除

④ DIコンテナ設計併用

  • フレームワーク依存分離
  • コンテキストスコープ統制

改善例：不変化設計

immutable_config.py 

class Config:
    def __init__(self, database_url: str):
        self.database_url = database_url

CONFIG = Config(database_url="postgres://localhost:5432/db")
  • 再代入不可
  • 変更責務分離

改善例：依存注入整理

app_entry.py 

from immutable_config import CONFIG
from db_client import DBClient

db = DBClient(CONFIG.database_url)
app = Application(db_client=db)
  • 明示注入経由でスコープ明確化
  • テスト用モック容易化
グローバル依存は「注入に逃がす文化」

レビューアーは「import依存せず渡しているか？」を常に確認すると健全性が保たれます。

改善構造モデル：責務分離整理

UML Diagram

観点チェックリスト

まとめ

グローバル変数は「静かに侵食する設計臭」を孕みます。
レビューアーは「グローバルではなくスコープ可視化文化」を継続指導することで、設計健全性の防波堤を築くことができます。