🛣️ “やり方が複数”の増殖（One obvious way to do it）

🧭 はじめに

このページでは、「同じことをするコードが、複数の流儀で書かれている」状態が、チーム開発において最も高コストになるという事実を整理する。 Python の Zen が言う There should be one— and preferably only one —obvious way to do it は、言語仕様の話ではない。設計と運用の話である。

---

🎯 ねらい

• 「自由に書けること」と「統一されていること」の違いを明確にする
• “個人最適” が “チーム最悪” になる構造を可視化する

---

❓ 問題の定義

• 同一目的の処理が、複数の書き方で散在している
• 振る舞いは似ているが、微妙に違い、修正時に事故る

Python は書き方を統一してくれない。統一は人間の仕事。

---

🧪 よくある症状

• エラー処理が

  • A：例外
  • B：None
  • C：Result オブジェクト

• 文字列整形が

  • format()
  • f-string
  • + 演算子

• データ変換が人ごとに違う書き癖

---

❌ 悪い例

日付フォーマットの流派乱立

• モジュールA：YYYY/MM/DD
• モジュールB：YYYY-MM-DD
• モジュールC：ロケール依存

仕様変更時、「全部直したつもり」が必ず漏れる。

---

✅ 良い例

「1つの流儀」をコードとして提供

• format_date(date) のように 関数化
• 呼び出し側は「考えなくてよい」

ルールは文章よりコード

• README やWikiではなく
• ユーティリティ関数・共通APIとして置く

守られる規約とは、守らなくても書けない規約。

---

🧠 設計の要点

• “One obvious way” は 自然発生しない
• 言語が保証しない以上、チームが設計する
• 選択肢を減らすことは、自由を奪うことではない → 判断コストを下げること

PEP8 より重要なのは、プロジェクト固有の「局所ルール」。

---

🧰 チェックリスト

• 同じ意味の処理が複数箇所に存在しないか
• 戻り値・エラーの流儀は統一されているか
• 「推奨パターン」が関数やモジュールとして存在するか
• 新人が迷わず選べる “道” が用意されているか

---

🏁 まとめ

• 書き方が複数ある状態は、拡張性ではなく負債
• 選択肢は設計で減らす
• “明白な1つのやり方” は、チーム文化とコードで作る

Python は自由だが、 プロジェクトは自由である必要はない。