はじめに
「自身のコードを振り返り、実装内容を言語化する習慣はありますか？」
「開発をするとき、動いたからOKと思い、急いでPRを出していませんか？」
また、「コードを書いて要件を満たしているからと、そのまま先輩エンジニアに丸投げレビューを依頼してませんか？」
それは、チーム内の開発コミュニュケーションとして良くないよーーーー
個人開発や、なんちゃってチーム開発（ハッカソン）しかしてきていない私は、セルフレビューの存在や大切さを全く知りませんでした。🥹
この記事では、Draft Pull Requestと、セルフレビューはどういうものかやその大切さを教えます！！！
以下では、Pull RequestをPRと省略します。
対象読者
- 長期インターン前に急いでGitHubの復習をしているエンジニア
- チームに入る前や入りたての駆け出しエンジニア
- セルフレビューが苦手な若手エンジニア
まずは自分の体験から
インターン先のとある開発にて
私 「業務終わりだし、自信ないけど、とりあえず進捗この辺だとわかるようなPRでもだしとくか。」
「PR出しました！ 自信がないので、Draft PRのままですが、お手隙の際に、確認お願いいたします！（slack）」💪
～次の日～
上司「nakampnayさんのPR見ましたが。。。。。。」
私 「はにゃ？！」🤔
上司「Draft PRだと作業途中の意味で、見て欲しい場合『どこまでできてる、ここがわかっていない』を書いて、、、」
私 「はにゃ？！」😥
上司「あとは、セルフレビューも大切で、自身でPR上にコメントを書いて、、、」
私 「はにゃ？！はにゃ？！」😰
上司「上記の点を明確にした上で投げていただけるとレビュワーもその観点で見れるので助かります！」
私 「え、そうなの、知らなかった、、、今まで丸投げしてきた」😨
～その後～
私 「Draft PRってそういう意味で使うの？！セルフレビューめちゃ大事やん……。」💡
というやりとりがありました。
この指摘をしていただけなかったら、
他人を気配れない（セルフレビューをせずレビュワーに全振りする）、
間違った知識を持ってる（Draft PRを使いこなせていない）大勘違い野郎のままでしたw
上司は優しく指摘してくださいましたが、開発現場に入る前に（インターン前に）、Draft PRとセルフレビューについて知っておくとスムーズに開発できると思うので、以下ではこの内容を詳細に説明します！🙆
👍 Draft PR（Draft Pull Request）について
Draft PRとは
作業途中：WIP(Work in Progress)の意味で使う
- コードの完成度はまだ高くないけれど、コードを見てもらいたい場合
- マージするためではなく、他のメンバーにフィードバックをもらいたい場合
- あらかじめPR作っておきたい場合
にして使うといいよ！！
その際は、『ココまでできてる』、『ココがわかっていない』を明確にすることを意識して使う！🙆
Draft PR出すと何がいいか？
-
思考の整理：
自分が実装したコードを言語化することで、作業ログやコメントを残せ、思考の整理になります。 -
レビューの簡略化：
Draft PRを共有することで、レビュワーとコードを共有でき、PRを正式にオープンするまでにレビューが格段に楽になります。
Draft PRの作り方
以下では、Draft PRの作り方を説明します。
step1
コードをpushをしたら、
Compare & PullRequestでPullRequestを作る画面へGo！！！
この画面で、PR作成！！！
step2
▽から、create draft pull requestを選択
step3
create draft pull requestを選択〜
step4
draftになっているか確認
このようになっていれば、Draft PRの作成成功！！！
Draft PRをオープンにするには？
Ready for reviewボタンでオープンになります！🙆
Draft PRにもどすには？（Draft PRを間違ってオープンにしちゃった）
OpenにしたPRからDraft PRにもどすには。。。
PRの右のReviewersから変更できる
Still in Progress?のConvert to draftのボタンをクリック！！
Convert to draftのボタンをクリック！！
これでDraft PRになった！！！👌
自分のPRの出し方（ご参考程度に。。。）
このコマンド一発で済ませちゃいます！（効率化重視😏）
$ gh pr create -a "@me" --draft
参考 GitHub CLI
👍 セルフレビューについて
セルフレビューとは
レビュワーにレビューを依頼する前に、自分がPR出したコードを自身でレビューする
セルフレビューはどんなところを注意してやればいいの？
-
どういう意図で実装したのか：
- このコードはこういう意図で書いた（何のための何をするコードか）
- 作業ログやコメントを残せるため、思考の整理
- 他者が見てもわかるか、わかりやすいコードか
-
自信のない箇所：
- 自信がないコードは特に見てもらいたいとアピール！！！
-
意図しない変更：
- タイポがないか
- ログ（console.log）などを消し忘れていないか
-
変数名と関数名について：
- 変数名や関数名を再確認し、違和感がないかをチェック！！！
-
まだ未完成の作業：
- 完了していない作業を、別のPRで対応するのか
-
最善の方法なのか：
- 自分が提供した解決策が最善と思えるものか
レビュアーへの配慮
-
レビュアーが気になりそうなことはコメントしておく
なぜ必要なのか、なぜこれを使ったのか等、レビュアーが気になりそうなことは、PRにコメントしておく
「この命名は、ここで使用されていたので、このような命名にしました」など -
悩んでいることや質問があればコメントしておく
自分は最終的にこういう実装をしたいけど、本当にこれの実装でいいか悩む時、「他に良いやり方あったら意見いただきたいです」と、PRの該当箇所にコメントするといいよ〜👍
-
どんな聞かれ方だと回答しやすいのかを考えながら書いてみる
質問の仕方なども工夫できるといいですね！！
セルフレビューすると何がいいか？
30分ぐらいは追加で工数かかるんだけど、レビュワーの負荷を軽減しつつ、しょうもないミスは全て除去できるのでめちゃくちゃコスパいいんですよね。
レビュワーのみならず、チーム全体に良い影響がありそう！！
そのぐらい大事！！！
セルフレビューのお手本
参考になるかどうかわからないですが、セルフレビューの一部をどうぞ😏（あまり参考にならないかもw）
おわりに
これで、セルフレビューやDraft PR使いこなせそうですか？
本当にちょっとしたことですが、セルフレビューはかなり大切ですよね！
チーム開発をする前に、少し知っておくだけでも、全然違うと思います！（自分も、まだまだですが、、、）🙄
エンジニアは、チームで開発をしているので、他人（レビュワー）のことを考えてレビューしやすいようにPRを作るのも、一つの欠かせない技術ですよね。。。
なるべく自身のコードを振り返り、言語化習慣をつけれるといいですね！💡
この記事が、実務に入る前の駆け出しエンジニアさんの参考になれば幸いです〜
参考
最近セルフレビュー関連の記事を見たので、ちょうど参考にさせていただきました🙇 以下の記事です