時間対価値の高いコードレビュー - Hello Tech

CTOの杉本です。 「コードレビューが忙しくて開発の時間がとれない」というのは、ある程度役割が広がったエンジニアからよく上がる不満だと思います。 コードレビューはチーム開発で重要な活動ではありますが、「コードレビューで使う時間に対してどれだけの価値を出せるかを意識できていない」ことが原因の一つにあることが多い、と僕は思っています。 僕自身も立場上日々のコードレビューの負担が重く、うまく開発が進まないと感じていた時期がありました。時間対価値を意識して思い切ってやり方を変えてからは、コードレビューの負担の重さを感じることは少なくなりました。 今回は、僕個人が運用しているコードレビューへの考え方について書きます。 コードレビューの目的 そもそもコードレビューは何のためにやるのでしょうか？ 僕が思うに、コードレビューの目的は「品質担保」と「開発者の成長」です。 最低限のコード品質・リリース品質を担

[umai_bow]

個人的には成長目的のレビューのラリーは反対派で、育成ならペアプロしたほうがいいと思ってる

[sigwyg]

“この話には前提として、「開発者の技術レベルが十分に高く、自律して技術的な問題解決ができる」ことがあります。幸いなことに、今いるメンバーは技術力が高く自走できる人が多いため” 解散！

[monorod]

解決策は掲示しないってのはあんまり同意できないなあ。特に複数の解決案がある場合。レビューってのは対話だし、直して欲しいとお願いするわけだから、どうして欲しいのかちゃんと言うのはマナーじゃない？

[shingo-sasaki-0529]

なかなか見かけない強い思想のレビュースタンスだ。部分的には参考になりつつも、自分はどうしても具体案まで提示したり、imo/nits も書いちゃうな。前者はともかく、後者はリンターやAIレビュー強化して無くしたい

[marshi]

解決策を提示しない、がレビュアーの中にある正解を言うまで終われません、じゃないのであればいいかな。それを当てるゲームは不毛すぎるので。

[youko03]

動作、仕様、アーキテクチャレベルでの指摘はさておき、コーディングルールにない書き方に関する細かい指摘は、Approveのブロッカーにしてほしくないかも。

[onesplat]

視野が狭い

[ss49919201]

とても良い。レビュワーの負担が減り、レビュイーの成長機会は増える。

[gachakku0131]

ほぼ納得できる内容だった。補足にある前提についても

[threetea0407]

同意できるところもあるけど、納期と成長の兼ね合いは難しい問題だと思った

[diveintounlimit]

モヤっとする内容だった。半分くらいはわかるが。

[tg30yen]

>コードレビューは所詮1対1のコミュニケーションのため、レバレッジもあまり効きません。丁寧すぎるコードレビューをするよりは、ドキュメントなどに時間を使うほうが効率的です。

[bz0]

『問題の指摘をする、解決策は提示しない』『期待値調整と関係値構築で軽減できる』この部分難しい気がする

[syou6162]

半分くらい同意で半分くらいはうーーーん悩ましい

[Sixeight]

相手と自分の成長の意味で考えや癖も共有したいのでとにかく気になったところや理解したこともコメントするようにして、コメントであるとか直さなくて良いと書いてる。相手の認知負荷の問題は確かになあ。

[hello_shimoda]

タメになった