正解なのに、怒られる
初めて機能実装のタスクをもらい、必死で書いたコード。テストも通り、ブラウザ上でも意図通りに動いています。
意気揚々とPRを出すと、先輩からのレビューコメント。
「動いてるけど、変数名を見直しましょう」
「このif文のネストが深すぎます。早期リターンを使いましょう」
「マジックナンバーに名前をつけましょう」
内心、不満でした。
「動いてるんだからいいじゃん。なんで文句つけるの？」
しかし数ヶ月後、自分が過去に書いたコードの機能追加を任された時、初めてその意味を理解しました。
自分で書いたはずのコードなのに、何をしているか1行も思い出せない。
「動くコード」と「読めるコード」の差
ケース1：変数名
// ❌ 動くけど読めない
const d = new Date();
const a = d.getTime() - s.getTime();
if (a > 86400000) { ... }
// ✅ 動くし読める
const currentDate = new Date();
const elapsedMilliseconds = currentDate.getTime() - startDate.getTime();
const ONE_DAY_IN_MS = 24 * 60 * 60 * 1000;
if (elapsedMilliseconds > ONE_DAY_IN_MS) { ... }
ケース2：ネストの深さ（早期リターン）
// ❌ ネスト地獄
function processUser(user) {
if (user) {
if (user.isActive) {
if (user.hasPermission) {
// ...本来の処理（ここにたどり着くまで頭が疲れる）
}
}
}
}
// ✅ 早期リターンでフラット
function processUser(user) {
if (!user) return;
if (!user.isActive) return;
if (!user.hasPermission) return;
// ...本来の処理（一目瞭然）
}
ケース3：マジックナンバー
// ❌ 86400000って何？
if (elapsed > 86400000) { ... }
// ✅ 名前がついていれば一瞬で分かる
const ONE_DAY_IN_MS = 24 * 60 * 60 * 1000;
if (elapsed > ONE_DAY_IN_MS) { ... }
なぜ「読めるコード」が大事なのか
プログラマは、コードを「書く」時間よりも「読む」時間の方が圧倒的に長いからです。
Robert C. Martin『Clean Code』より：
「コードを読む時間と書く時間の比率は10:1を超える。
新しいコードを書くためには、常に周囲の既存コードを読まなければならない」
あなたが書いたコードは、3ヶ月後の自分、先輩、そしてまだ見ぬ後輩が読みます。その時に「何をしているか」が一瞬で分かるコードは、チーム全員の時間を節約する最高の贈り物です。
明日から始められる3つの習慣
-
変数名に30秒悩む：
dではなくcurrentDate。この30秒が、未来の30分の読解時間を節約する - PRを出す前に「自分のdiffを声に出して読む」：声に出して読んで意味が通らない箇所は、他人にも伝わらない
-
先輩のコードから「良い命名」をパクる：上手い人のコードには、良い変数名・関数名の見本が詰まっている
「動けばいい」は、趣味のコードなら正解です。でも、チームで作るプロダクトのコードは、「読めること」が最低限の品質です。この感覚を入社1年目で掴めたら、あなたの成長速度は圧倒的に加速します。