【エンジニアあるある】コードレビューで指摘された箇所、実は他の人が書いたコードだった

2025年2月25日

こんばんは！IT業界で働くアライグマです！

コードレビューを受けていると、自分が書いた覚えのない箇所について指摘されることがあります。慌てて確認してみると、実は別の人が書いたコードだったという経験をしたことがあるエンジニアは多いのではないでしょうか。こうした状況は特に、チーム開発では頻繁に発生します。

コードレビューは、品質を向上させるために不可欠なプロセスです。しかし、レビュー時に「この処理はおかしいのでは？」「この書き方は冗長では？」と指摘されても、自分が手を加えていないコードだった場合、どのように対応すべきか戸惑うこともあるでしょう。

このような誤解が生じる原因や、それをどのように解決すればよいのかを詳しく見ていきます。

Contents

なぜこうした状況が発生するのか

このような勘違いが起こる理由はいくつかあります。

コードは変更履歴の積み重ねで成り立っています。過去に別のエンジニアが書いたコードが、何らかの理由で自分のプルリクエストに含まれてしまうことがあります。例えば、リベースやマージの際に意図せず変更が含まれるケースです。

レビュアーも人間です。コード全体を正確に把握しているとは限りません。変更履歴をすべて確認せずにレビューを進めると、「この書き方はおかしい」と指摘されることがあります。特に大規模なプロジェクトでは、全員がすべてのコードを熟知しているわけではないため、誤解が生じやすくなります。

特に長期間メンテナンスされていないコードや、複数人が関わるプロジェクトでは、誰がどのコードを書いたのかが分からなくなりがちです。Gitのログを見なければ、誰の変更なのかを特定するのが難しいこともあります。

プルリクエストを作成する際、意図しないファイルが変更に含まれてしまうこともあります。これにより、思いがけないコードがレビュー対象になり、指摘されるケースがあります。

このような誤解を防ぐためには、いくつかの対策が有効です。

コードレビューを受ける前に、git blame や git log を活用して、自分が変更した箇所を把握しておきましょう。特に、他の人の変更が混ざっていないかを事前にチェックすることが重要です。

もし自分が書いた覚えのないコードを指摘された場合、慌てずに「このコードは私が書いたものではないかもしれません」と伝えましょう。場合によっては、過去の担当者に確認するのも手です。GitHubのコメント機能を使って、コードの作者にタグをつけて質問するのも有効な方法です。

他の人が書いたコードであることが明確になるように、コメントを追加したり、適切なドキュメントを整備することで、誤解を防ぐことができます。また、コードの意図や背景を説明するコメントを残しておくことで、次にメンテナンスする人が迷わないようにできます。

レビュー時のルールや基準を統一することで、誤解を防ぐことができます。例えば、「レビュー時には変更履歴を確認する」「関係者に確認を取る」といった基本ルールを決めておくと、スムーズに進めることができます。

コードレビューは、単にバグを指摘するだけでなく、チーム全体のコード品質を向上させるためのプロセスです。そのため、他の人のコードと間違えられることがあっても、それを前向きに捉え、より良いコードにしていくことが重要です。

また、レビューの際には単に「ここが間違っている」と指摘するのではなく、「このコードの意図は何か？」と考えながらコメントすることで、より有意義なフィードバックになります。

コードレビューで自分の書いたコードではない部分が指摘されたとき、最初は戸惑うかもしれません。しかし、こうした機会をチーム内の知識共有やコード品質向上のチャンスと捉えることが大切です。

例えば、指摘をきっかけにして「この部分の仕様はどうなっているのか？」と議論を深めたり、「この書き方はなぜ良くないのか？」と学ぶことで、チーム全体のスキルアップにつながります。また、自分が直接手を加えていない部分についても意見を持つことで、より広い視点でプロジェクトに関われるようになります。

コードレビューは単なる指摘の場ではなく、チーム全体でより良いコードを作るための重要なプロセスです。誤解が生じることもありますが、それを乗り越えていくことで、より成長できる環境を作ることができます。