こんにちは。 コベリンの @numa08 です。
コベリンには3人のエンジニア (@numa08, @mironal, @ryohey) がいて、動いているプロジェクトがいくつかあり、うち複数人で回しているものが4つあります。
内訳は
- iOS/Android版feather
- 新期開発中の自社サービス
- 新規開発中の受託サービス
となっています。
それぞれのプロジェクトでは Pull Request を通してコードや進捗の共有、品質の向上を目指しています。
しかし、多くのプロジェクトがそうであるように、 Pull Request を軸にした開発フローでしかも人数が少ないとなると「待ち時間の発生」というボトルネックが生まれます。
「待ち時間の発生」に対するアプローチはチーム毎に様々な方法があると思います。「様々な方法がある」ことを認めた上で「ケース・バイ・ケース」で判断するという方向に舵を切ってしまうと、どうするべきかの判断の基準が人によって異なったり、また決断をすることによってメンバーにストレスがかかることが懸念されます。
そこで、プロジェクト毎にどう言った方法が適切なのか、どうするのがベストなのかを調査し、話し合い、「Pull Request のレビューを行うのか」あるいは「行わないのか」を定めたルールを試験導入することにしました。
今回は、試験導入することになった方式を紹介します。
レビューをやるのか/やらないのか
iOS版/Android版 feather の場合
- コードレビューをやるもの
- 全てのソースコードの変更
- コードレビューをやらないもの
- 依存ライブラリのアップデート
- typo の修正
twitter 非公式クライアントの feather は Android版はリリースをしてからそろそろ1年、 iOS版は2年以上経ちます。いずれもソースコードの量も多く、変更が及ぼす影響はどうしても大きい物になってしまう可能性を秘めています。
そのため、コードの変更を行った場合は Pull Request の作成とレビューの実施を絶対に行う物としました。ただし、依存しているライブラリのバージョンを上げるだけの変更や typo を修正するだけの場合は Pull Request を作るものの、コードレビューの依頼はせず、変更者本人によるマージの後、 slack などを利用して変更を行った事をメンバーに通知します。
また、 Clashlytics を利用しているので、依存ライブラリのバージョン変更による見た目や挙動の変更確認はコードを見なくてもベータ版を誰かにインストールしてもらうことで確認可能です。
そういった理由から「基本的にコードレビューは行うものの、小規模な修正と考えられるライブラリのアップデートや typo の修正はレビューは行わず、マージ後に周知をする」としました。
新規開発中の自社サービス
- コードレビューをやるもの
- 変更者の主観で「不安だ」と感じた物
- コードレビューをやらないもの
- 全部
現段階でリリースをされていない新期開発中サービスについては、レビューを実施することよりも速く開発をしてリリースをすることを優先したいと考えています。ただし、その前提として、 Issue を利用して設計をいつも以上に詰めることや、他のサービスと連携をする I/O 部分について変更が必要となった場合はメンバー全員に周知をすることとします。
そのため、「基本的にコードレビューは行わないが、設計については細かく共有し変更の通知をすぐに行い、早期のリリースを目指す」としました。
新規開発中の受託サービス
- コードレビューをやるもの
- 不安なもの
- コードレビューをやらないもの
- 全部
こちらも未だリリースされていないサービスのゼロからの開発のため、自社サービスと同じ仕組を導入します。また、実は開発がスタートしてから1ヶ月近く経ちますがこの方式で問題は出ていません。 Issue を利用した情報共有や設計の共有が行われているからだと考えられます。
まとめ
コベリン社内でコードレビューの実施を行うかどうかのルールを決定し、試験導入することにしました。こういった大切なルールはやはり昔ながらの「紙に印刷して眼につくところへ貼り付ける」が有効だと思うので、早速印刷をして貼り付けました。
今後、この試みがうまく言っているかどうかを検証する必要があります。開発効率の向上を検証することは難しいといえますが、幸いにもコベリンではイテレーションを作ってベロシティを計測する手法が確立しているため、それによる計測が行えるはずです。
「Pull Request を作ってコードレビューを行いマージをする」という、 開発フローは一見メリットが多いようにも思えますが必ずしも全てのプロジェクトについて万能であるとは言えません。我々は常に今までの当たり前を見直すことが求められていると言えますね。
なお、この試みを行った結果についてもブログで紹介をする予定ですので、しばらくお待ち下さい。
