コードをセルフレビューしてる？〜いまから実務を始める君へ〜

# はじめに
「自身のコードを振り返り、実装内容を言語化する習慣はありますか？」

「開発をするとき、動いたから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とは

:::note 
**作業途中**：**WIP**(**Work in Progress**)の意味で使う
:::

- コードの完成度はまだ高くないけれど、コードを見てもらいたい場合
- マージするためではなく、他のメンバーにフィードバックをもらいたい場合
- あらかじめPR作っておきたい場合

にして使うといいよ！！

その際は、『ココまでできてる』、『ココがわかっていない』を明確にすることを意識して使う！🙆

## Draft PR出すと何がいいか？

1. **思考の整理**：
    自分が実装したコードを言語化することで、作業ログやコメントを残せ、思考の整理になります。
2. **レビューの簡略化**：
    Draft PRを共有することで、レビュワーとコードを共有でき、PRを正式にオープンするまでにレビューが格段に楽になります。

## Draft PRの作り方

以下では、Draft PRの作り方を説明します。

**step1**

コードをpushをしたら、
![スクリーンショット 2023-07-20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885098/7b845666-3d89-5b1b-375c-5e9ecc67a6df.png)


`Compare　&　PullRequest`でPullRequestを作る画面へGo！！！
この画面で、PR作成！！！
![スクリーンショット 2023-07-20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885098/f7785d5c-4a9a-636f-1b76-c83e7d679eb0.png)

**step2**

`▽`から、`create draft pull request`を選択
![2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885098/329e445a-ea40-82a8-624f-d9849cba24b5.jpeg)

**step3**

`create draft pull request`を選択〜
![スクリーンショット 2023-07-20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885098/818d486b-57d0-fbbc-233d-7e721fe8298f.png)


**step4**

`draft`になっているか確認
このようになっていれば、Draft PRの作成成功！！！
![スクリーンショット 2023-07-20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885098/92b61b1e-dd57-8043-bcdd-faf0b58e0ad7.png)

## Draft PRをオープンにするには？

`Ready for review`ボタンでオープンになります！🙆
![スクリーンショット 2023-07-20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885098/3d880f04-f673-fda7-8331-b551affea324.png)


## Draft PRにもどすには？（Draft PRを間違ってオープンにしちゃった）

OpenにしたPRからDraft PRにもどすには。。。
![1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885098/4d3d915f-f8c3-85ca-49b1-e3c59e7ea73d.jpeg)
PRの右の`Reviewers`から変更できる

`Still in Progress?`の`Convert to draft`のボタンをクリック！！
![スクリーンショット 2023-07-20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885098/f5c3dbe0-e3b2-0b94-80cc-83654ea278c8.png)


`Convert to draft`のボタンをクリック！！
![スクリーンショット 2023-07-20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885098/6d3bd94f-6804-6909-296e-bfdee40bcd4d.png)

これでDraft PRになった！！！👌

## 自分のPRの出し方（ご参考程度に。。。）
    
このコマンド一発で済ませちゃいます！（効率化重視😏）

```
$ gh pr create -a "@me" --draft
```

**参考**　GitHub CLI

https://cli.github.com/manual/gh_pr_create

# 👍 セルフレビューについて

## セルフレビューとは

:::note
レビュワーにレビューを依頼する前に、**自分がPR出したコードを自身でレビュー**する
:::

## セルフレビューはどんなところを注意してやればいいの？

1. **どういう意図で実装したのか**：
   - このコードはこういう意図で書いた（何のための何をするコードか）
   - 作業ログやコメントを残せるため、思考の整理
   - 他者が見てもわかるか、わかりやすいコードか
2. **自信のない箇所**：
   - 自信がないコードは特に見てもらいたいとアピール！！！
3. **意図しない変更**：
   - タイポがないか
   - ログ（console.log）などを消し忘れていないか
4. **変数名と関数名について**：
   - 変数名や関数名を再確認し、違和感がないかをチェック！！！
5. **まだ未完成の作業**：
   - 完了していない作業を、別のPRで対応するのか
6. **最善の方法なのか**：
   - 自分が提供した解決策が最善と思えるものか

### **レビュアーへの配慮**

- **レビュアーが気になりそうなことはコメントしておく**

    なぜ必要なのか、なぜこれを使ったのか等、レビュアーが気になりそうなことは、PRにコメントしておく
    「この命名は、ここで使用されていたので、このような命名にしました」など

- **悩んでいることや質問があればコメントしておく**

    自分は最終的にこういう実装をしたいけど、本当にこれの実装でいいか悩む時、「他に良いやり方あったら意見いただきたいです」と、PRの該当箇所にコメントするといいよ〜👍

- **どんな聞かれ方だと回答しやすいのかを考えながら書いてみる**

    質問の仕方なども工夫できるといいですね！！

## セルフレビューすると何がいいか？

>30分ぐらいは追加で工数かかるんだけど、レビュワーの負荷を軽減しつつ、しょうもないミスは全て除去できるのでめちゃくちゃコスパいいんですよね。

https://twitter.com/engineer_ryoma/status/1671095869683425280

レビュワーのみならず、チーム全体に良い影響がありそう！！
そのぐらい大事！！！

## セルフレビューのお手本

参考になるかどうかわからないですが、セルフレビューの一部をどうぞ😏（あまり参考にならないかもw）

![スクリーンショット_2023-07-20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885098/39c0a33f-d3a2-5757-8304-4ee5d10b499a.png)
![スクリーンショット_2023-07-20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2885098/facc9e61-cbf5-fa60-ebc9-c7c2878b9ca5.png)

# おわりに

これで、セルフレビューやDraft PR使いこなせそうですか？

本当にちょっとしたことですが、セルフレビューはかなり大切ですよね！

チーム開発をする前に、少し知っておくだけでも、全然違うと思います！（自分も、まだまだですが、、、）🙄

エンジニアは、**チームで開発をしているので、他人（レビュワー）のことを考えてレビューしやすいようにPRを作るのも、一つの欠かせない技術ですよね。。。**

なるべく自身のコードを振り返り、言語化習慣をつけれるといいですね！💡

この記事が、実務に入る前の駆け出しエンジニアさんの参考になれば幸いです〜

# 参考

https://github.blog/jp/2019-02-19-introducing-draft-pull-requests/

https://developer.so-tech.co.jp/entry/2022/09/14/120000

最近セルフレビュー関連の記事を見たので、ちょうど参考にさせていただきました🙇　以下の記事です

https://qiita.com/matsuken314/items/45430995ae0fa8d34231