コードレビュー
この記事を読んで。
とても同意できる部分が多かったし、考えさせられる部分も多かった。 チーム開発において、コードレビューが当たり前のように正しいもの、と認識されるようになって、ただ当たり前になりすぎて、どういう意味があるのか、少し考える機会が少ないのかもしれない。
コードレビューはちゃんとやろうとするとかなりの時間をとられる。まとまったコードのPull Requestに対して、背景を理解して、差分を隅々まで見て、差分以外の関連する部分も確認する。背後にあるデータや様々な条件に想像を膨らませる。こういうことを真面目にやると、2、3時間かかる事は普通にある。
僕は、コードレビューには、大きく二つの目的があると思っていて、コードの質に対するレビューと、不具合を見つけるためのレビューがあると考えている。 それらがどれくらい必要とされるかは、チームの状態だったり、プロダクトの状況・重要性によって、結構幅があるんじゃないかと思う。人は、いろんなプロジェクトに関わって、その中でいろんなチームの文化に触れて、コードレビューに対する考え方を持っていくんじゃないかと思うし、コードレビューといったときに、哲学とまではいわないけどなんらかの思いを持っているんじゃないかと思う。
自分は、どちらかというとコードレビューというものに価値がある、と思っている方だと思う。
ただ、コードの質を上げる、という意味においては、コードレビューによって直接的・本質的な効果は出にくいなと思っていて、そういったものは普段の会話の中で設計について議論したり、チーム全体のエンジニアリングの力を上げるための施策をしたほうが効果的だと思っている。
振り返ると、自分がコードレビューで重視してきたのは、不具合や危険なコードを防ぐ、というところが大きい。 これはおそらく経験によるところがあって、自分が経験がだいぶ浅い時代、あるチームに参加したときに、すごく厳しいレビューをする人がいた。自分の人生の中でも尊敬するエンジニアの一人だ。そのチームのプロダクトは、コードも歴史を重ねていて複雑になっていたし、決して綺麗とは言えるコードではなかった。普通に考えると、不具合も起きやすい状態だった。でも、その人は、すべてのコードに対して丁寧に目を通していて、そんな条件のバグ見つけるか？っていう不具合を、コードを読んだだけで見つけていた。もちろん、その人が書くコードにほとんど不具合はなかった。人はここまでコードに対して注意深くなれるのかと衝撃をうけた。 おそらく、これは人によって感じ方は違うと思うけど、自分はこの人のことをかっこいいと思ったし、ここまでしてちゃんと自分たちがリリースするコードに責任をもつ、というのがプロのエンジニアなんだと思った。
だから自分は、おそらく、人より注意深くコードレビューをする方だと思うし、時間をかけることが多い。ただ、これはだいぶ偏った考え方の自覚もあるから、全員がやるべきだとも思わない。
でも、そうやってコードを読む、ということを習慣づけていくと、コードを読むということが自分の力になるというのを実感するようになる。コードを読んでそのプロダクトの詳細を理解する。そうするとちゃんとそのプロダクトでエンジニアとして価値を出せる。そう思うようになった。
一方で、いろんなエンジニアを見ていると、人それぞれに強い領域があって、チームでの価値の出し方も違うし、成長の仕方も全然違うんだなとも思うようになった。だから、コードレビュー怠けるけど、コードをたくさん書くみたいな人がいてもいいし、そういうチームの方が強いと思う。
チームの文化としてコードレビューはこうあるべき、というのはあまり考えなくなったけど、自分自身としては、これからもなるべく人のコードをたくさん読んでいきたいとは思っている。
