AIコードをDRY/KISSで徹底リファクタ！
コードレビュー道場 #1：DRY/KISS

公開日：2025年12月13日

最終更新日：2026年02月22日

このページでは、AIが生成しがちな冗長・重複・やりすぎなコードを題材に、DRY / KISSを武器にしたコードレビュー形式の4択クイズで実戦力を鍛えます。理屈を読むだけでなく、「どこがまずい？どう直す？」を自分の判断として身につけるのが狙いです。

4択クイズ（10問・全問解説付き）で腕試し → 解説でなぜその修正が効くのかを腹落ち。「読む→解く→わかる」で、AIコードをスリムに整えるリファクタの勘所を鍛えていきましょう！

今すぐクイズに挑戦
（10問・約3分・解説つき）

プリンシプルオブプログラミング
AI時代を生き抜く「101の設計原則」

#1 DRY/KISS：AIコードをリファクタせよ！目次

クイズに挑戦する(10問)

参考文献・出典
このページの著者
シェア

コードレビュー道場 #1～DRY/KISSで太りすぎた関数を救え！～

1. 次の2つの関数は、とても似たバリデーション処理を行っています。DRYの観点から、最も適切な改善はどれでしょうか？

function isValidUserName(name) {
  return typeof name === 'string' && name.length >= 3 && name.length <= 20;
}

function isValidProjectName(name) {
  return typeof name === 'string' && name.length >= 3 && name.length <= 20;
}

A. ユーザー名とプロジェクト名は別物なので、このまま重複していてよい
B. typeof チェックを削除する
C. 長さチェックを別の共通関数に切り出し、再利用する
D. 3 と 20 の値を変える

2. 次のコードでは、10という値が複数の場所で使われています。DRYの観点から、最も良い改善はどれでしょうか？

function isNewUser(user) {
  return user.daysSinceRegistered < 10;
}

function isRecentOrder(order) {
  return order.daysSincePlaced < 10;
}

A. 10 を 7 に変更する
B. 10 を定数として切り出し、意味のある名前を付けて共有する
C. "< 10" を "<= 10" にする
D. daysSinceRegistered と daysSincePlaced を削除する

3. 次の関数は、複数のモードに応じて処理を切り替えています。KISSの観点から、最も問題になりやすい点はどれでしょうか？

function handleAction(mode, data) {
  if (mode === 'create') {
    // 作成処理
    // ...
  } else if (mode === 'update') {
    // 更新処理
    // ...
  } else if (mode === 'delete') {
    // 削除処理
    // ...
  } else if (mode === 'copy') {
    // コピー処理
    // ...
  } else if (mode === 'archive') {
    // アーカイブ処理
    // ...
  } else {
    throw new Error('Unknown mode');
  }
}

A. mode を文字列で管理していること
B. 例外を投げていること
C. 1つの関数で多くのモードを扱い、if-else が増え続ける設計になっていること
D. data を引数に取っていること

4. 次の2つの関数は、ほとんど同じメール送信処理を行っています。DRYの観点から、最も良い改善はどれでしょうか？

function sendWelcomeMail(user) {
  const subject = 'ようこそ！';
  const body = `こんにちは ${user.name} さん`;
  mailer.send(user.email, subject, body);
}

function sendByeMail(user) {
  const subject = 'ご利用ありがとうございました';
  const body = `さようなら ${user.name} さん`;
  mailer.send(user.email, subject, body);
}

A. mailer.send の第3引数を削除する
B. user.name を subject にも入れる
C. 共通の sendMail(user, subject, body) のような関数を定義し、差分だけを渡すようにする
D. メール送信処理を2つの関数に分けたままにする

5. 次の2つの関数は、データ取得後のエラーハンドリングがコピペになっています。DRYの観点から、どう改善するのがよいでしょうか？

function loadUsers() {
  return fetch('/api/users')
    .then(res => {
      if (!res.ok) {
        throw new Error('ユーザーの取得に失敗しました');
      }
      return res.json();
    });
}

function loadProjects() {
  return fetch('/api/projects')
    .then(res => {
      if (!res.ok) {
        throw new Error('プロジェクトの取得に失敗しました');
      }
      return res.json();
    });
}

A. エラーメッセージを英語にする
B. エラーメッセージ部分を共通の handleError 関数に切り出し、APIごとの差分（どのリソースか）だけ渡す
C. res.ok のチェックを削除する
D. fetch を XMLHttpRequest に変える

6. 次の if 文は、KISSの観点から少し読みにくい書き方になっています。最も改善したいポイントはどれでしょうか？

function canShip(order) {
  if (order && order.paid && !order.canceled && !order.refunded && order.items && order.items.length > 0) {
    return true;
  }
  return false;
}

A. order を引数に渡していること
B. 1つの if 条件に多くのチェックを詰め込みすぎていること
C. !order.canceled と !order.refunded を使っていること
D. return true / false を使っていること

7. 次の2つの関数は、ほとんど同じログ出力を行っています。DRYとKISSの観点から、より良い設計はどれでしょうか？

function logUserLogin(user) {
  console.log('[LOGIN]', new Date().toISOString(), user.id, user.name);
}

function logUserLogout(user) {
  console.log('[LOGOUT]', new Date().toISOString(), user.id, user.name);
}

A. ログ出力をすべて削除する
B. 日付の出力を削除する
C. 共通の logUser(eventType, user) 関数を作り、[LOGIN]/[LOGOUT] だけを引数で変える
D. console.log の代わりに alert を使う

8. 次の関数は、かなり多くの責務を抱えて太りすぎています。DRY/KISS の観点から、最も問題がある点はどれでしょうか？

function handleCheckout(cart, user) {
  // 合計計算
  // クーポン適用
  // 在庫チェック
  // 配送先住所チェック
  // 支払情報チェック
  // 決済API呼び出し
  // 注文レコード作成
  // メール送信
  // 画面遷移
}

A. コメントが多すぎること
B. 引数が2つあること
C. チェックアウトに関するすべての処理を1つの巨大な関数に詰め込んでいること
D. 関数名に handle が含まれていること

9. 次のコードは、「とりあえずなんでも詰め込んだユーティリティ関数」です。KISSの観点から、どのような改善方針がよいでしょうか？

function doMagic(obj, options) {
  // ログ出力
  console.log('start', obj, options);

  // バリデーション
  // ...

  // データ変換
  // ...

  // API呼び出し
  // ...

  // 画面更新
  // ...
}

A. さらに多くの処理を足して、アプリ全体をここから呼ぶ
B. doMagic の中身を、責務ごとに小さな関数に分割し、意味のある名前を付ける
C. すべての処理をコメントアウトしておく
D. 関数名だけ doEverything に変える

10. 次のコードは、「分かりやすさ」よりも「1行で書くこと」を優先してしまっています。KISSの観点から、どの書き方がより望ましいでしょうか？

const isAdult = (age) => age != null && age >= 18 ? true : false;

A. const isAdult = (age) => age >= 18;
B. const isAdult = (age) => { return age != null && age >= 18 ? true : false; };
C. const isAdult = (age) => !!age;
D. const isAdult = (age) => age != null && age > 0;