普段ソフトウェアの開発をする上でいろんな開発フローを耳にする。
そんな中、リリース前には「PullRequestを作り、他のメンバーがレビューし、approveされている事」というのはほぼ必ずと言っていいほど導入されているフローに思える。
これはなぜなのか？実は昨今の技術の進歩によって僕らがレビューをする必要はすでに無くなってるのではないか？
そんなことを思ったため、思いつく限りのPRレビューの役割とそれについて本当に必要なのかを考えてみる。
PRの目的とは？
不具合がないかを確認する目的
まず真っ先に思いつくのはここ。やはりリリースするものには誰しも不具合が含まれてほしくはない。
レビューという形でダブルチェックすることで、開発者が見落としている不具合が発見できる可能性がある。
不具合には二つの種類がある「意図通りシステムが動いてくれないこと」「パフォーマンスの悪化」
この二つの種類の不具合をレビューによって排除できるようにするためには、それぞれ条件があるように思う
「意図通りシステムが動いてくれないこと」
レビューするメンバーは開発の目的をしっかりと把握できていて、何が仕様で何が不具合かを正確にジャッジできること
レビューするメンバーは開発した部分以外の箇所で不具合が出ないか検知できること
これらは、システムテストを工夫することで、テストをレビューすれば良い状態にできそうである。
「パフォーマンスの悪化」
レビューするメンバーは効率の悪い処理が何が理解しており、より効率の良い処理方法を知っていること
これは個人のスキルに依存するので、スキルの高いメンバーがチームメンバーへ伝達することで少しずつ改善できそうである
品質を担保する目的
ソフトウェアの品質とは、何を指していて、なぜ品質を良くする必要があるのか？
コードが読みやすい（＝ そのコードが何をしているか把握しやすい）
改修がしやすい（＝ コードを修正してもバグが発生しにくい）
これに関してはチームで品質の高いコードの定義ができていれば、それに則っているかをチェックするだけで済みそうである。
つまり
どうやら人が確認したほうがいいことはやはりありそうではある。
しかしながら、体制を整えたりツールを利用することで人は最低限のところだけを見れば、よくできそうではある。
テストを見て、目的が達成できるかを確認
コードを見て、アンチパターンがないか、決められた書き方になっているかを確認
まとめ
やはり「PullRequestを作り、他のメンバーがレビューし、approveされている事」は必要なフローでありそうだ。
しかしながらチームで議論したり適切なツールを利用することで、人が確認や選択をする負荷はだいぶ減らすことはできそうである。