1. 次のコードは、API呼び出しのオプションを毎回ベタ書きしています。DRYの観点から、最も効果的な改善はどれでしょうか?
function fetchUsers() {
return fetch('/api/users', {
method: 'GET',
headers: { 'Content-Type': 'application/json' },
credentials: 'include'
});
}
function fetchOrders() {
return fetch('/api/orders', {
method: 'GET',
headers: { 'Content-Type': 'application/json' },
credentials: 'include'
});
}
-
-
-
-
解説: fetch のオプション(method / headers / credentials)が関数ごとに重複しています。DRYに反する典型例です。
共通オプションを1か所にまとめておき、URL や一部オプションだけ変えるようにすると、変更時の修正漏れも防げます。
2. 次の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);
}
-
-
-
-
解説: メール送信のための `mailer.send(user.email, subject, body);` というパターンが2つの関数に重複しています。
共通関数にまとめておくと、送信方法の変更(BCC追加など)も1か所で済み、DRYに沿った設計になります。
3. 次のコードでは、配列のフィルタリングとマッピングが重複しています。DRYとKISSの両方を意識した改善として、最もよいものはどれでしょうか?
const activeUserNames = users
.filter(user => user.active)
.map(user => user.name);
const activeUserEmails = users
.filter(user => user.active)
.map(user => user.email);
-
-
-
-
解説: `filter(user => user.active)` が2か所に重複しており、DRYに反しています。
一度 `const activeUsers = users.filter(...);` としてから、name / email をそれぞれ map することで、処理もシンプルになり、無駄なフィルタリングも減らせます。
4. 次の関数は、かなり多くの責務を抱えて太りすぎています。DRY/KISS の観点から、最も問題がある点はどれでしょうか?
function handleCheckout(cart, user) {
// 合計計算
// クーポン適用
// 在庫チェック
// 配送先住所チェック
// 支払情報チェック
// 決済API呼び出し
// 注文レコード作成
// メール送信
// 画面遷移
}
-
-
-
-
解説: handleCheckout が「チェックアウトに関するすべて」を担当しており、非常に肥大化しやすい構造です。DRY/KISS の観点からは、責務を分割して小さな関数やクラスに切り出すことで、読みやすさやテストのしやすさを高めることが重要です。
5. 次の関数は、複数のモードに応じて処理を切り替えています。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');
}
}
-
-
-
-
解説: handleAction が「何でも屋」になっており、モードが増えるたびに if-else が増えていきます。KISSの観点からは、モードごとに小さな関数やオブジェクトに分けるなどして、分岐の増殖を抑えた方が読みやすく保守しやすいです。
6. 次のコードは、「分かりやすさ」よりも「1行で書くこと」を優先してしまっています。KISSの観点から、どの書き方がより望ましいでしょうか?
const isAdult = (age) => age != null && age >= 18 ? true : false;
-
-
-
-
解説: 「条件式 ? true : false」は、そのまま条件式だけで十分意味が伝わる場合には不要な複雑化です。KISSの観点からは、`const isAdult = (age) => age >= 18;` のようにシンプルに書く方が読みやすくなります。
null チェックが必要な場合でも、別途分かりやすく書いたほうがよいでしょう。
7. 次のコードは、ユーザー名ラベルを作る処理です。DRYの観点から、最も問題がある部分はどこでしょうか?
function createUserLabel(user) {
return user.lastName + ' ' + user.firstName + '(' + user.id + ')';
}
function createOrderLabel(order) {
const user = order.user;
return user.lastName + ' ' + user.firstName + '(' + user.id + ')';
}
-
-
-
-
解説: ユーザー名ラベルの生成ロジックが、2つの関数にほぼ同じ形で重複しています。これはDRY(Don't Repeat Yourself)に反しており、仕様変更があったときに片方だけ修正漏れするリスクがあります。
「ユーザーラベルを作る関数」を1か所に切り出し、共通利用するのがDRYな設計です。
8. 次のコードでは、同じ「合計金額のフォーマット処理」が重複しています。DRYの観点から、最も適切な改善はどれでしょうか?
function showCartTotal(cart) {
const total = cart.items.reduce((sum, item) => sum + item.price * item.quantity, 0);
const label = total.toLocaleString() + '円(税込)';
document.getElementById('cart-total').textContent = label;
}
function showOrderTotal(order) {
const total = order.items.reduce((sum, item) => sum + item.price * item.quantity, 0);
const label = total.toLocaleString() + '円(税込)';
document.getElementById('order-total').textContent = label;
}
-
-
-
-
解説: 合計金額の計算とフォーマット処理が2か所に同じように書かれており、DRYに反しています。
合計計算とフォーマットを共通関数にまとめることで、仕様変更時も1か所を直すだけで済みます。
9. 次の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();
});
}
-
-
-
-
解説: 「!res.ok のときにエラーを投げる」ロジックが重複しており、DRYに反します。共通のエラーハンドリング関数にまとめて、リソース名だけ引数で変えるようにすれば、エラーメッセージの変更やログ追加も1か所で管理できます。
10. 次の関数は、ネストが3段階の三項演算子になっています。KISSの観点から、どのような改善が望ましいでしょうか?
function getStatusLabel(status) {
return status === 'active'
? '有効'
: status === 'pending'
? '承認待ち'
: status === 'suspended'
? '停止中'
: '不明';
}
-
-
-
-
解説: 三項演算子をネストしすぎると、KISSに反して読みづらくなります。この程度の分岐であれば、if-else 文で素直に書くか、`const labels = { active: '有効', ... };` のようにマップを使って表現する方がシンプルです。