コードレビューの目的と考え方 - osa_k’s diary

まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを

[suneo3476z_tn]

ソースコードを論文に置き換えると分かりやすいと思う。誤字脱字を見つけるよりも、研究内容を平易明快に伝達できる書き方であるかのチェックを主目的とする作業。／追記：前段階のセルフレビューは言わずもがな。

[Pasta-K]

最高の文書だ / バグ探しが第一目的になるのは確かに違和感がある “コードレビューの主要な目的は、書いたコードの内容を他のチームメンバーに理解してもらうことである”

[tbpg]

“Code authorの書いたコードと自分のイメージが食い違っていた場合でも、書かれたコードのほうが劣る点を明確に指摘できないのであれば、Code authorの方針を尊重する”

[yatmsu]

ワイのapprove最低ラインではある “実装者の他に少なくとも一人、マージされたコードをメンテナンスできる人が存在するようにする。”

[ledsun]

20年前は単体テストよりコードインスペクションの方がバグを発見すると言われていたのに、自動テストの方がコードレビューよりバグを見つけるんだな（まあ、早く見つけるか）。

[love0hate]

Code authorがセルフレビューする (コメントも付ける) のもオススメ。というか自分はいつもしている。

[teramako]

書き手は自分以外のメンテナを増やす、読み手は自分もメンテするかもしれないという当事者意識を持つこと。書き手と読み手との間に上下意識が無くなり（実際には無いなんて事は無いけど）、心理障壁が下がりそう。

[degucho]

意思を持って書いたか？なんとなく書いて人に意図を説明できない箇所はないか？の確認作業

[vine_hate]

コードレビュー

[nikkie-ftnext]

from: https://shinkufencer.hateblo.jp/entry/2023/03/04/235800

[diveintounlimit]

いいはなし

[nilab]

コードレビューの目的と考え方 - osa_k’s diary

[t2wave]

参考文献がまとまっている

[mather314]

なんのためにレビューするのか目的意識を持ってレビューしよう

[braitom]

コードレビューの目的、コードレビュー時のチェックリスト、レビューを負担にしないような工夫、レビュワー向け/Code Author向けのアドバイスなどがまとめられている。

[castaneai]

“優先度の低い指摘はそれと分かるようにする。コメントの文頭に[nit]を付けるなど（nitはnitpickingの略で”

[raitu]

“今すぐに他人が読んで理解できないコードは、もちろん将来も理解されていないし、何なら書いた本人も3か月後には理解できなくなってしまう。そうなったコードは拡張することも難しい”

[hatest]

特殊な実装の場合はコメントでその理由書くとレビューしやすいし、レビュアからの無駄な質問が減るのでおすすめ。コードだけで会話するのが難しいときはコメントで会話

[ni_haru]

分かりやすく、バランス良く丁寧にまとまってる

[kairusyu]

良い

[onesplat]

リファクタと機能実装を分けるべきというのはその通りだが、レビューが遅いと面倒なんだよね。何故レビューが遅くなるかというと…という悪循環。だから「レビュアーは最速でレビューせよ」というのも加えて欲しい

[taguch1]

いいね。大まかなところは事前のコミュニケーション、ツール等、ペアプロで合意して出来るだけレビューのコストを下げたい。

[iavivai]

大変良かった

[TriQ]

良い記事

[yokoyantech]

プルリク見るときの方針としたい

[gorokumi]

コードレビューに限らないけどレビューについては森崎修司さんが色々研究されてて 易しい解説多い。例えば古めだけど https://www.atmarkit.co.jp/ait/spv/1403/25/news007.html

[strow0343]

まとまっていると思う。ただ単に詳しそうな人をレビュアーに選ぶと負荷が集中するので分散の仕組みが欲しいところ

[nonaka1007]

コードレビューは数学の証明問題のようなもの

[a_bicky]

超良い

[stealthinu]

『コードレビューの主要な目的は書いたコードの内容を他のチームメンバーに理解してもらうこと』今までコードレビューについて間違った認識だった。不具合がないか確認作業という意識だった。

[otihateten3510]

目的多いと難しくならない？

[ytRino]

新しい話ではないが散々言われてきていることの整理として良き

[cad-san]

コードレビューと呼ばれるものに、設計レビューに属するものと、インスペクション（Code Completeより）に属するものがあって、これは前者の話で、後者は割とがっつり時間をとる必要がある。

[ayakohiroe]

“コードへのコメントはあなたへの攻撃を意図してはいない”受け取り方にもよるがたしかに。

[ktanaka117]

良かった。

[Twintaro]

いいですね。このチェックリストを、毎回レビューする前に見るようにするといいかも。