もうすぐ産休をいただく志賀です

今回は、「設計ができるようになる！」という目標のもと取り組んでいる「todoレビュー」についてお伝えします。

当たり前のような内容ですが、何かお役に立てばと思います！

1. issueにアサインされる

（例）issue名「お問い合わせフォームの作成」

※開発部では、GitHubを使って開発をしています。

細かい仕様もコメントで共有してもらいます。わからないことがあれば随時issue上で確認をします。

2. todoを考え、書き出す

（例）

todo
  - FormTypeの作成
  - Twigテンプレートの作成
  - Controllerの作成
  - サービス定義
  - 動作検証

（PHPチームではSymfonyを使用しているためこんな感じになります。）

私はこの時、既存コードやテストを見たりしたりして追加するコードを整理しています。

似た機能が既にあれば、それを参考に考えることが多いです

3. todoレビュー依頼を出す

todoをレビュアーにレビューしてもらいます。

ここで、助言や意見があればコメントをもらいます。

4. 実装

okをもらったtodoに沿って、実際にコードを書いていきます。

todoリストのリスト単位（FormTypeの作成・テンプレートの作成…）でプルリクを出すと大きなプルリクになりにくいです。

メリット

• 設計(todo)と実装をきっちり分けることで、それぞれをじっくり考えて取り組める。
• 設計(todo)を言語化する機会が生まれるので、必然的に頭の中を整理ができる。
• あとで見返せて、振り返りができる。
• 答え合わせ感覚で設計(todo)の確認ができるので、モチベーションがあがる。
• 予想外の事が起こらない限りレビュー済みのtodo通りにコードを書いていくので、コードレビューでの手戻りは少なくなる。
• todoとして書き出すことで、設計だけでなくリリースまでに必要な作業系のやるべきことも明確にできる。
• todoを考える時に、どう設計したらいいかわからないなどの相談がしやすい。

デメリット

• レビューが2回(todoとコード)となるので、レビュアーの負担が大きくなる。

さいごに

上に挙げた通りレビュアーの負担が増えますが、確認が細かくできるのでコードレビュー時点での手戻りが減ったりとレビュアー・レビュイー双方のメリットが多いのでとってもいいと思います！！！