【あるある】コードレビューで指摘された箇所、実は他の人も同じように悩んでいた
こんばんは！IT業界で働くアライグマです！
コードレビューは、エンジニアにとって避けては通れないプロセスです。しかし、レビューで指摘されるたびに「自分の書いたコードはダメなのか…」と落ち込んだ経験はありませんか？
実は、コードレビューでよく指摘されるポイントは、他のエンジニアも同じように悩んでいるものが多いのです。特に、経験が浅いうちは「この書き方でいいのか？」と迷いながらコードを書くことが多く、指摘を受けるたびに「またダメだった…」と感じてしまいがちです。
この記事では、コードレビューでよく指摘されるポイントと、それを事前に防ぐための工夫について解説します。同じ悩みを抱えているエンジニア仲間がたくさんいることを知り、前向きにコードレビューを受けられるようになりましょう。
コードレビューでよく指摘されるポイント
コードレビューでよく指摘されるポイントは、多くのエンジニアが同じように悩んでいる箇所でもあります。以下に、特に頻繁に指摘されるポイントを紹介します。
命名がわかりにくい
変数名や関数名を付けるのは、意外と難しいものです。「わかりやすく書いたつもりなのに、レビューで指摘される」という経験がある人も多いのではないでしょうか？
よくある指摘例
tempという変数名では、何のデータを保持しているのかわからないprocessData()では、具体的に何を処理するのかわかりにくいaやbのような一文字の変数は、意味が不明
改善のポイント
- 変数名には「どんなデータが入るのか」を明示する
- 関数名には「何をするのか」が一目でわかるようにする
- 省略しすぎず、適度に説明的な名前をつける
例
// NG
let temp = getUserData();
// OK
let userData = getUserData();
コードの可読性が低い
「動くからいいや」と思って書いたコードが、後から見返すと何をしているのか分かりにくいことがあります。特に、一行で処理を詰め込みすぎたり、無駄に複雑なロジックを書いたりすると、レビューで指摘されることが多くなります。
よくある指摘例
- 条件分岐がネストしすぎていて、何を判定しているのか分かりにくい
- 1つの関数の中に処理を詰め込みすぎている
- 短く書きすぎて、意図が伝わらない
改善のポイント
- 適度に改行を入れて、処理の区切りを明確にする
- ネストが深くなりすぎる場合は、関数に分ける
- 読みやすさを優先し、短縮しすぎない
例
// NG
if (user && user.isActive && user.role === 'admin') {
doSomething();
}
// OK
const isAdminUser = user && user.isActive && user.role === 'admin';
if (isAdminUser) {
doSomething();
}
DRY原則が守られていない
「同じようなコードが繰り返し出てくる」と、レビューで指摘されることがあります。プログラムの基本原則である DRY（Don’t Repeat Yourself） を意識していないと、冗長なコードになりやすいです。
よくある指摘例
- 同じ処理を複数箇所でコピペしている
- 似たような関数がいくつも存在する
- 定数や設定値がハードコーディングされている
改善のポイント
- 再利用できる部分は関数化する
- 設定値や定数は一箇所にまとめる
- コードの共通部分を意識する
例
// NG
function calculateTax(price) {
return price * 0.1;
}
function calculateDiscount(price) {
return price * 0.05;
}
// OK
function calculatePercentage(price, rate) {
return price * rate;
}
コメントが不足している or 多すぎる
適切なコメントを入れることは重要ですが、適量を意識することが大切です。コメントがまったくないと「何をしているのかわからない」と指摘されますが、逆にコメントが多すぎると、かえって可読性が落ちることもあります。
よくある指摘例
- 「何をしているか」ではなく、「なぜそうしているのか」が書かれていない
- コードをそのまま説明するだけの不要なコメントがある
- コメントが古くなり、実際のコードとズレている
改善のポイント
- 必要な部分にのみ、簡潔なコメントを記載する
- 「なぜこの処理が必要なのか」を説明する
- コードをそのまま説明するコメントは避ける
例
// NG
// priceに0.1を掛けると消費税が計算できる
const tax = price * 0.1;
// OK
// 税率が変わる可能性があるため、変数として定義
const TAX_RATE = 0.1;
const tax = price * TAX_RATE;
まとめ
コードレビューで指摘されるポイントの多くは、他のエンジニアも同じように悩んでいる共通の課題です。「自分だけがダメなんだ」と思う必要はなく、むしろ指摘を受けることで成長できるチャンスと捉えましょう。
特に、命名、可読性、DRY原則、コメントの適切な使い方は、多くのエンジニアがつまずくポイントです。これらを意識してコードを書くことで、コードレビューでの指摘を減らし、より質の高いコードを書けるようになります。
コードレビューは単なる指摘ではなく、チーム全体のスキル向上につながる貴重な機会です。指摘されたことを前向きに受け止め、日々の開発に活かしていきましょう。