概要
このチートシートでは、コードを書くときによく出てくる設計原則を短く整理します。
原則は暗記するものではなく、迷ったときの判断材料として使います。
最初に覚える4つ
| 原則 | 一言でいうと | 注意点 |
|---|---|---|
| DRY | 同じ知識を重複させない | 似たコードを全部まとめる意味ではない |
| KISS | 必要以上に複雑にしない | 短いコードが常に良いわけではない |
| YAGNI | 今いらない機能を作らない | 雑に作るという意味ではない |
| AHA | 急いで抽象化しない | 重複を放置し続ける意味ではない |
DRY
| 見るポイント | 判断 |
|---|---|
| 同じ業務ルールが複数箇所にある | 共通化を検討 |
| 同じ変更で複数箇所を直す | DRY違反の可能性 |
| 見た目が似ているだけ | すぐ共通化しない |
KISS
| 複雑なサイン | 見直し方 |
|---|---|
| ネストが深い | ガード節を使う |
| 引数が多い | 関数やデータ構造を見直す |
| 汎用関数が読みにくい | 目的別に分ける |
| 抽象層が多い | 本当に必要か確認する |
YAGNI
| 作りたくなるもの | 判断 |
|---|---|
| 将来使いそうなオプション | 具体的な要件が出るまで待つ |
| 未使用の抽象クラス | 今使わないなら作らない |
| 予定だけの分岐 | 実装時に追加する |
| 使われていない設定 | 削除を検討する |
AHA
| 状況 | 判断 |
|---|---|
| 似たコードが2箇所 | まだ様子を見る |
| 3回同じ変更をした | 抽象化を検討 |
| 共通化すると引数が増える | 急がない |
| 名前が具体的に付く | 抽象化しやすい |
他にも覚えたい原則
| 原則 | 意味 |
|---|---|
| 単一責任 | 変更理由を1つにする |
| ガード節 | 対象外条件を先に返す |
| Fail Fast | 問題を早く検出する |
| Composition over Inheritance | 継承より部品の組み合わせを優先する |
| Tell, Don’t Ask | データを聞き出しすぎず責務の場所で判断する |
迷ったときの順番
- まず正しく動くか
- 名前で意図が伝わるか
- 変更理由が混ざっていないか
- 同じ知識が重複していないか
- 不要な先回りをしていないか
- 共通化で読みやすくなるか
この順番で見ると、原則を使いやすくなります。
まとめ
コード原則は、絶対ルールではなく判断の道具です。DRY、KISS、YAGNI、AHAをセットで見ると、重複を減らしつつ、早すぎる共通化も避けやすくなります。
参考リソース
← 一覧に戻るPR
PR
