# レビューまでに行うべきテスト範囲の共通化

- MALのコードは複雑に絡み合っているのでテスト範囲は大きな課題となるが、工数は限られるため機能単位でレビューを行っていければ、テスト範囲を小さくでき負担の軽減になると思われる。
ただ、ブランチ単体でのテストが難しい場合もあるので、そこはレビュアー、レビュイーともにプルリクにきちんと明記して、マージ後に確認する等柔軟に行っていく。
- 以下の動作に影響がありそうな場合は、パターンが増えてしまうが必ず確認を行いたい。
- ログイン・ログアウト状態の動作
- VPNアクセスでの動作
- フレンド・非フレンドでの動作
- PC、SPレイアウトでの動作

# Branch戦略

- 粒度
- CluckUPをサブタスクに切る。
- サブタスクの粒度についてのレビューは切った人の裁量に任せる。
- レビューや精査はチームリーダーが行う。
- TODO サブタスクに切る観点、指針を決める。
- Git Flowで良いか？
- 懸念点、現状はdevelopは無いので無理に作る必要があるか？
- Release branchの形骸化しやすいが、そこはどうするべきか？
- ネーミングルール
- ディレクトリーはGit Flow準拠
- Issueが無いので、ClickUP!を貼るのでも良いが、ClickUP!のstatus変更を忘れてしまうので、そことをなんとかしたい。
- ClickUP!のインテグレーションをGitHubに紐付けることを徹底する。
- UpdateやFixという英文のブレから直したいので、コーディング規約のようなルールを決めたい。


# レビュアーは誰がアサインされ何をするべきか

- アサインメンバーは現在ほぼ同チーム内となっているが、チームを横断してリクエストが出せれば理想。
- とはいえ、実作業をお願いすることになるので、なかなか頼みづらい状況ではある。
- 誰がどこを得意としているかが分かると、比較的お願いしやすい状況が作れるか。
- 大人数でレビューを行ったから品質があがるとは限らないので、例えば必要に応じて別チームから1人レビュアーをアサインさせてもらう。
- アサインメンバーは、チームリーダーに選定してもらってアサインさせてもらう等が考えられる。
- アサインされたメンバーは適材と考えられるので、経験や知識を元に品質を担保できるようなレビューをしてもらえることを期待したい。（とはいえ、皆さんお忙しいのでまずはお試しから始めましょう）
- プルリクに記載されたテスト内容に抜けが無いかや、経験上のロジック指摘、処理負荷等の確認をしてもらえることが重要。
- また、開発主体のチームでグループレビューを行ってみることも検討する。（とりとめなくならないよう、1時間などと時間を決めてはみ出さないよう注意する）

# レビューアサイン方法の草案

- Reviewersは必ず指定する。
- エンジニアがCluckUP起票しているなら、その人を指定する。
- チームリーダーとか安易な指定ではなく、この人にレビューしてほしいという観点で指定する。
- 緊急性を要するもので事前確認ができているものは無指定でも良い。
- SlackなどでReviewersにメンションを行う。
- メンションした理由も追記することが望ましい。
- Asigneesは指定することが望ましい。
- 他チームの人を1人選ぶのが推奨する。

# Pull Requestタイトル

- 概要を1行で表せる感じで書きましょう。
- ブランチ名を記載するのは推奨しない。
- 緊急リリース時は、その限りではない。

# Pull Requestの内容

- 概要（必須）
- 1行で書けることを目指す。
- 複数行でもかまわない。
- CluckUPがあれば、それも書きましょう。
- やったこと（必須）
- 概要の補足情報を書きましょう。
- やらないこと
- CluckUPには記載あるが、保留にしていることをここで書きましょう。
- 無ければ項目無しで良い。
- できるようになること（必須）
- この機能がなくなり、この機能に変わりましたなどを書きましょう。
- できなくなること
- 無ければ項目無しで良い。
- 動作確認（エビデンス）（必須）
- 確認手順の記載する。
- スクショでエビデンスを貼り付ける。
- CluckUPに貼り付けるのでも良い。
- 緊急性があるときは無くても良い。
- 備考
- 無ければ項目無しで良い。

- Pull Requests用のテンプレートを作成する。

.github/PULL_REQUEST_TEMPLATE.md

# フィードバック

- フィードバックを通して品質向上を目指す方向性を書きましょう。
- 命令調では書かず、質問で書きましょう。
- 「変更しないでください」ではなく「この変更はどう思いますか？」と書きます。
- 中立な意見はネガティブにバイアスされることを注意して書きましょう。
- 変更要求するなら理由も書きましょう。
- 個人的に嫌いな書き方（日を表す変数は$dateじゃなくて$dayが良いなど）でも理由を書く。
- Defineについては、PHP8から小文字も判別するようになったので指摘しますとか、理由を書く。
- より良い提案があるなら、コードを提供するぐらいの感じで書きます。
- 謙虚に努めましょう。
- 👍絵文字を使いましょう。

フィードバックで参考にしたもの

[https://github.blog/2015-01-21-how-to-write-the-perfect-pull-request/](https://github.blog/2015-01-21-how-to-write-the-perfect-pull-request/)

# オマケ
- リリース時には、このTシャツを着る。