設定管理のアンチパターン：ハードコーディングを見抜くレビュー ~ コードレビューのやり方徹底解説

はじめに

設定値のハードコーディングは、初期実装時には最も手軽な方法に見える。
しかし、後に環境の切り替えや外部接続先の変更、セキュリティ要件が追加された際、コードの再デプロイや事故の温床になる。

レビューアーは「値が直接書かれている」だけでなく、それが設定なのかロジックなのかを判別し、構成の分離がなされているかを確認しなければならない。

以下のようなコードに遭遇した際、それがアプリケーション構成の一部であるかどうかを判断する。

典型的なハードコーディング

def send_email(to):
    smtp_server = "smtp.example.com"
    port = 587
    ...

Comment

@Reviewer: SMTPサーバ設定は環境依存性が高く、ハードコーディングされた値は後の環境移行時に変更ミスを誘発します。環境変数や設定ファイルへの切り出しが望ましいです。

以下のような値はハードコーディングすべきではない構成要素とされる。

危険な構成値の例

DB_URL = "postgresql://user:pass@localhost:5432/mydb"

Comment

@Reviewer: DB接続情報がコード内に直書きされています。`.env`ファイルまたは設定ファイルからの読込に変更することで、環境ごとの分離が容易になります。

設定を管理するモジュール（例：settings.py）がプロジェクトに存在しない、もしくはimportされずに値が直書きされているコードは高リスクである。

誤：モジュール内で直値定義

def connect():
    timeout = 5  # ← 他モジュールからも繰り返し使用されている
    ...

Comment

@Reviewer: 同様の定数が複数箇所に散在しているようです。共通の設定モジュールに切り出し、変更可能性のある値の一元管理を推奨します。

正：settingsから読み込み

from settings import TIMEOUT

def connect():
    ...
    sock.settimeout(TIMEOUT)

設定値がロジック内部に埋め込まれていると、どの環境でどの値を使うべきかが曖昧になる。
このようなコードは保守・レビューの両面で負債を生む。

判別困難な構成

if env == "prod":
    retries = 5
else:
    retries = 2

Comment

@Reviewer: `env`に応じた設定の切替がコード中に混在しています。`.env`ファイル＋`os.environ`で一元管理する構成を検討してください。

テスト環境での設定値の上書きが不可能な構造は、本番前の確認作業に支障をきたす。
特にsettings.pyを直接importしてしまっている場合、テスト環境の切替が困難になる。

settingsのimportが固定されている例

from settings import RETRY_LIMIT

Comment

@Reviewer: `settings`モジュールをモックやDI（依存性注入）で差し替えられる構成にすると、テストと本番での柔軟な切り替えが可能になります。

APIキーやトークン、暗号キーなどがソースコードに埋め込まれている場合、それは単なるレビュー観点ではなくセキュリティ上の脆弱性である。

危険なハードコーディング

API_KEY = "sk_test_abc123"

Comment

@Reviewer: APIキーがコードにハードコーディングされています。Git漏洩や公開リスクを防ぐため、`.env`やSecrets Manager経由での管理が必要です。

Gitリポジトリにコミットされない構成（.env, config.yaml, 環境変数）での管理を明示すべきである。

以下は適切な設定構成例である。

settings.py

import os

SMTP_SERVER = os.getenv("SMTP_SERVER", "localhost")
PORT = int(os.getenv("SMTP_PORT", 25))

.envファイル（例）：

SMTP_SERVER=smtp.example.com
SMTP_PORT=587

アプリ本体：

from settings import SMTP_SERVER, PORT

def send_mail(...):
    smtp = smtplib.SMTP(SMTP_SERVER, PORT)

レビューアーの視点では、設定値が「別モジュール化＋環境変数対応」されているかを評価することが重要である。

SMTP設定

@Reviewer: SMTP接続先がコードに直接書かれています。環境に応じて切り替わる設計が望ましいため、環境変数または設定モジュールでの管理を推奨します。

APIキー

@Reviewer: セキュリティ上、APIキーやパスワードなどの秘匿情報は`.env`ファイルまたはSecrets Manager経由で外部管理してください。

タイムアウトやバッチサイズ

@Reviewer: 実行環境によりパフォーマンス要件が変動する設定値は、環境ごとに調整可能な構成が必要です。設定分離をご検討ください。

設定値のハードコーディングは、「とりあえず動かす」ためには最速だが、「将来も正しく動かす」ためには最大の障壁となる。

レビューアーとしては、コードに出現する「値」そのものを疑い、それが設定値として分離されるべきものかを見極める必要がある。
特に環境・セキュリティ・可搬性・テスト性の観点での構造的レビューが不可欠である。