TL;DR: コードレビューを優先すべき。
こんにちわ。 合同会社コベリンの CIO です。
僕らの会社の開発は基本的にプルリクエストを出してレビューしてもらって、大丈夫ならマージするというよくある流れで行っています。
今回は、自分の作業よりもコードレビューを優先したら開発効率が増した(相手も自分も)ということについて書きたいと思います。
事の起こりは、僕が下記の記事を読んでレビューの優先度を上げたことから始まります。
この記事にはコードレビューをする側とされる側に対してどのような姿勢でそれらに望むべきかについて書いてあります。
その中に、コードレビューを最優先に！ という記述があります。
それに習って、1ヶ月ほどレビューの優先度を MAX にしました。
結果
対照実験や定量的な開発効率の計測は行っていないのですが、感覚的には改善されたと思われます。
何よりも開発のテンポが良くなった感じがあります。
こういう良くなったっていう雰囲気大事だと思います。
考察
何故改善したのかについて自分なりに考えてみます。
作業の重要度の視点で
レビューと自分の作業、どちらの方が重要なのか？ということについて考えてみます。
関わる人が多い作業を止める方が作業全体への影響度が大きいのでここでは関わる人が多い作業ほど重要であるという考え方をしてみます。
非常に雑に考えると
- 自分の作業は自分だけのものです
- 関わる人は自分1人
- レビューは自分の作業でもあり相手の作業でもあります
- 関わる人は自分と相手の2人
ということで、レビューの方が重要度が高い作業であると考えられます。
よってレビューを優先することによって重要度が高い作業が先に終わり、効率が改善されたと考えられます。
キリの良い所までという視点で
例えば自分の作業がノッている時にレビューをお願いされたとします。
弊社では Slack で 「@hogehoge れびゅよろ〜 <プルリクエストの URL>」 みたいな感じでメンションが飛んできます。
今まで僕は切りの良いところまで作業を進めて、その後にレビューをしていました。
しかし、切りの良いところってなかなか訪れない(特に作業がノッている場合)のでレビューが遅れがちになりました。
僕の経験上、キリの良い所ってのはなかなか来ないのでレビューの依頼が来たら10分以内で無理やりにでも作業を中断してレビューを行ったほうが良いと思います。
キリの良い所まで作業をするということは重要度の高いレビューを後回しにしてしまっているので結果的に開発効率が落ちます。
時間が経過するという視点で
コードを書いてから時間が立つほど書いた人でさえコードについてどんどん忘れていきます。
レビュー依頼をしたらその人は別の作業に移っていき、人間の記憶力は無限ではないのでさっきのことはどんどん忘れてしまうのでしかたのないことです。
「ちゃんと書けば後で読んでもわかりやすいコードになるはずだ」と言われそうですが、それは理想論でそんな理想を追い求めているとそれこそ開発効率が落ちます。
なのでできるだけレビューした人がコードについて覚えている状態でレビューをすべきです。
そうすることで質問に対して直ぐに答えてもらえることが期待できます。
また、コードに対する修正が必要になった場合も直ぐに修正を行うことができます。
時間が経ってからではもう一度コードを書いた時のことを思い出さなくては行けないのでレスポンスが落ちてしまい、レビューする側にも待ち時間が発生してしまいす。
これらのことからすぐにレビューを行うことで記憶を呼び起こす時間やレスポンスを待つ時間が削減されるので開発効率を改善することができます。
コミュニケーションという視点で
コードレビューはプルリクエストを通して行う人と人とのコミュニケーションです。
レビューを後回しにするということは
レビューを依頼する人: 「こんにちわ！ 元気ですか？」
レビューを依頼された人: 「...」
数時間後...
レビューを依頼された人: 「こんにちわ。元気です。」
という会話をしているようなものです。
これは明らかにテンポが悪そうですね。
ということで、コードレビューを優先することで開発効率が改善したということと、その理由について考えてみました。
これからも意識してコードレビューを優先的に行っていきたいと思います。
その中でなにか新しい知見が得られたらまた追記したいと思います。