コードレビューにおけるレビュアー側のアンチパターン

tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に

[yug1224]

リーダブルコードのURLをぶん投げられるレビューを喰らった時、逆に自分の書き方の正しさを証明する章のURLをぶん投げてやった。そして始まる殺伐とした時間。優しさが足りない。

[NOV1975]

これはレビューの目的がレビューのみなのか、コーダーのレベルアップも含むかで大きく違う話には思えるけど、そのあたりをどの程度やるかは難しいところ。

[threetea0407]

ピアレビューはとてもいい文化なのでやっていくべき。偉い人のコードは誰もレビューしないってのは本当に良くない。

[karikari1255]

レビューの粒度が変わるのは仕方ない気もするけどなあ。設計レベルで問題があったらまずそこ直して、細かいとこは後から見るからってなるんじゃ

[joker1007]

意識高い系コメントは割とやるのだが、具体的な修正内容を細かく指示してしまうと自分で考えるタイミングを失うってのと、場合によってはレビュアーにめっちゃコストかかるので、方向性だけ示すに留める時もある。

[katzchang]

「対応方法」の方をまとめるとパターンにできるんだけどなー

[koheisg]

解決策はペアプロしかないな。

[otherworld]

“対象がひよこードで激しくピヨピヨを主張していると”

[kbn1053]

"ポエム記事は染みるように読めるためにはある程度のソウルジェムの汚れが必要です"この記事自体にもソウルジェムの汚れは必要、というメタい指摘

[love0hate]

4はマジであるなぁ。指摘力とコーディング力は別物。レビューの指摘は的確にできても、コーディングは遅かったりアンリーダブルだったりする。が、豊富な知識があるのは理解しているので、指摘しづらい的な。

[cuttoff19]

アッアッアッ

[skl0123]

“コードレビューはコミュ障なぼくらにとって、恒常的に発生するほぼ唯一のコミニケーションなので、大事に扱おう”

[TransRadio]

「コードレビューはコミュ障なぼくらにとって、恒常的に発生するほぼ唯一のコミニケーションなので、大事に扱おう」あと言い方と双方向性と、レビューとは別個に解決すべきことは別個に解決

[souvenir038]

ある程度の知識・経験が無いと上手いのが思いつかなったりするだけで、それなりにがんばって書いているので突き放すのは良くない。具体的な修正指示、できれば例示を出してあげる。

[braitom]

修正後に改めて見るとやっぱ他にも気になるところが出てくること良くあるんだよなあ。"最初のレビューと修正を何度も繰り返しながら、雪だるま式に修正のスコープと内容が肥大化していくパターン"

[dabits]

社内勉強会のネタにしてみると良さ気。

[iww]

レビューされる人をレビュイーっていうのか

[sigwyg]

HAHAHA →「時間がないのでこの修正はmasterブランチに直Pushして良いですか？」

[pmint]

1の意識高い系のは、実装できてから設計を指摘してどうするんだろう、とも思う。2のゴールが逃げるのは顧客（非技術者）がよくやるやつ。

[rAdio]

『初心者にあるべき論、つまりトップダウンからの思想的なフィードバックコメントをしても上手く成長しない』

[hiddy216]

思いやりを持ってレビューしたい

[luccafort]

めっちゃいい話しだこれ。

[kagerou_ts]

コードレビューの話だけど他のことにも当てはまるんやないかなあって思いながら読んでた。

[kithzmky]

コードレビュー アンチパターン

[amasho]

ふむ

[nokogiring]

要は言い方。 抽象から具体は大切だと思う。

[kamei_rio]

コードはかけるのに会話ができない人が結構いてとてもつらい、のはあるあるなのか

[suthio]

よくあるのがまとまっていて良い

[hi-hats]

この手の悩みはみんな同じなんだなあ

[zorio]

ややこしくなったらミーティングした方が良いと思う。地球の反対側にいるのでなければ。

[digo]

具体的な修正指示大事。あと、指示の理由や目的をちゃんと述べるのも大事。

[t-cyrill]

頭が痛い。現場がダメになる典型例だけど、なかなか気づかれないんだよね・・・

[umaemong]

「チーム開発が初めてレベルの新人さん」に「PRベースでのコードレビュー」ってのが相性悪そう。OJTするつもりなら対面のコミュニケーションが必要かと。対面がムリなら赤ペン先生並みの丁寧さが必要になっちゃう。

[Chisei]

ムービングゴールポストパターンわかる。これやられ続けると疲弊していくので他人にはやらないようにしている。

[endo_5501]

“ポエム記事は染みるように読めるためにはある程度のソウルジェムの汚れが必要です”

[mohno]

「こう直してね、理由はこれこれ」じゃないレビューは見たくないw　あと「tl;dr」って初めて知った^_^;

[june29]

独力で仕上げるのが難しいような内容なら、独力でがんばってからレビューに出すよりペアプロするなどした方がよさそう / ぼくは「レビュー」と「修正指示」は完全に別のものとして認識している

[takuver4]

そんな性格悪い人が世の中にはいるのか…。うちの会社は平和で良かった。

[to4iki]

“ムービングゴールポストパターン”