この記事ではスケルトンレビューと呼んでいる

一般的な呼称ではなさそう

具体的な実装をする前に、方針のみを示した状態でCode Reviewする

ガチガチに実装した後に、「全然ちゃいます。0からやり直し！」になるのを防ぐ

方針の伝え方には色々ありそう

図を書く

viewならComponentの分割の図とか

model付近ならER図とか

要は、構造をreviewするということだろう

実装対象について、どういう風にmoduleを切りましたか？

そのmoduleのinterfaceはどの様になっていますか？

といったことを共有できていればひとまず良い

他のメンバーは、その部品の利用者となるので、

それを利用して他の機能を実装できるならひとまずそれで良い

実装の詳細をレビューする必要は今の段階ではない

実装の詳細部分で問題がある場合も、上記の考え方を範囲を狭めて適用すれば良い

そして、仮に実装の詳細に問題があったとしても、moduleの外部には影響しない

だから、どうでも良いっちゃ良い

ただ、そのメンバーのレベル感によって、任せるmoduleの大きさは変わってくるだろう

例えば、Reactの入門者なら、小さい1つのComponentに対して同様のことを行えば良いし、

玄人メンバがいるなら、大きめのState Machineのinterfaceに対して適用すれば良い

詳細の方針は基本的にその人に任せる

実装の詳細部分は、reviewするモチベーションがないのでちゃんとしたレビューができない

参考

元々あった問題

PR大きすぎると、レビュー大変

PR小さすぎると、個々は良いが、全体で見るとおかしい

解決策

1つの「方針段階PR」に対して、複数の「具体的な実装PR」を出している

実装の方針を適当なフォーマットに沿ってメモ書きする

これやるならScrapboxみたいな同時編集できるツールを使ったほうが良さそう

あるいは普通にPRに書けば良いのでは。編集履歴も残るし