1 . 次の関数は、バリデーション・保存・画面遷移までを1つに詰め込んだ例です。KISSの観点から、最も優先して行うべき改善はどれでしょうか?
function submitForm(data) {
// 入力チェック
if (!data.name) {
alert('名前は必須です');
return;
}
if (!data.email) {
alert('メールアドレスは必須です');
return;
}
// 保存用データ整形
const payload = {
name: data.name,
email: data.email,
createdAt: new Date().toISOString()
};
// 保存API
fetch('/api/contacts', {
method: 'POST',
body: JSON.stringify(payload)
}).then(() => {
alert('送信しました');
location.href = '/thanks';
}).catch(() => {
alert('送信に失敗しました');
});
}
A.
createdAt を削除する
B.
fetch を同期処理にする
C.
バリデーション・保存ロジック・画面遷移を役割ごとに分割し、小さな関数にする
D.
location.href の代わりに console.log を使う
解説: この関数は「入力チェック」「保存用の整形」「API呼び出し」「UI制御(アラート・画面遷移)」まで全部入りで、肥大化した関数になっています。
KISSの観点からは、責務ごとに小さな関数に分割して、読みやすく・テストしやすい形にすることが重要です。
2 . 次の 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 を使っていること
解説: 1つの if に多くの条件を詰め込むと、何をチェックしているか一目で分かりにくくなります。KISS(シンプルに保つ)の観点からは、チェックを小さな関数に分けたり、名前付きの変数に代入して意味を明確にする方が読みやすくなります。
3 . 次のコードは、「とりあえずなんでも詰め込んだユーティリティ関数」です。KISSの観点から、どのような改善方針がよいでしょうか?
function doMagic(obj, options) {
// ログ出力
console.log('start', obj, options);
// バリデーション
// ...
// データ変換
// ...
// API呼び出し
// ...
// 画面更新
// ...
}
A.
さらに多くの処理を足して、アプリ全体をここから呼ぶ
B.
doMagic の中身を、責務ごとに小さな関数に分割し、意味のある名前を付ける
C.
すべての処理をコメントアウトしておく
D.
関数名だけ doEverything に変える
解説: 「何でも詰め込む」関数は、KISSにも単一責任の原則にも反します。処理を分割し、それぞれが1つの役割に集中するように関数化することで、全体がシンプルに理解しやすくなります。
4 . 次の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か所に重複しており、DRYに反しています。長さチェックだけを共通関数に切り出しておけば、仕様変更時に1か所を修正するだけで済みます。
「意味としては別のバリデーション」であっても、「全く同じコード」がコピペされている場合はDRYを疑うサインです。
5 . 次のコードでは、バリデーションメッセージがコピペされています。DRYの観点から、どこを改善するとよいでしょうか?
function validateName(name) {
if (!name) {
return '名前は必須です';
}
if (name.length > 20) {
return '名前は必須です';
}
return '';
}
A.
20 の制限をなくす
B.
エラーメッセージをそれぞれ別の文言にする
C.
同じメッセージを返している部分をまとめ、条件だけ分岐させる
D.
validateName 関数を削除する
解説: 「名前は必須です」というメッセージが2か所に重複しており、条件だけが異なっています。DRYの観点からは、条件をまとめて1回のメッセージにするか、共通のエラーメッセージ用関数を利用するなどして重複を減らすとよいです。
6 . 次のコードは、「分かりやすさ」よりも「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;
解説: 「条件式 ? true : false」は、そのまま条件式だけで十分意味が伝わる場合には不要な複雑化です。KISSの観点からは、`const isAdult = (age) => age >= 18;` のようにシンプルに書く方が読みやすくなります。
null チェックが必要な場合でも、別途分かりやすく書いたほうがよいでしょう。
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 を使う
解説: ログフォーマット(日時+ID+名前)が重複しており、DRY的に良くありません。共通関数にまとめておくと、ログ形式の変更も1か所の修正で済みますし、KISSの観点からも意図がはっきりします。
8 . 次のコードは、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'
});
}
A.
method を 'POST' に変更する
B.
'Content-Type' をヘッダーから削除する
C.
共通の fetch オプションを変数や関数にまとめ、URLだけ変えるようにする
D.
fetch を axios に置き換える
解説: fetch のオプション(method / headers / credentials)が関数ごとに重複しています。DRYに反する典型例です。
共通オプションを1か所にまとめておき、URL や一部オプションだけ変えるようにすると、変更時の修正漏れも防げます。
9 . 次の関数は、条件分岐が深くネストしています。KISSの観点から、どのような改善が最も効果的でしょうか?
function process(user) {
if (user) {
if (user.isActive) {
if (!user.isBanned) {
// メイン処理
doSomething(user);
}
}
}
}
A.
user をグローバル変数にする
B.
ネストした if をガード節(早期 return)に変えて、ネストを浅くする
C.
doSomething の中にすべての条件チェックを移動する
D.
isActive と isBanned のプロパティ名を変える
解説: 条件が増えるたびにネストが深くなり、読みづらくなっています。KISSの観点からは、早期 return を使って「条件を満たさない場合はすぐ抜ける」形にして、メイン処理を左端に寄せるとスッキリします。
10 . 次の関数は、ネストが3段階の三項演算子になっています。KISSの観点から、どのような改善が望ましいでしょうか?
function getStatusLabel(status) {
return status === 'active'
? '有効'
: status === 'pending'
? '承認待ち'
: status === 'suspended'
? '停止中'
: '不明';
}
A.
すべて '不明' を返す
B.
if-else 文に書き換えるか、マップ(連想配列)を使ってシンプルに表現する
C.
ラベルを英語に変える
D.
status を数値に変える
解説: 三項演算子をネストしすぎると、KISSに反して読みづらくなります。この程度の分岐であれば、if-else 文で素直に書くか、`const labels = { active: '有効', ... };` のようにマップを使って表現する方がシンプルです。