筆者は何度かソースコードレビューという作業があるプロジェクトに従事した事がある。
しかし、その度に思っていたのが、
「これ、費やしている時間に対して、リターン少ないのではないか？」
と、漠然と思っていた。
そして、先日とあるプロジェクトの区切りの反省会を行う機会があり、
その際に、コードレビューがあったにも関わらず、物凄く初歩的なバグが出てたりしていたことが議題に上がり、
ソースコードレビューという物の存在意義がますます分からなくなっていった。
しかし、別のプロジェクトに居る知人から、そのプロジェクトで行われているソースコードレビューの内容を聞いた時に、
筆者なりのソースコードレビューの意味、在り方が少しずつ見えてきたので、
その知見を共有したい。
〇思考を巡らす前に感じていた、ソースコードレビューの問題点
ぶっちゃけ、
「ソースコードレビューを行う目的が不明確」
という事が全てなのだが、しばしその思考に至った理由を見ていただきたい。
1．かけるコストに対するリターンが少ないと感じる
ある人は、実装内容を頭から全てトレースして、設計やバグが起きそうな内容にまで言及している。
しかし、それは物凄く時間がかかる事だと思うのだ。
更に、ソースコードレビューはタスクとしてスケジュールに反映されていないので、
スケジュール管理の観点から見ると、仕事をしないで関係ないことに時間を費やして
いるという事になる。
これでは、むしろソースコードレビューは害になっていると言っても過言ではない。
2. レビューの熟練具合が、人によって異なる。結果、一番熟練している人に任せて、熟練していない人は見なくなる
ある人は、設計にまで言及し、ある人はTypoや規約違反だけ指摘する。
こうなると、熟練のレビュアー一人に任せてしまえば、それ以外の人が見るのは時間の無駄と思えてきてしまう。
事実、筆者はコードレビューするくらいなら、熟練者の人が見た方がいいんだからと、レビューをせずに作業に集中するという割り切りをした。
〇ソースコードレビューを行う目的
そう、順序が逆だったのだ。
ここでも、問題に対する解決策を考える必要があったのに、
先にソースコードレビューという物が先行してしまい、それが何に寄与するのかを考える事をしなかったのが、存在意義に疑問を持ってしまった理由だ。
そもそも、何故ソースコードレビューを行う必要があるのだろうか。
ソースコードレビューを行うメリットが何かあるはずなのだが、それはなんなのだろうか？
色々な意見があると思うが、筆者が思考を巡らせて至った考えを書くと、
プロジェクト進行という観点からすると、
ソースコードレビューで解決したい「問題」は、クオリティアップと無駄な時間の削減しかない。
そして、それの障害になる物があるとしたら、
問題があるとされるコードの早期発見による解決
・バグに関わる物（バグその物、悪い設計等）
・進行に関わる物（車輪の再発明や、ユーティリティメソッドの共有等のパイプ役）
これしかないと思う。
ソースコードレビューも問題解決の手段の一つに過ぎないので、
この問題を解決する事を目的に行うのが、ソースコードレビューであり、
逆に言えば、この問題が解決できるようにソースコードレビューを行わなければならない。
と、考えた。
〇じゃあ、それ全員でやるの？
平均レベルの新卒プログラマがコードレビューをしたからと言って、バグの発見や設計の悪さを指摘できるとは思えないだろう。
というより、かける時間に対して、リターンが少な過ぎる、と言った方が正しいかもしれない。
つまり、能力がある人間が少数で行うのが理想的なのではないかと推測する。
〇こうすればいいんじゃないかという提案
これは、知人のプロジェクトで実際にこのような思想で行われているのではないか？という想定を基に考案した物だ。
特に実績があるわけがないので、そこは注意してみて頂きたい。
・「PRのマージ許可を出す責任を持つ」、という人が2人以上、レビュアーになる
⇒1人だとリスクが高い。なので、2人という仮設定。
・レビュアーは、プロジェクトでのプログラム作業経験があるメンバーが行う
⇒どの程度できるか、というのが定量化できないのが難しい所だが、3年程プロジェクトに従事したメンバーなら、任せてみてもいいのではないかと思う。
・レビュアーは、全ての設計・実装を理解出来るようにレビューを行う必要がある
⇒レビュアーは、この意識を強く持つ必要がある。全てを理解する事が使命と理解する。
・レビュアーのソースコードレビューのタスクは、実装タスクよりも優先度が高い
⇒ここが回らなくなると成果物のマージがされない為、むしろ専属でもいいくらいだと思う。
・更に、レビュアーにはソースコードレビューというタスクの工数をきちんと割り当てる
⇒プロジェクト管理者が、プロジェクト管理に工数を取るように、レビュアーにも、ソースコード管理という工数を割り当てるのは問題ないと思う。
・後は、リスクとリターンに応じて、レビュアーの人数を増減させればいい
⇒ここは、バランスと実際に行ってみての効果がどの程度あるか見ながらだと思う。
さしずめ、ソースコード版QAと言ったところか。
この方法なら、熟練者がプロジェクト全体の設計に言及する事で、プログラムクオリティの平均値が上がりそうだし
タスクとしてソースコードを確認しているので、事前のバグもある程度は見逃しにくくなるのではないかと思われる。
レビュア以外は、通常通り作業に集中すればいい。
〇結局、ソースコードレビューってなんなのよ
グダグダと長く書いてしまったが、この記事の内容に沿うと、
ソースコードレビューとは、ソースコードのQAが、ソースコードのクオリティを担保する為に行う手法・作業フローである、と定義できそうだ。
つまり、レビュアーは、ソースコードのクオリティを担保する責任を負う、という事になる。
これを脳内トレースしてうまく行きそうか考える所までは至っていないのだが、
これは、自分達がソースコードレビューを行う理由が出来た時に、考える必要がある事なので、
その時の為のヒントとして、これを残しておく。
