アルパカログ

Webエンジニア兼マネージャーがプログラミングやマネジメント、読んだ本のまとめを中心に書いてます。

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

f:id:otoyo0122:20200926180605p:plain:w300

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

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

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

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

題材:クエスト達成状況の確認画面

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

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

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

f:id:otoyo0122:20190707143829p:plain:h520
クラロワのクエスト画面

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

新人エンジニアによくある躓き

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

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

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

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

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

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

1. コードを書く前に設計レビューを受けよう

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

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

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

2. PRは分割して出そう

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

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

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

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

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

3. 視覚的にPRを説明する

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

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

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

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

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

設計その1:用語集を作る

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

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

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

設計その2:ER図を描いてデータの関係を視覚的に説明する

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

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

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

f:id:otoyo0122:20190707143941p:plain:w600
クエスト機能のER図

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

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

設計その3:UI設計もスライドなどで視覚的に表現する

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

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

次のようなものです。

f:id:otoyo0122:20190707144026p:plain:w600
クエスト達成状況確認画面のUI設計

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

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

おわりに

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

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

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

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

以上です。

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

参考になった方は、ぜひ「はてブ」やSNSでシェアしていただけると嬉しいです。

--

2020年9月26日 加筆修正