# セルフレビューはどこまで確認しようか
今回は日記として、セルフレビューはどこまでって議題で書いてみよう。

## セルフレビューって:question:
チーム開発の場合、開発したソースコードは Git などを利用して管理します。開発した内容は、レビューチェックを別の担当者にお願いして、基本的にはクロスチェックの体制にしてチームで管理されます。責任はみんなで負う。

担当者Aさんが開発して、Gitで共有して、レビュー者Bさんにチェックしてもらう感じ。

で、その前に自分自身で「この内容でレビュー依頼して良いよな」ってチェックするのがセルフレビュー。あまりにも当たり前のチーム内のルールや、すぐ検知できるミスは自分で検出した方が良いよね、という視点でセルフレビューをするものです。

## レビューって具体的にどんな感じ:question:
Git を利用したものを具体的に見ると分かりやすいので、ここでは GROWI の OSS で利用している GitHub （Git を利用した Webサービス）上で管理しているソースコードを見てみましょう。

Git と GitHub の違いについてはまた別の機会に記事化だな。。

- [/開発日記/GitとGitHubの違い](https://tips.weseek.co.jp/5e417dcadecd0a0049953ad7) として`早速記事執筆`してもらいました。


GROWI は OSS なので、引用で参照します。コーディングの修正でレビュー依頼する単位である Pull request （プルリクエスト、略してプルリクって読んだりする）を見てみましょう。

https://github.com/weseek/growi/pull/623/files

パッと見て、「あ、これくらいチョロっと変えるくらいなんだ」という規模の修正もあります。

レビューの前提として、プロジェクトの知識が担当者より豊富な方にレビューしてもらうのがチーム開発の基本なので、このくらいの規模だと目視で指摘や間違いなどを検出してもらえます。

レビューする側も、このくらいの規模だと指摘漏れとかせず品質チェックできます。

## デカいレビュー:man_student:
さて今度はちょっと大きめの規模のコーディングの依頼

https://github.com/weseek/growi/pull/611/files

さて、パッと見るとどうでしょうか。

レビューというと、機能がちゃんと開発できているかどうかというポイント以外にも、`目を皿にしてプログラミングの１文字１文字を見る` というチェックになることもあります。:eye:

あんまり行数が多いと、レビューする側の担当者もツライという事になります。

こういう時は、「この部分は前提としてこうだから、このレビュー依頼（PR、プルリクエスト）ではこの視点でチェックしよう」と、ある程度レビュー観点を絞ってチェックするのが一般的です。

## レビュー者の負担について:expressionless:
この時に結構重要になってくるのが、「担当者Aさんはこのへんはちゃんと自分で確認済みだよな」というところ。

レビュー者Bさんがレビューする観点が少なく出来る品質を、担当者Aさんが確保できているかどうか。これが開発現場では結構仕事の重い軽いを左右する重要ポイント。

もし担当者Aさんが、セルフレビューでいろいろな観点を几帳面にチェック済みで、レビュー者Bさんがかるーくチェックするくらいで済むのなら、プルリクエストでレビュー依頼するソースコード行数は大きくても良いと思う。

問題は、レビュー者Bさんが「あ、担当者Aさん、このプロジェクトのこのルール守ってないじゃん」みたいな要素がいっぱいNG状態になっているとき。

こういう時は、レビュー者は指摘をいっぱいすることになり、指摘対応する担当者Aも「うわ、指摘多すぎ」ってなって、双方が不幸になり仕事の進捗が悪くなりがち。

## じゃぁ結局どこまでセルフレビューするものなの:question:
プロジェクトでは、レビュー依頼する単位(GitHub では PR）の規模を小さ目にすることを意識して、レビューして欲しいポイントとバランスを考慮するのが大事。

具体的に「〇〇行以上のレビュー依頼はしないこと」とか、「セルフレビューのチェックポイントとして、このチェックリストの内容を全てを自分でチェックすること」とかすると、今度はスピードが損なわれる。

人に見てもらわないと検知できない間違いもいっぱいあるので、あんまり時間かけてレビュー依頼を躊躇するのも良くない。

結論として、なにごともほどほどにというところかな。

---

## Page Navigation

- Canonical URL: https://tips.weseek.co.jp/開発日記/セルフレビューはどこまで確認しようか
- Permalink: https://tips.weseek.co.jp/5e3d2adfcff797004b16abbe
- Parent: [開発日記](/5e3d294bcff797004b16abba.md)
- Children: 0 total
- Total descendants: 0
- Siblings: 20 total
  - [GROWIのAPIを使用したアプリケーション](/5e5bd0e3e7f8db0048df3a08.md)
  - [GitとGitHubの違い](/5e417dcadecd0a0049953ad7.md)
  - [LDAP攻略への道](/5e48b2561ec5e4004811d4e9.md)
  - [Migrationsファイルを作成する](/5e9d1dc7b682620049e55a64.md)
  - [QiitaでGROWIが設計書システムとして紹介されました](/5e535a04eb17ce0048b9fb13.md)
  - [UserManagement](/65069da24603e7ff39a6b3d2.md)
  - [aタグ以外での画面遷移](/5e9cfd51b682620049e55a5d.md)
  - [jestを使ったテストを初実装しました](/5ef1ed225eea4b004a1912b2.md)
  - [npm とyarn の違いを簡単に説明](/5e3e6822591d7f0048b3cc5e.md)
  - [react-card-flipを使って回転するカードレイアウトを作る](/5ebaa05ad3055000488bd526.md)
  - [throttleでスクロールイベントを間引く](/5e8de43931511b0048ecf612.md)
  - [vuepressのテンプレート内で二重波括弧をエスケープ](/5f16ecf4c2f6150048b2955b.md)
  - [なぜsetStateをComponentDidMountで使用してはいけないのか](/5eb7728458c8ea00480d0825.md)
  - [アジャイルとウォーターフォール](/5e4137d343c1c400499b6bac.md)
  - [ソート機能の実装](/5e8aadc15245e70048c22c7c.md)
  - [タスクを円滑にこなすために必要な垂れ流しとは](/5e47a18a927c020048448a18.md)
  - [ページ内リンクの実装](/5e93c9d511007300489677ff.md)
  - [レビュー依頼する際に確認すること](/5e3ae41225751e00499297f6.md)
  - [動作確認用にページをたくさん作りたい](/5f80326633588b0048eaf865.md)
  - [間違えてマージしてさらにプッシュしちゃった](/5e9d176db682620049e55a60.md)
- Last updated: 2020-02-12T06:58:32.902Z by deleted_at_1731496442448
- Full page listing (all children regardless of count): https://tips.weseek.co.jp/_api/v3/page-listing/children?id=5e3d2adfcff797004b16abbe