良いコードレビューとは

コードレビューする時、自分がどんなことに気を付けているか (本当は気をつけたいか)みたいなポイントをまとめてみた。 コードレビューの目的 プロダクトの品質を担保するため 人は基本的にミスをするもの 1人で考えたものより、2人、3人集まって考えたものの方が良いことが多い 知識をチーム内でシェアするため チームでコードに関する知識を常に共有し続けることで、「この機能はAさんしか知らない」といった属人化問題を防ぐ Aさんが有休取った時に限って障害が起きたりするんですよね。分かります 他の人が書いたコードを読み、さらに分からないことは質問できる、素晴らしい学びの場だと捉える 責任をチーム内でシェアするため 何か問題が起きた時に関連するコードを書いた人間だけが責められるようなことは決してあってはならない レビュー時 (又はそのコードがデプロイされるまで)に問題に気づけなかったチーム全体の責任なので、

[turanukimaru]

コードレビューは「今オレが読んで解らないものは来年のお前も解らない」の一点だけでやってる。デグレってそうなときは「テストケース〇〇のときの挙動の正解は私にも解らないからPOに確認して」。実際解らないし。

[razihai]

最近めちゃくちゃPRのレビューしてるのだが、「デグレがないか」まーじでここが関門すぎる。最近はもうその後のテストで拾えるように、であまり見過ぎないようにしてるが日々精進って感じ。

[yuuAn]

コードレビューは何ではないというのを決めておくのも大事で、例えばコードレビューはバグがないことを保証するためのものではない。

[bz0]

しっかり見ようとすると時間かかりすぎる問題ある。意図した通り動くかとコードの良し悪しは分離したい、どこまで許容するかラインをはっきりさせたいが言語化が難しい

[ducktoon]

心から尊敬し合っている関係でないと難しいと思うわ

[stabucky]

非システムの人間からすると、勉強は時間外にやって、納期は死守してくれ、と思う。

[korilog]

バグとかデグレは基本的にテストとか書いた人が自分で動作確認したりQAで担保するものだと思う。たまたま見つかったらありがたいぐらいの気持ち。

[electrolite]

Cで始めるならいったんEに行ってAmで少し落としてからGかDで盛り上げる感じかな、途中で7thを入れて微妙なニュアンスを表現しても良いし、分数コードで繋げても良いよ、ってそんな話じゃなかった。

[toteri]

バグ、デグレはテストで拾えば良いと思ってる。コードレビューで拾うのはカロリー高い

[daaaaaai]

はい

[mumei-0]

“良いと思った点は積極的に褒める”

[a96neko]

見てる

[syu-m-5151]

良いコードレビューは良いフィードバック仕草を考える。

[hocopi]

レビュー投げる側として参考になった

[cive]

悪いコードレビュー「動くからヨシッ」

[otihateten3510]

わい「よし！」しか言わない

[tendanku]

目的の3つについて、本当に品質が上がる？ 知識をシェアしても覚えてる？レビューしてなかったら責任一人に負わせるの？とか実はレビューで解決するべき問題ではないってこともある

[Shinwiki]

具体的な修正案は示さずに何度もつっ返して、進捗に遅れが生じたらなぜなぜ分析させるんでしたっけ。

[cvtbgspuda]

デグレに関してはないことテストで確認してから投げてもらうようにしてる。じゃないと話が進まない。

[shoh8]

どこまで見るか、信頼するかはレビュー外の活動も多分に関係する

[nanana_nine]

指摘をしすぎない、自分が神だと思わない

[diveintounlimit]

よい

[ch1248]

よいですね

[xlc]

一人で作っていて品質の高いものもあるので、レビューとはヘタクソのデタラメを正す教育の場と心得た方がよいと思う。ヘタクソ同士でレビューするのは時間の無駄だし品質も上がらんよ。

[xKxAxKx]

極めて「そのとおりですね」としか言いようがない。デグレがないか、をどこまで拾えるかは本当に難しい。

[shunt_i]

“コードレビューする時、どんなことに気を付けてるか (本当は気をつけたいか)みたいなポイントをまとめてみた”