長くなりがちだったコードレビューを改善した話 - 弁護士ドットコム株式会社 Creators’ blog

弁護士ドットコム クラウドサイン事業本部でエンジニアをしている山田です。 主にフロントエンドを担当しています。 普段の業務でフロントエンド開発のコードレビューをすることが多く、今回は長い時間がかかりがちだったコードレビューを以下の施策で改善した話をします。 タスクへの認識合わせを拡充 タスクを小さく分割 類似するタスクのレビュー内容は共有 必要に応じて同期的にレビュー 達成されないスプリントゴール スプリントゴールが達成できない原因 コードレビューが長くなる要因 レビュアーのレビュー期間が長い タスク担当による対応期間が長い 対応策 タスクについての認識合わせの時間を設ける タスクをなるべく小さくする 類似する複数のタスクはレビュー内容を共有 必要に応じてオンラインミーティングなどで画面共有し会話しながら同期的にレビューする スプリントゴールも達成できるように まとめ 達成されないスプリン

[J138]

「プルリクを小さくして、レビューを手早くする」これだけを言うためにこんな長い文章書いちゃう（文化？）が原因なんじゃないかな / 抽象的な話では、詳細なコンテキストは徹底的に省くべき

[nakag0711]

これ、細かいタスクに分割するやりかたが正しい保証がないのでは。実際コード見てみたらこのやり方じゃなんか変だけどそうチケット作られたからその通り作るみたいなことにならないならいいけども。あと裁量の余地が

[shogochiba]

成る程ーーー。👍👍👍✋😺👨😊

[sa-yama321]

ペアレビューをおすすめするよ。

[bosatsumiroku]

鈍重なJTCにありがちなセレモニー的な問題解決手法を、テックカンパニーでの日々のスクラムの課題解決に当てはめるのって、相性最悪な気がする。

[Bryntsalov]

このPRを細かくするの最近よく聞くけど、木を見て森を見ずにしてるだけなきがするんだよね。

[jksy]

細かすぎて大きな流れわからなくない？ コーダーとして頼んでるならいいけどさ

[ucue]

それよりも、ちゃんと検索で事例が見つかるようにしろよ。

[kjin]

無慈悲な…。結果いいんだけど、より効率的にできんだろ、とか他人に渡すの可能なもの判定て何で判断してるのかそのコスト含めメリット上回りそうとかの根拠を伝えてくれると嬉しい“レビュアーが忙しい問題は効率

[sigwyg]

重い腰が上がらない問題がやっぱ一番でかいので、レビュワー呼んでMtgするのは（同期的になっちゃうけど）やっぱ良いと思った。事前にモブプロ/ペアプロする方法もあり