【エンジニアあるある】コードレビューで指摘された箇所、実は他の人も同じ間違いをしていた
こんばんは！IT業界で働くアライグマです！
コードレビューを受けるたびに、「また同じような指摘をされた…」と落ち込んでしまうことはありませんか？特に未経験や駆け出しのエンジニアにとって、レビューでの指摘は「自分だけができていないのでは？」と不安を感じる原因になりがちです。しかし、実は多くのエンジニアが同じような間違いを繰り返し、指摘を受けながら成長しているのです。
この記事では、コードレビューでよく指摘されるポイントを紹介し、それを改善するための具体的な方法を解説します。「自分だけじゃない」と思えれば、指摘を前向きに受け止めることができ、スキルアップにもつながるはずです。
コードレビューでよく指摘されるポイント
可読性の低いコード
コードレビューで最もよく指摘されるのが、可読性の低いコードです。プログラムが意図した動作をしていたとしても、他のエンジニアが理解しにくいコードはメンテナンス性が低く、チーム開発において問題となります。
具体的な指摘例
- 変数名・関数名が不明瞭（
tmp、data、func1など） - 一つの関数が長すぎる（100行を超える関数など）
- コメントがない、もしくは過剰に多い
改善策
- 意図が伝わる変数名・関数名を付ける（例：
userListやcalculateTotalPrice） - 関数を適切に分割する（1つの関数は基本的に1つの責務を持たせる）
- 適切なコメントを残す（「なぜこの処理が必要なのか」を補足する）
DRY（Don’t Repeat Yourself）原則の違反
コード内で同じ処理を繰り返してしまうのも、頻繁に指摘されるポイントです。同じ処理が複数の場所に存在すると、修正や機能追加の際にミスが発生しやすくなります。
具体的な指摘例
- ほぼ同じコードをコピペして使用
- 似たような処理を複数の関数で行っている
改善策
- 共通処理を関数化する（例えば、日付フォーマット処理を
formatDate()として共通化） - 定数や設定ファイルを活用する（同じ値をハードコーディングしない）
- クラスやモジュールを適切に活用する
適切なエラーハンドリングができていない
エラーハンドリングを軽視してしまうと、システムが予期しない動作をしたり、クラッシュの原因になったりします。特に初心者は、エラーハンドリングを後回しにしがちですが、コードレビューでは必ずと言っていいほど指摘されるポイントです。
具体的な指摘例
- 例外処理がない（
try-catchを使っていない） - エラーを無視している（
catch (Exception e) {}だけ書いて何もしない） - ユーザーへの適切なエラーメッセージがない
改善策
- 適切なエラーメッセージを返す（
"データの取得に失敗しました"など、具体的な情報を出す） - ログを記録する（エラー発生時に
logger.error(e)のようにログを出力） - 意図的に例外を投げることで異常系のテストをしやすくする
コードレビューの指摘を前向きに活かすには
指摘を個人攻撃と捉えない
コードレビューの目的は、エンジニア個人を批判することではなく、より良いコードを作ることです。指摘を受けるとつい落ち込んでしまうこともありますが、「これはチーム全体の品質向上のためのアドバイスだ」と考えることで、前向きに受け止められるようになります。
同じ指摘を繰り返さないためにメモを取る
同じ間違いを何度も指摘されると、自分の成長が感じられずモチベーションが下がってしまうことがあります。そのため、指摘された内容をメモに残し、次回のコーディング時にチェックする習慣をつけることが重要です。
他の人のコードレビューも参考にする
自分のコードだけでなく、チームメンバーのコードレビューの内容をチェックするのも学習の機会になります。 他の人がどのような指摘を受けているのかを知ることで、共通する課題や改善点が見えてきます。
まとめ
コードレビューで指摘された箇所は、実は他のエンジニアも同じように間違っていることが多いです。特に、可読性の向上、DRY原則の遵守、適切なエラーハンドリングなどは、どのエンジニアにとっても課題となるポイントです。
大切なのは、指摘を前向きに受け止め、学びのチャンスと捉えることです。同じ指摘を繰り返さないように工夫し、コードの品質を高めていけば、エンジニアとしてのスキルも着実に向上していきます。
「自分だけができていないのでは？」と不安に思う必要はありません。むしろ、指摘されるということは、それだけ成長のチャンスがあるということです。コードレビューを通じて、より良いエンジニアを目指していきましょう！