はじめに
エンジニアとしてキャリアが4年ほど経過しましたが、いまだにコードレビューを出す行為が苦手です。特に予め設計が組まれていて部分的に切り出された課題に対して、適切にレビューを出すのが苦手だなと感じています。
レビューのプロセスやレビューする側の記事はいくつもありますが、レビューをされる側の記事はあまりないなと思っています。
レビューを出すのに苦手意識のあるエンジニアには特に読んでほしい記事になってます。
レビューされる側の立ち位置
レビューする側（以下レビュアー）とレビューされる側（以下レビュイー）は、上司と部下の関係が多く、レビュアーの方が経験年数は上だと思います。そのため、レビュイーはレビュアーの指摘に対して、多くの場合は従うことが推奨されていると思います。
ただ、勘違いしないでほしいのは、レビュイーは受け身であってはならないことです。レビューを出したコードに対して、一番の理解者はレビュイー自身です。そこが抜けてしまうがためレビューアーに完全丸投げしてはNGだということ。例えば、「コードレビューお願いできませんか？明日までに」という当事者意識のない文章を送ってしまっては、レビュアー側はストレスに感じてしまい、お互いにとって不幸な未来にしかならないでしょう。
レビューとは、あくまで自分のタスクを第三者にみてもらって不安な点を解消するプロセスです。筆者もよくあったのが動かないコードに対してレビューを出す場合は、レビュイーとして当事者意識のない最たるものになります。
上下関係になりやすいレビューですが、レビュイー側は特に能動的にコミュニケーションが求められると考えています。
プログラムを文章で伝える難しさ
実際にレビューにかけるコードについて、伝達の方法についてお話しします。昨今のリモートワークの普及に伴い、文章でレビュワーに依頼すること場合が多いでしょう。よくありがちなのが、「このコードは〇〇という機能があって..」と長々書いてしまう場合です。
レビュアーは何を知りたいのでしょうか？それはおそらく、「レビュイーが適切なコードを書いて適切なサービス提供できているか」 を知りたいはずです。そこに処理はここをこうして...と書かれると「いやコードを読めばわかるやん！」という気持ちになります。なので、レビュアーには「適切な粒度で伝わる文章と表現」で依頼する必要があります。
以下、筆者が書いたひどいレビュー依頼文を記載します。絶対真似はしないように..
(SQLを想定して書いてます)
××のクエリに関してレビューをお願いします。
注意点として、容量が多くなってしまうので、1日分のテーブル分が取れるの分だけで実施しました。
ただし、クエリを実行すると、下記エラーが出てしまいました。(エラー文)
以下レビューの観点です。
・クエリとしてとってきている処理が正しい処理をしているのか？
・クエリ自体目的が達成できているか？
・下記できなかったところと懸念点及びテーブルの仕様で確認するの解消方法の3点です。
以下、今回の処理の流れと、一部まだ未対応な点と、テーブルの仕様を確認する必要がある点に関しても記載させてください。レビューの際に補足としてみていただければ幸いです。
（長文ですみません）
① やったこと....
②できなかったこと....
③ 懸念点及びテーブルの仕様で確認する点...
レビュー観点の難しさ
次に適切にレビューを出すことを考えていきましょう。ここで登場するのが、レビュー観点です。端的に言えば 「コードの見てほしいポイント」 です。レビュー観点に関して良い書き方について考えてみましょう。
箇条書きでレビュー観点を伝える
筆者が書いたひどいレビュー依頼では、文章チックで要点も纏まってないです。
「何のプログラムなのか？」「レビューしてほしい点は何か」 を箇条書きする方法でレビューを出されていた方がいました。その文章を見て、こうすればうまく伝わるなと思い、参考にさせて頂いてます。以下良いレビューの出し方の例です。
〇〇クエリのレビューをお願いします。
店舗ごとのアプリ会員数とhoge広告閲覧者の合計値を取得するクエリ
joinの方法
同じ期間内で、片方のテーブルに存在したがもう片方になかったものがあったので left join
更新頻度に関して
前段のクエリが△日前からの更新のため、合わせて対応
コード上のコメントをうまく活用する
レビューで指摘してほしいポイント以外にも、複雑な処理をやっている場合、初見だと気になってしまう可能性もあります。その際はコード上に「ここの処理はこういう意図」と書いておくのが望ましいです。それは、初見で見る人に対する配慮はもちろんのこと、自分自身改めてコードを見返した場合にも「どんな処理だっけ？」と振り返られる材料にもなります。
以下BigQuery上でのコメントの書き方例になります。
-- joinに際して店舗ごとの集計にする必要有
with sum_member_sum_per_store as(
select
date,
storename,
-- アプリの会員数の日毎の合計
sum(member) as sum_member
from store_app_member
group by date,storename
)
SELECT
b.event_date,
b.storename,
-- アプリの会員数の日毎の合計
ifnull(s.sum_member, 0) as sum_member,
-- うちアプリのhoge広告をみた人
sum(b.count_view_user) as sum_count_view_user
from app_hoge_commerce_view_user as b
/**同じ期間内でhoge広告のマートにあって
アプリ会員数のマートにないデータがあったのでleft join**/
left join sum_member_sum_per_store as s
on
s.date = b.event_date
and s.storename = b.storename
group by event_date,storename
-- 前段のクエリと更新頻度を合わせた
where event_date between ‘hoge_day’and 'fuga_day'
※注意点として、既存のコードをコピーする場合、コピー元のコメントは必ず消すようにしてください。仮に残した状態でレビューを出した場合、レビュアーから「なんだこれ？」と思われて心証がよくありません。
レビュアーは神でもないし鬼でもない
レビュアーに適切な粒度でのレビューを投げる方法について話してきました。
注意すべきは、レビュアーの指摘を絶対的な解として考えてはなりません。レビュアーは初見でレビュイーのコードを見て指摘します。だから、レビュイーは指摘に対して「本当にそうか？」と改めてコードを見返す必要があります。指摘を鵜呑みにすると結局何をやってるかわからなくなって、指摘が間違っていて自分の書いたコードを2回書く可能性があります。
加えて、レビュアーの指摘に怯える必要もありません。
指摘されてばかりだと、人間凹んでしまいます。結果、当たり障りのない修正しか加えられなくなって、指摘が膨らむケースは筆者も経験があります。そこはレビューアーに「指摘全体的に丁寧で優しい説明にしてもらえると...」とレビュアーに意見を出しましょう。改善してくれると思います。
それでも治らなかったり、相手を罵倒するような表現を使い続ける場合は、レビュアー側に問題があります。その場合は、他の上司に相談して注意してもらうなり、関係性が修復不可能な場合はプロジェクトを変えてもらうなりしましょう。ただしそれは最終手段なので、積極的にレビュアーと議論することをオススメします。
レビュアーはあなたを責めたいのでなく、より良くしたいから指摘するのです。
レビューする立場になって考えてみよう
ここまでレビュイー目線での難しさを語ってきました。
少し話は変わりますが、筆者自身振り返ってみると「相手の疑問点を解消する」点については苦手意識なく楽しさも感じてます。
例えば、営業さんが「今度自前でこんな分析やりたくて、でもpythonでエラー出ちゃったんだけど見てくれる？」と言った場合に、プログラム見て「エラーの原因は〇〇で××すればどうですかね？」など相互に議論することができてました。他にも、kaggleでチームを組んだ場合でも相手の出した結果やコードに対して適切なアドバイスができてました。
では、なぜレビューをされる立場になると苦手意識が生まれてしまったのか？
それは レビュアーの状況や作業量の観点を踏まえられてなかったから です。例えば、上で書いた長〜いレビュー依頼文を出した際に、「ああ、早く依頼出さないと....」という自分岐点でしか物事を考えられてませんでした。自分がレビューする立場であれば、「こんな長い文章送ってきて、面倒くさいなあ」と感じます。
ふと、相手の疑問点を解消する際に立ち返ってみました。その時に、「こんなエラー自分も出たな、丁寧に説明する必要あるな」と思えていました。自分が通ってきた道だからこそ、相手の立場もよく理解できました。
レビュー出す場合も同様に「こんな長い文章だったら〇〇さん疲れさせちゃうかな..」と思えるようになった瞬間、端的で相手に負荷をかけないようなコミュニケーションになるべきだと気づくことができました。
快適なコミュニケーションを目指して
私自身、レビューを出すという行為で何度も相手に迷惑をかけてしまっていました。そこには私自身が指摘されることによって相手に萎縮してしまうことが起因していました。
レビュイーも人間であってレビュアーも人間です。「俺はこれくらいできるよ」と尊大になる必要もなければ、「なんでこんなにできないんだ」と卑屈になる必要もありません。
あくまで、より良いプログラム作成するという目標の途中過程でレビューが存在しています。 普段の仕事と同様に、独りよがりにならず、相手のことを思いやれれば、きっとレビュアーとも良い人間関係が築けると筆者自身は感じています。
参考にした記事
最後に、参照したQiitaの記事を紹介したいと思います。
-
レビューのやり方・進め方（効率的、効果的にレビューをしよう）
→レビューなんてやりたくない...と思い立った時にこの記事を見つけました。
レビューの観点や優先度をつけるところを参考にしたほか「レビューアがすべて指摘できるとはかぎらない」や「レビューイを攻撃しない」の章もレビューされる立場から考察してみました。 -
エンジニアの劣等感との付き合い方
→劣等感に苛まれず、いかに自分らしくレビューできるか？という点で参考にさせていただきました。