僕たちのPRレビューは意味があるのか

takarot
·

普段ソフトウェアの開発をする上でいろんな開発フローを耳にする。

そんな中、リリース前には「PullRequestを作り、他のメンバーがレビューし、approveされている事」というのはほぼ必ずと言っていいほど導入されているフローに思える。

これはなぜなのか?実は昨今の技術の進歩によって僕らがレビューをする必要はすでに無くなってるのではないか?

そんなことを思ったため、思いつく限りのPRレビューの役割とそれについて本当に必要なのかを考えてみる。

PRの目的とは?

不具合がないかを確認する目的

まず真っ先に思いつくのはここ。やはりリリースするものには誰しも不具合が含まれてほしくはない。

レビューという形でダブルチェックすることで、開発者が見落としている不具合が発見できる可能性がある。

不具合には二つの種類がある「意図通りシステムが動いてくれないこと」「パフォーマンスの悪化」

この二つの種類の不具合をレビューによって排除できるようにするためには、それぞれ条件があるように思う

「意図通りシステムが動いてくれないこと」

  • レビューするメンバーは開発の目的をしっかりと把握できていて、何が仕様で何が不具合かを正確にジャッジできること

  • レビューするメンバーは開発した部分以外の箇所で不具合が出ないか検知できること

これらは、システムテストを工夫することで、テストをレビューすれば良い状態にできそうである。

「パフォーマンスの悪化」

  • レビューするメンバーは効率の悪い処理が何が理解しており、より効率の良い処理方法を知っていること

これは個人のスキルに依存するので、スキルの高いメンバーがチームメンバーへ伝達することで少しずつ改善できそうである

品質を担保する目的

ソフトウェアの品質とは、何を指していて、なぜ品質を良くする必要があるのか?

  • コードが読みやすい(= そのコードが何をしているか把握しやすい)

  • 改修がしやすい(= コードを修正してもバグが発生しにくい)

これに関してはチームで品質の高いコードの定義ができていれば、それに則っているかをチェックするだけで済みそうである。

つまり

どうやら人が確認したほうがいいことはやはりありそうではある。

しかしながら、体制を整えたりツールを利用することで人は最低限のところだけを見れば、よくできそうではある。

  • テストを見て、目的が達成できるかを確認

  • コードを見て、アンチパターンがないか、決められた書き方になっているかを確認

まとめ

やはり「PullRequestを作り、他のメンバーがレビューし、approveされている事」は必要なフローでありそうだ。

しかしながらチームで議論したり適切なツールを利用することで、人が確認や選択をする負荷はだいぶ減らすことはできそうである。