新しいプロジェクトでコードレビューのときに意識していること

フリーランスのエンジニアとして、さまざまなチームに参加する中で、コードレビューの際に気をつけるべきポイントについて整理しました。

レビュアーとして意識していること

コードレビューをする上で、特に大事にしているのは次の2つです。

自分のレビューが正しいとは限らない

コードには正解がないので、「こう書いてほしい」と押し付けることはしません。むしろ、「こうした方がいいかも？」と提案して、相手から意見を引き出すことが大切です。そうすることで、お互いに新しい考え方を学べます。

自分の色に染めない

コードにはそれぞれのエンジニアの個性があります。自分のスタイルを押し付けると、その人の工夫を抑えてしまうことになるので、相手が自由に考えられる余地を残すようにしています。

コードレビューでチェックしているポイント

基本的にレビューで確認しているのは以下の点です：

• 不要なログが残っていないか
• デバッグ用の遅延コードがないか
• 重複したコードがないか
• スペルミスがないか
• 変数や関数の名前が適切か
• 不要なコメントアウトが残っていないか

これらのポイントをチェックすることで、コードをクリーンに保っています。

エンジニアのレベルごとのレビュー方法

エンジニアのレベルによって、レビューの仕方を変えています。

ジュニアエンジニアの場合

ジュニアエンジニアにとって、レビューが通ってアプルーブをもらえることは大きな自信になります。自分もジュニアだった頃、最初のアプルーブをもらったときは嬉しかったです。だから、ジュニアにはあまり細かい指摘はせず、必要な部分はハドルなどで直接説明することが多いです。そうすれば、説明もしやすいですし、理解も深まります。

シニアエンジニアの場合

シニアエンジニアには、あえて細かくコメントしないこともあります。👀だけ付けて「ここをどうするか考えてみて」と促すこともあり、経験豊富な分、自分で解決してもらうことが多いです。

アプルーブ後のフィードバック

アプルーブ後に、「次はこうしてみよう」とか「こういうアプローチもあり」といったフィードバックをすることもあります。これで、次回以降に向けたヒントを伝えられます。

新しいプロジェクトでのレビュー

新規参加の場合

プロジェクトのスタートから参加する場合は、まずプロジェクト全体のルールやコードスタイルを把握することを優先します。この段階では、チームが共有しているコーディング規約や、使用しているツール、進行中の技術的な方針に沿ったレビューを行うよう心がけています。最初からプロジェクトに入れると、ルール作りにも貢献できるので、その後のレビューもしやすいです

途中参加の場合

途中から参加する場合は、すでに出来上がっているルールやコードスタイルに従ってレビューする必要があります。そのため、まず過去2〜3ページ分のマージ済みコードレビューを確認して、チームの流れやルールを把握します。これにより、レビューがチームの既存のやり方にフィットし、無駄な指摘やズレを防ぐことができます。

レビュイーとして意識していること

自分がレビューを受けるときも、いくつか意識していることがあります。

300行以内でまとめる

コードをなるべく簡潔にして、レビュアーがすぐ理解できるようにしています。

ViewやModelなど階層ごとに分ける

特にUIに関するレビューは、画像や動画を付けて説明すると分かりやすくなります。

簡潔に伝える

余計な説明をせず、必要なことだけを伝えます。

結論 – アプルーブをもらえると嬉しい

アプルーブをもらえると、やっぱり嬉しいです。自分の書いたコードがしっかり確認され、問題がないと認められた安心感と、一区切りついたスッキリ感があります。コードレビューは単なるミスチェックではなく、相手との対話を通じて改善点を見つけたり、新しい視点を得たりする貴重な機会です。そのプロセスを経てアプルーブをもらえると、自分の提案や判断が正しかったと確認でき、努力が報われたように感じます。

アプルーブは次のステップに進む合図でもあり、次の作業に自信を持って取りかかるきっかけにもなります。特に、長い時間をかけて試行錯誤した部分がアプルーブされると、それまでの苦労が実を結んだ瞬間だと感じられます。