9
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

レビューを受ける側として気をつけてきたことの雑記

Last updated at Posted at 2025-03-27

はじめに

これまでレビューを受ける側(レビューイ)としてやってきた工夫を整理します。

観点が混ざるとややこしくなりそうなので、レビューをする側(レビュアー)としての工夫は別記事にします。

プログラム等のレビューに限らず、資料作成などにも通じるものとして書いているつもりですが、半ば無意識にプログラミングを前提にしている項目もあるかも。

レビュー依頼を出すまで編

できれば小さい単位で

変更量の多いレビューは、見るのがとても大変です。あまり大きすぎると、細かいところまで気を回せなくなる場合もあります。

どれくらいのボリュームが適切かは状況によっても違うでしょうけど、悩んだ時は「できれば小さい単位で」を一つの指標にできるかなと。
小さくなりすぎて問題になったら、その時に改めるくらいで丁度いいかもしれません。

特に、大きな手戻りが発生するような事態は避けるべきです。

例えば2週間かけて書き上げた、もうほとんど出来上がってますみたいなコードがそれまで一度もレビューされておらず、いざレビューに回ってきた時に「これ、そもそもの設計がマズいのでは?」みたいなちゃぶ台返しが発生すると、大幅な手戻りになってとても辛いことになります。
大きめの判断については、早い段階で人に相談するなりレビューに出すなりしましょう。

「大きめの設計や実装を3日誰にも見せてない(1人だけで作業してる)のはマズい」みたいな定量的な指標をチームで設けてもいいかもしれませんね。

持っている情報は明確に伝える

情報が足りないと、レビュアーが想像するか、作業者(レビューイ)に聞くかしないといけないけど、どちらもあまり効率が良くないです。
もちろん、内容に疑問があってレビュアーから質問がいくのは普通のことですが、できれば先回りで「疑問に思いそうな箇所」は補って、質問が少なく済むと親切。

持っている情報、の具体的な例は、参考にした資料や、作業の前提となる情報など。

  • 他システムとの連携を行う場合、連携相手の仕様が分かるようにする、とか
  • こういう方針で作業しました、とか
    • 設計の打ち合わせをやったときのホワイトボードなど
  • こういう作業がまだ残ってます/この作業はもう終わってます、とか
    • これがないと、漏れているのか、後でやる予定なのか等が分からない

進捗を示す場合、具体的に何が終わっていて何が残っているのか明示されると親切です。
例えば何らかのマスター保守画面を作成する場合なら↓のような感じ。

1. マスターを作成する(テーブル作成のDDLなど)
2. 参照系のバックエンド処理を作成する <- 今ココです
3. 更新系のバックエンド処理を作成する
4. フロントエンドを作成する

特に見て欲しいところや懸念点があればハッキリ書く

例えば「テストパターンが十分足りているか少し不安です」など懸念点が示されていれば、レビュアーもそこを気にして見るので、的確なフィードバックをもらいやすくなります。

注意点として、「不具合がないか確認して欲しい」と書きたくなったら、それは原則として実装者の責務のはずなので自分でやりましょう。
「自分でも全力を尽くしたつもりだけど、複雑なロジックなのでレビュアーさんの力も借りたい」とかならOKかも?

逆に、「まだあまり動作確認できていないザックリの実装なので、バグってないかの観点は一旦いらないです。大きな処理の流れに問題ないかを見てもらいたいです」とか、そういうのはあって良い。

何を見てもらいたいのかを明確にするのは大事です。

面倒くさがらない

ここまでに書いてきたことを「ちゃんとやる」のって、結構面倒くさいです。

でも、実装者にとって「ちゃんと説明するのが面倒」な内容は、レビュアーが理解するのはもっと面倒(大変)です。
レビュアーの負荷軽減のためにも、情報をきちんと残す意味でも、「ちゃんとやる」のはとても大事です。

ちなみに、最初の「できれば小さい単位で」を意識できていると「ちゃんと説明する」ことの大変さも少し軽減されるかも。

あとは、コードレビューを依頼するときのテンプレートを用意しておいたり、過去の類似レビューを真似るなどすれば「ゼロから全部自分で書く」必要がなくなるので、コストを下げられます。

指摘を受けてから編

納得していないなら修正しない

よく分かっていないのに、「レビュアーの人がそう言うならそうなんだろう」みたいな姿勢で対応しない。

忙しかったり、とにかく目先の仕事をやっつけたい時に起こりがち。
あとはレビュアーの方が組織上の立場が上なことも多いと思うので、そういう場合も起こりがち。
でもこれだと、チーム内での知識共有に繋がらない。

指摘内容がよく分からないなら、納得できるまで質問する。
そうでないと、成長の機会を逃すことになります。

質問に「修正しました」で返さない

先程の「納得していないなら修正しない」にも近い話ですが、例えば「このパターンではXXXを使うことが多いと思いますが、そうしなかった意図がありますか?」みたいな質問をもらったとして「XXXを使うように修正しました」とだけ返すと、納得した上での変更なのか「言われたからその通りに直した」のかがレビュアーに伝わらないです。

修正する場合も「〇〇だと思ってこう書いてたんですが、確かにXXXの方が良さそうなので修正しました」みたいにやり取りできると、受け手(レビュアー)の印象はかなり違います。

9
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?