こんにちは、運営者のハックです！
Javaコース上級編の卒業制作課題のフィードバックを受けている最中なのですが、修正箇所のプルリクエストを作成した際に、プルリクエストの作成方法について色々学習したことがあるので、今回は上級編Day15として記事を作成しました。
レビュー依頼後にコードの修正が必要になりました
前回仕上げたマインクラフトのミニゲームのレビューを依頼したところ、デイトラメンター方のアドバイスを元にコードの修正を行うことになりました。
修正箇所はコードの整形や、Javadocとコードの間の空行を削除、リテラルの定数化など、大まかな変更はありませんでしたので、具体的なコードの紹介は省略します。
コードを修正し、GitHubにプルリクエスト（以下PRと表記）を作成することになったのですが、その際にプルリクエストの作成方法について学習したので紹介します。
レビューしにくいPRとしやすいPRの違いとは何か？
引用：GitHub
ところで、このＰＲのタイトルを見てください。これ、どう思いますか？
すごく…分かりづらいのにゃ！
「Modify2」って、これじゃあ具体的に何の修正なのか分からないのにゃ。
画像のとおりPR文のタイトルを付けたところ、この記載方法は良くないとアドバイスをいただきました。そこで、レビューしやすくなるような良いPR文とダメなPR文の違いについて紹介します。
学習するにあたり、こちらのはてなブログ様の記事を参考にしました。
レビューしにくいダメなPRの特徴は「意味不明」
引用：hydrakecat’s blog「レビューしてもらいやすいPRの書き方」
画像のように、ダメなPRは「タイトルが意味不明」「なぜ変更したのか不明」「何を変更しているのか分からない」など、パッと見て意味不明な文章となっています。
また、修正した差分を少なくするように気を付けます。バグ修正、リファクタリング、コードフォーマットなど複数の目的が一つのPRに混ざってしまうとレビューが困難になります。
もし自分がレビュー担当者で、相手からこのようなPR文が送られてきたら…画面をそっ閉じして見なかったことにしますね。
ハックがメンターさん相手にやったことなのにゃ！？
自分がされて嫌なことは相手にしないって小学校で学ばなかったのかにゃ？
GitHubについて理解を深め、以後気を付けます…
引用：GitHub
コミットメッセージについても、どの点について修正したのか適切な表現にする必要があります。
画像のように「修正版です」というメッセージでは、「何の修正なのか」不明です。
レビューしやすいPRの特徴は「パッと見て内容が明確」
レビューしやすいPRはつぎのような特徴があります。
引用：hydrakecat’s blog「レビューしてもらいやすいPRの書き方」
- 変更の目的が説明されている（対応するissueが書いてある）
- 変更内容が説明されている
- 差分が小さい
- 確認手順が書いてある
凄く見やすくなったのにゃ！
これなら、パッと見ただけでも変更内容が頭に入ってくるのにゃ。
この特徴を元にPRタイトルと中の文章を作成し直した結果、以下のようになりました。
修正前
引用：GitHub
修正後
引用：GitHub
- タイトルで「何の変更なのか」が分かるように訂正
- 変更内容を箇条書きにし、「変更による仕様変化」の項目を追加
参考様サイトのように綺麗に書けてないけど、少しはマシになったかにゃ。
落第点ではないって感じでしょうか。
現場に出る前にGitとGitHubの使い方について、もっと慣れておく必要がありますね。
おまけ READMEに差し入れる動画も作成していました。
前回作成したREADMEに、課題の要件を満たしているか判断できるデモ動画の作成も行っていました。
課題の要件である以下の項目を満たしているか分かるように撮影しました。
- コマンドを実行によりゲームモードに切り替え
- 鉱石の種類によりスコアが変化する
- 採掘した時点でスコアが加算される
- スコアはDBに登録される
- スコアはリストとして確認できる
- 制限時間が設定されていること
また、以下の独自要素も分かるように撮影しています。
- ゲーム開始時と制限時間がタイトルコールされる
- 採掘時に鉱石の種類と点数がメッセージに表示される
- 同種鉱石連続採掘ボーナスが発生する
- 特定時間経過を知らせるアナウンスがある
こちらが作成した動画です。
早送りになってるし、画質もあまり良くなくて見にくいのにゃ…
GitHubのREADMEに添付できる動画サイズは10MB以内なので、早送りで動画の再生時間を短くし、動画ファイル容量圧縮サイトを使用して10MB以内にしました。
初めてゲーム動画撮影＆動画編集を行ったので簡単な編集のやり方すら分からず、かなりの時間がかかった割には動画の質も低いです。
まさに四苦八苦しましたが、いい経験になったと思っています。
まとめ 現場に出る前にGitとGitHubに慣れておく
今回は卒業制作でレビュー依頼中に修正したコードのプルリクエストを作成した際に学習した、良いプルリクエストの作成方法について紹介しました。
レビューが終了し、卒業課題が完全に完了したらJavaコース上級編の最後の記事を投稿します。
今回の記事で行ったようなダメなプルリクエスト作成を現場で行っていたら、叱られるを通り越して仕事を任せていただけない事態になるところでした。
転職して現場に出る以上、年齢の若い新人さんと同じようではいけません。
今のうちにGitとGitHubに慣れるように、Gitを学べる書籍も購入しました。
書籍についてはそのうちブログ記事で紹介するかもしれません。
以上で今回の学習記録を終えます。
ここまでご覧いただきありがとうございました。
コメント