コードレビュー ありがちな問題への対処例 - Crieit

コードレビュー、これまでいろんなプロジェクトで経験して、意外と使われていないノウハウがあったり、風習が違ってつらみがあったりしたので、いろいろまとめてみる。 指摘事項について よくある話 - 駄目コードを憎んで人を憎まず。駄目なのはコードであって人格じゃない - 指摘する人は人格攻撃せずにコードのどこが悪いのかを指摘しましょう - 指摘される人も、言われているのはコードの問題であって人間の問題じゃないので、素直な心で受け止めよう この辺はみんな知ってると思うので略。ぼくが思う大事なルール コードレビューで指摘された内容は、対応必須ではない 理由： 対応必須にすると、「これ言ったらリリースできなくなるよね」みたいな忖度が発生してコメントできない人が出現するから。 絶対ダメとは言わないけど、あまりよくはない、みたいな指摘については、そのときは急ぐからリリースするけど、次回から気をつけるとかがあ

[cocoasynn]

最低限のレビューの質を保てる人が複数人いないような環境ではどうすればいいんだろう。自分の出した難しめなPRが無限にスルーされる様子にやるせなさしかない。

[everybodyelse]

コードレビューはゆるふわ運用が一番いいよね。

[otihateten3510]

コードレビューは8割の人には早すぎる。正直ほとんどの人はヒヨッコだと思う（俺も）。あと何で皆優先度使わないんだろうと疑問。／（コードディスカッションとかに名前変えたい）

[satmat]

レビューが超雑な人がいてどんなに改善を求めてもこの人がapproveするとあかん感じになってしまうので仕方なくレビュワーは2人以上必須というルールを設けたことがある

[satoryCats]

わかる。全員のApproveが必要ってなると一人でもダメだよってコメントがつくと心的ストレスで死ぬし、コメントが曖昧でもレビューイーが困って死ぬ。誰が責任持つの？を決めないと全員不幸になるよね

[ukayare]

ちょうど自分が先週社内資料用に書いた内容と被りまくってて笑った

[aflske]

そこでペアプロですよ

[shiopon01]

コードレビュー制度を設けるにあたって決めないといけない規則について、コメント付きで詳細に記載されている良記事だった

[igrep]

"「彼の合意だけでリリースするのはまずいのでもうひとり見てくれるまで待とう」というブレーキをかけることが出来る。逆に、「些細なPRなので彼一人でも良いだろ」という判断もできて、柔軟な対処が"

[katsuren]

政治的な組織作りと似てるなあ。票を集めてリリースOKにするとか普通にやるけど、記事になってるの見るとこれ民主主義じゃんってなった。

[maecchi]

巨大PR問題は分割もいいけど、説明会も知見の共有ができるという点で良いなとこの頃考えるようになりました。

[assaulter]

PR回ってないときはモブプロ的なのやって教育コスト払ってしまう手もあるかな(同意してもらうの大変だけど...

[endok]

PR文化が無いので羨ましさを感じつつ、SIの設計書レビュとかにも同じことを考えられるのかも。

[lyiase]

レビューはPR使うのが多いので、MUSTは「必ず」とか「必須」とかで表現するな。MAYについては「これが意図的ならば構わない」とか「構わない」と必ず入れることにしてる(もちろんMAYだけならApproveの状態にする)

[tune]

その通りだよねという印象。まとまっていてよい。

[trashtoy]

なるほど, 良いバランス感 “一人厳しすぎる人の指摘はスルーできるけど、みんなが駄目だと思うような項目はスルーできなくなる”

[s99e209]

コードレビューで指摘された内容は、対応必須ではない

[odmishien]

ユルフワ

[xKxAxKx]

現実としては🐤が多すぎたり、物理的に人が少ない場合もあるので、そこらへんで理想とどう擦り合わせて行くのかが結構むずい

[sigeharucom]

PR出した瞬間に自分でマージボタン押してる状況…。チームのメンバー減って一人になってしまったので。

[koogawa]

“マージボタンを押す人問題” これはみんなどうしてるのか気になる。今はレビュイーが押すルールにしてる

[dorokei]

あんまり複数人がレビューする環境にいなかったな。大体一人がみるし、彼が責任者だった。複数人レビューは一人マスターを置いて、その他はサブレビューみたいなもんでいいんじゃないか。

[masatomo-m]

Mergeボタン、うちはレビュアーが押す形式の方が主流。フラットな実力のチームと上級者・初級者が入り混じったチームで結構違いそう

[kei_0000]

コードレビューの自動化についても検討したい。おおよそ機械的にチェックできる箇所とそうでない箇所があるので。

[alt-native]

前いたプロジェクト レビュー皆無だった。プロトタイプで仕様承認。結合・総合レベルで初めて品質検査。バグが収束しなくて笑ってた。レビュー大事。

[jr6jr6]

うちのレビューはすぐき人格否定になりがち。だから怖くてレビューできない→それを人格否定するってのが繰り返されるから若手が成長しないし、潰れていく。

[chess-news]

面白いな。合議制なのか。

[kikikaikaikai]

>レビューアーは、「このPRがプロダクトにマージされて良い」と思えばapprove(👍)をつける。これが一定数集まったらリリースしてOK、というのが一般的なルール。 なるほど

[marshi]

うちは2つapproveついてたら誰がマージしてもいいルールだなー。ほんとは自動でもいいくらい。/自分のapproveでマージはまずいんじゃないかと思ってapproveできないときあったわ

[shikiarai]

ひよっこ問題きつい

[akulog]

とても難しいよね

[odakaho]

“そういう人がいるとみんな頼もしいし便利なんだけど、その人の負荷はとても高く、退職したり爆発四散してしまったりするとプロジェクトが一気にピンチに陥る”