アルパカログ

プログラミングとエンジニアリングマネジメントがメインです。時々エモいのも書きます。

クラロワで学ぶ 新人エンジニアが手戻りのないPRを作る方法

学生の頃から開発経験はあるし、配属されて現場での開発も経験した。

なのに、PRがなかなかレビューしてもらえないしマージされない、なんなら設計に対する指摘が入って作り直し...なんてことありませんか?

4月に入社した新人エンジニアたちが、そろそろそんな悩みを抱えている頃かなぁと思います。

なぜPRが見てもらえなかったり、設計からやり直しになってしまうのでしょうか?

こういうところに気を付けると良いんじゃないでしょうか?というのを、クラロワのクエスト機能を題材に書いてみようと思います。

クラロワのクエスト機能

クラロワのクエスト画面は下記のようになっています。複雑なので、今回は赤枠部分だけを考えていきます。

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

簡単に説明しておくと、表示されているクエストは、メンバーにカードを120枚寄付するとクエスト達成となり、報酬としてレアカード20枚とクエストポイント20ポイントがもらえるというものです。

念のため断っておきますが、私はクラロワの1ファンであって、開発会社のsupercellとはなんの関係もありません。

いつかsupercellで働いてみたいとは思ってますけどね。

おっと、そういえば自己紹介を忘れていました。

私はCREという、カスタマーサポート向けに管理ツールを作ったり、不具合を調査したりするエンジニアのグループで働いています。

管理ツールってあまり馴染みのない方も多いと思いますが、表側とはまた違ったデータの表現が必要になるんです。

例えばゲームなんかだとプレイ履歴がそうで、いつプレイして、何を受け取ったのか、管理ツールならではのデータ表現やUI設計が必要になります。

今回は管理ツールに、ユーザー毎のクエスト履歴画面を追加することを考えていきます。

さて、何から手をつけましょうか?

え、もうコードを書き始めただって?

実はそれ、新人が陥りがちな傾向なんです。

新人エンジニアが陥りがちな傾向

新人エンジニアによく見られる陥りがちな傾向は次の3つです。

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

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

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

どうすれば良いのでしょうか?

1つずつ説明していきます。

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

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

ロスする時間と設計に費やす時間、どちらが大きいでしょうか?

どちらの方が建設的な進め方でしょうか?

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

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

PRは分割して出そう

「機能が全てできてからPRを出す」というルールはありません。

意味のまとまりごとに分割してPRを出しましょう。

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

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

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

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

視覚的にPRを説明する

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

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

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

設計資料をちゃんと作っていると、ここで役立つわけですね。

さっきから口うるさく設計、設計と言っていますが、具体的に何をすれば良いのでしょう?

コードを書き始める前にこれだけやっていればとりあえず大丈夫、というのを次に説明します。

その1: 用語集を作る

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

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

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

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

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

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

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

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

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

他にも、「報酬のところがポリモーフィック関連になっとるなー」みたいなことがすぐにわかります。*1

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

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

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

次のようなものです。

f:id:otoyo0122:20190707144026p:plain
エスト履歴のUI設計

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

しかも、共有リンクを送るだけで使う側の人との認識合わせにも使えるため、まさに一石二鳥なのです。

おわりに

高速なチーム開発では、どうしてもコードレビューがボトルネックになりがちです。

言い換えれば、わかりやすいPRを作ればレビュアーの負担が減りPRが早くマージされるということです。

2〜3回のレビューでパスすれば良いですが、設計に問題があると何往復もすることになります。

このとき、自分だけでなくレビュアーの時間も使っているということを忘れてはいけません。

もちろん、仕事を覚えるまでそうなってしまうのは仕方がないことです。

設計は素振りと同じで、繰り返しやることで上達します。

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

*1:ポリモーフィック関連なんぞや?という人は「失敗から学ぶRDBの正しい歩き方」を読もう。