Site cover image
新人エンジニアが手戻りのないPull Requestを作るコツ(Web開発)

Webの開発現場では、GitHubのPull Request (プルリクエスト、以下PR)でコードレビューが行われることが多いです。

新人エンジニアの人によくある躓きとしては、下記のようなものがあります。

  • PRを作ったのになかなかレビューしてもらえない…
  • コード以前に設計に対する指摘が入って作り直しになった…(手戻り)

このエントリでは、新人エンジニアが手戻りのないPRを作るためのコツを人気スマートフォンゲーム「クラッシュロワイヤル(クラロワ)」のクエスト機能を例に挙げて紹介します。

下記はクラロワのクエスト画面です。クエストは同時に最大3枠まであり、クリアすると翌日まで空になります。

1番上がデイリークエストで、時間経過で3つまで報酬がもらえます。下2枠はランダムで日によって求められるアクションが違います。

例えば画像赤枠の「カードを寄付」では、カードを120枚寄付するとクエスト達成になります。

Image in a image block
クラロワのクエスト画面

今回は運営向けの管理画面に、ユーザーのクエスト達成状況が確認できる画面を追加することを考えてみましょう。

開発するものが決まりました。さて、何から手をつけたら良いでしょうか?

新人エンジニアによくある躓きは次の3つです。

  1. 設計なしにいきなりコードを書き始めてしまう
  2. 全て完成してから巨大なPRにする
  3. PRの説明が不十分

すると、こんなことが起こります。

  1. 設計に問題があり大きく手戻りしてしまう
  2. 差分が多すぎてレビューが後回しにされてしまう
  3. レビュアーがPRの意図を理解できない

ひとつずつ説明していきます。

設計に問題があると最悪の場合、PRをクローズして作り直しになり大幅に時間をロスしてしまいます。

簡単な修正ならまだしも、新しい機能を追加するようなケースでは、必ずコードを書く前に設計し、レビューを受けましょう。

設計はエンジニアの大事な能力です。設計図を書かない建築士に家を建ててほしいとは思わないですよね?

「機能が全てできてからPRを出す」というルールはありません。意味のまとまりごとに分割してPRを出しましょう。

例えば今回のように画面追加なら、ロジックの実装だけのPRと、UIを追加するPRといった具合です。

大きな差分をレビューするためには、まとまった時間を確保しなければなりません。

レビュアーも他の仕事を持っているので、まとまった時間を確保するにはどうしても時間がかかります。

PRを早くマージしてもらうためには、まず第一にレビュアーの負担を減らすことを考えましょう。

あなたが開発しているものをレビュアーが熟知しているとは限りません。

あなたのPRを理解するために、あなたが理解するのにかけた時間と同じだけの時間をレビュアーに課していては、チームで働く意味がありませんよね?

レビュアーがPRを簡単に理解できるように説明する義務が、あなたにはあります。

設計資料をちゃんと作っているとここで役立ちます。

でも設計とは具体的に何をすれば良いのでしょう?次に説明します。

ゲーム内では「クエスト」という表記でも、コード上では全く想像もつかない名前かもしれません。

例えばDaily Dutyだとすると「なんのこっちゃ?」となりますよね。

そういうわけで最初に用語集を作りましょう。箇条書きで十分です。

用語を理解したところで、それぞれのデータ(DBテーブル)の関係をER図を描いて視覚的に説明しましょう。

ER図を描くにはMySQL Workbenchが便利です。

例えば次のようなER図が描けたとします。

Image in a image block
クエスト機能のER図

視覚的になっているとテーブル同士の関係が一目瞭然です。

ER図を書くと他にも「報酬のところがポリモーフィック関連になってるな」みたいなことがすぐにわかります。

データの関係がわかったところで、いよいよそれらをUI上でどう表現するか考えていきます。

一覧したいのは何か、表示する項目は何かをGoogleスライドなどを使って視覚的に説明します。

次のようなものです。

Image in a image block
クエスト達成状況確認画面のUI設計

こんな風に図を描くと「あれっ、進捗状況の最大値はどこから持ってくるんだっけ?」みたいなことに気付けます。

しかもGoogleスライドなら、共有リンクを送るだけで管理画面を使う人(運営スタッフ)との認識合わせにも使えるため一石二鳥です。

高速なチーム開発では、どうしてもコードレビューがボトルネックになりがちです。これは言い換えれば、わかりやすいPRを作ればレビュアーの負担が減りPRが早くマージされるということです。

2〜3回のレビューでパスすれば良いですが、設計に問題があると何往復もすることになります。このとき自分だけでなく、レビュアーの時間も使っているということを忘れてはいけません。

もちろん、仕事を覚えるまでは仕方がないことです。設計は素振りと同じで、繰り返しやることで上達します。

レビュアーの負担を減らし、チームで高いパフォーマンスを発揮できるよう、めんどくさがらずに設計に取り組みましょう。

以上です。

このエントリでは、新人エンジニアが手戻りのないPRを作るためのコツをクラロワのクエスト機能を例に挙げて紹介しました。


2020年9月26日 加筆修正

Thank you!
Thank you!
URLをコピーしました

コメントを送る

コメントはブログオーナーのみ閲覧できます