いてづきブログ

情シスでやってみたことの備忘録

コードレビューをボトルネック化させないタスクの進め方

普段開発を行っているときコードレビューをすると思います。

 

しかしコードレビューの指摘と修正が繰り返されいつまで経ってもマージできないということが往々にして発生します。
レビューに何を求めるかはチームや組織によってまちまちですが、少なくともレビューの遅延が原因でマージやリリースが遅れるような状況は健全ではありません。

 

自分が入ったチームで行って効果的だったのは、実際に手を動かす前にタスクを全員で見る時間を作ることです。
もう少し具体的には開発の方針を決めてしまうことです。設計と言ってもいいかもしれません。

 

チームで開発をしていると言ってる割にこれをやっていないチームは意外と多い印象です。
各エンジニアがそれぞれ領域を持っているけどレビューはやらないといけないのでレビューだけ他のエンジニアにしてもらう…とか。

 

 

設計をどのくらいまでやるかはチーム内のレベル感に寄ると思います。
新しく入った人がいたりルーキーみたいな人がいるときはスケルトン作るくらいまでやってもいいかもしれません。

というかレビューが爆発してるパターンのときは大抵の場合、よくわからないけどそれらしいものを作ってレビューに出してそこで初めて設計レベルの指摘をされてほぼ全作り直し…というようなパターンが多いので、チーム内でその領域に詳しい人と一緒に全部作るくらいのことを最初はやってもらうくらいでもいいと思っています。

 

年数とか関係なくその部分のことをがわからないならわかるようにして、全員の前提知識を増やしてあげることが大切です。