最近少し悩む事がありました。掲題の通りなんですが、iOSアプリエンジニアとして仕事をしている中で「プロダクトを開発する」という事と「品質の高いコードを書く」という事が同時に存在するなと感じる事がありました。(コードレビューは何故するのかを話し出すと別記事になるぐらい話せると思うのでここでは一旦この定義としておきます。)
開発メンバーはPO(プロダクトオーナー、いなければマネージャーやディレクターで読み替えてもらえれば)、QA、その他のエンジニアが居る状況です。
仕事の流れとしてはコードを書き始め、ユーザーストーリーが満たせるなと思うタイミングまで来たらコードをコミットしてGithubでPull Requestを出します。
そうするとCIでビルドが始まって皆が触れるバイナリが生成されて動作確認を依頼します。
この流れはとても自然に見えますが、最近違和感を感じ始めました。

コードレビュー後に動作確認で仕様漏れが発覚した場合

　弊社の場合、エンジニアはほぼ常に席にいるのでコードレビューを依頼すると早い時には数分以内でApproveされる事があります。逆にPOは色んなMTG等に出ながら進捗を確認するので結構忙しく、CIでビルドしたものをインストールして動作確認するというのも中々手間なので時間ががっつり出来た時ぐらいしか確認が出来ないというギャップがあります。
そんな状態で動作確認してもらった後で仕様漏れ等で手戻りがあった場合、再度コードレビューを依頼しないといけなくなります。
僕がレビュワーの場合は多少手戻りがあってもレビューするのは全然構わないのですが、何度も依頼する場合は申し訳無さを感じる事があります。

動作確認後にPull Requestでコードの指摘があった場合

　逆のパターンになる事が少なかったのであまり気にした事が無かったんですが、先に動作確認を依頼して、受け入れてもらった後にPull Requestでコードの指摘が入った場合を考えてみました。Pull Requestでコードに指摘が入る場合、ユーザーへの挙動が変わる事は滅多に無いと思うんですよね。基本的にはスタイルや命名などの書き方や、既存資産があるからそっち使ってねとかそういう指摘が入る事が多いかと思うんですが、どれもユーザー影響はほぼ無いのでPOへの再度の動作確認はほぼ必要ない事が多いんですよね。そう思うとどちらもレビューの依頼なんですが、時間は掛かるが動作確認を先に済ませてからコードのレビューをしてもらった方が仕事をしていく上での手戻りは少ないなと感じる様になりました。コードレビューで指摘が入っても、修正した後で指摘をもらった人にレビューを依頼するので妙な気を遣う必要もありません。

皆がどうなのか気になったので聞いてみた

　Twitterでアンケートを取ってみた結果「PRが先」と「PRと動作確認を同時に出す」という結果が同列で多い事が分かりました。僕もこれまで同じ様な感じだったので納得の結果ではあります。ただ、先述した様にこれからは「POに動作確認をしてもらってからPRでコードレビューを依頼する」というのが仕事をする上では良いかもなと思う様になりました。

まとめ

　最近ではGithubにもWIP機能が提供されたので「Pull Requestは先に作るけどレビューはまだしないでいいよ」という状況が作れる様になったので仕事の内容が大幅に変わるわけではないですが、レビューを依頼する時に順番だけ気をつけるだけで業務効率も少し良くなるかもな？と思う様になりました。小さな事をダラダラと書き連ねてしまいましたがここまで読んで頂きありがとうございました。

P.S.

　今日たまたま誕生日なので干し芋のリストを置いておきますね