クリーンコードって、結局なんなの？

この業界は「読みやすいコードを書け」を宗教にしてしまった。そして多くの宗教と同じように、信者たちは本来のメッセージを忘れてしまった。

たった1つの割引フィールドに40ファイル

チームメイトがチケットを取った。チェックアウトに割引フィールドを追加するだけ。1日の作業、テスト込みで2日。

3日後、彼は40ファイルに触るPRを持ってきた。決済モジュールをストラテジーパターンにリファクタリングしていた。インターフェースを作成。「将来もっとプロバイダーが必要になったら？」という理由でファクトリーも追加。

チケットに必要だったもの：

• checkout.tsx — 入力フィールド追加
• api/checkout.ts — discountパラメータ追加
• DBマイグレーション — カラム追加

実際に納品されたもの：

• DiscountStrategy インターフェース
• PercentageDiscountStrategy
• FixedAmountDiscountStrategy
• DiscountStrategyFactory
• DiscountValidatorService
• ...他35ファイル

見積もり： 1-2日。実際： 5日。

プロバイダーは2つだった。3年間ずっと2つだった。

彼は本気で正しいことをしていると思っていた。 一方、PMはなぜ単純なフィールドにスプリントの半分がかかったのか聞いていた。

ガイドラインが戒律になった

Uncle Bobの本には良いアドバイスがある。関数は小さくあるべき。名前は意味のあるものに。それはいい。

でも私たちはガイドラインを戒律に変えてしまった。「これは役に立つか？」と問うのをやめ、「これはルールに従っているか？」と問い始めた。

実際にこうなる

UserNameValidator、UserEmailValidator、UserAgeValidator、そしてCompositeUserValidatorを作成するUserValidatorFactory。3つのフィールドをバリデーションするために。

3つのフィールドをチェックするから「3つのこと」をしている、だから単一責任原則に違反していると言う人がいるだろう。

ユーザー入力のチェックは1つのことだ。 そうでないと主張するための精神的曲芸こそが問題の本質だ。

すべての抽象化にはコストがある

関数を抽出 — 再利用性を得て、局所性を失う。

インターフェースを作成 — 柔軟性を得て、直接性を失う。

パターンを適用 — 「既知の解決策」を得て、シンプルさを失う。

抽象化を追加 — 将来への備えを得て、現在の明快さを失う。

これらはどれも無料ではない。クリーンコード信者はそうでないふりをする。

唯一重要な質問

何かをリファクタリングする前に：

「このコードは今、問題を起こしているか？」

理論的にではなく。仮想の未来でもなく。今。

リファクタリングすべき時：

• 同じロジックを3回以上コピーした
• 変更が無関係なコードを壊す
• 5分見ても理解できない
• 複雑さによるバグが発生した

リファクタリングすべきでない時：

• 「後で必要になるかも」
• 「クリーンに見えない」
• 「SRPに違反している」
• 「パターンに従っていない」

今問題がないなら — 放っておいて何かを作れ。

私が実際に従っていること

1. 明確に命名する。 calculateTotalPrice > calc。常に価値がある。
2. 賢くなろうとしない。 トリックを説明するコメントが必要なら、退屈なバージョンを書け。
3. 痛みがあればリファクタリング。 同じロジックを3回コピーした？抽出しろ。1回？放っておけ。
4. 機能をリリースしろ。 誰も美しいコードに金を払わない。問題を解決することに払う。

---

ジュニアの頃はクリーンコード＝良いエンジニアだと思っていた。ミドルの頃はデザインパターン＝良いエンジニアだと思っていた。今はメンテナンスできる動くソフトウェアを届けること＝良いエンジニアだと思っている。

プルリクエストで演技するのをやめろ。リリースしろ。

---

リリースされた「まあまあ」のコードは、リリースされない「完璧な」コードに毎回勝つ。

— blanho