Sandi Metz、設計原則「間違った抽象化より重複を選べ」を公開──共通化による複雑性増大の回避手法
共通化を急ぐあまり条件分岐が増大した「間違った抽象化」を解消し、コードを一度インライン化させてから真の共通点を見出す手法を解説する。
リリース: 2016-01-20 · 読了 3 分何が起きた
Ruby界の著名な開発者 Sandi Metz 氏が、RailsConf 2014 の講演内容を基に 2016年1月にブログで公開した設計指針。
「重複は間違った抽象化よりも遥かに安上がりである」という原則を掲げ、不適切な共通化が技術負債を生むプロセスを 10 段階で説明。
新しい要件に対して既存の抽象化が「ほぼ完璧」に見える際、引数や条件分岐を追加して無理に適合させることがコードを難解にする主因と指摘。
解決策として、理解不能になった抽象化を一度削除して元の重複コードに戻し、パターンが明確になるまで待つ「インライン化」を推奨。
なぜ重要
DRY 原則を盲信して if 分岐だらけの関数を作るより、コードを重複させたままの方が将来の変更コストを低く抑えられるという逆説的な視点を得られる。
LLM が生成したコードを統合する際、無理に共通化して複雑性を上げるべきか、独立させておくべきかの明確な判断基準になる。
👁️ 開発者
テックリードは、レビュー時に「共通化による複雑性の導入」と「重複による見通しの良さ」を天秤にかけ、将来の仕様変更に伴うリファクタリング工数を削減する設計判断を下せる。
🇯🇵 日本
国内の受託開発や中規模 SaaS 開発チーム（特に Ruby on Rails や TypeScript を採用する組織）において、要件定義が曖昧な段階での過度な共通化を抑制し、数ヶ月後の機能追加時に発生するコードの不整合を回避できる。