コードレビュー虎の巻 - Qiita

レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし

[hiro_curry]

「古くからの名著にリーダブルコードという書籍があります」リーダブルコードは最近の本だと思ってた・・・（プログラミング作法世代）

[atori07]

無言ブクマの嵐

[kei_0000]

「なにが最悪かを考え、それを防ぐための物からレビューをします」デメテルの法則、自分が理解した内容。あるクラスを作る→それを他の人が使う→他の人がそのクラスを使う為の知識が最小限になるように設計する

[slash_01]

レビューは結局、経験と勘と過去のやらかしの引き出しの数に頼ってたところあり、なにかしら文書化できないだろうかと思っていたところにちょうど良さげな記事発見。

[reitanigawa]

全部やってると工数が足りないのだが、価値観をチームで統一していく必要があるので、案件によって、部分強化していく。

[isrc]

レビュアーに出す前にそもそもテストしたい項目／実際に試したのか、証拠としてスクリーンショットを撮ること／デメテルの法則、YAGNI、DRY、KISS、GoFを意識して実装、レビューすることも大事です。

[naglfar]

テストで分かるバグはレビューでの指摘観点じゃないと思う。“以下に書く項目は（中略）レビュアーに出す前にそもそもテストしたい項目”って、どの項目のことか分からない。

[SundayIsEveryday]

組み込みソフトエンジニア的には、ユニットテスト、インテグラルテスト(コンポ、アーキ)の観点(≒アーキ、コンポ、ユニット設計レビューで押さえるべき観点)も混在しているように見える

[mas-higa]

"レビュアーに出す前にそもそもテストしたい" ちょっと何言ってるのか分からない

[yamadadadada2]

最近思うのはそもそもPRのサイズを小さくすべきだよなあ、と。そうなると回数が増えるとかまた別の課題はあるものの。/ペアプロもいいよね

[diveintounlimit]

こういうリストかつては作ってたけど、かなりレビュー時間かかっちゃうから結局勘所を見るようになったな。

[Bryntsalov]

長すぎかな

[polyamid]

プロジェクトメンバーによるレビュー、ピアレビューって言うんだ。勉強になった。

[ryuichi1208]

仕事してるアピールが必要なPJでコードレビューはイチャモンレベルでも必ず1つ以上は指摘する事って教えられたけどあまり納得出来なかった思い出🤔

[imash]

仕様、設計書の内容がちゃんと実装に落とし込まれてることみたいな確認観点が無さそうだけど別のレビューでやるのかな

[hokkey]

ビジュアルリグレッションテストのことが書いてあるのが良かった。すごく良さそうなツールなので試してみたい

[adwhing]

無言失礼

[miyakona38572]

“が発生しない”