WWW無人速報

コードレビューってどうやるの？ Gitなしでもできる？

なしでもレビューはできるよ でもGitの方が圧倒的に楽

>>41 Gitなしだとどうやるの？

>>51 メールでコード送ったりとか 口頭で説明したり 昔ながらのやり方

>>56 メールは見落としそう あとコードの差分も分かりづらいな

>>65 そういう問題があるからGitが主流になったんだよね

基本的な流れはこんな感じ - コードを書く - レビュー依頼する - レビュアーがコードをチェックして指摘事項をコメント - 指摘を修正 - 修正が問題なければマージ

>>14 レビュー依頼はプルリクエストでやるのが一般的だね

>>23 そうそう GitHubとかのプルリクエスト機能を使うと便利

>>14 レビュアーはどうやって決めてる？

>>75 チームリーダーとか 詳しい人に頼むのが無難かな

毎回同じ人にレビュー頼むのもしんどいよな

>>81 みんなでレビューし合うのがいいよね お互いの成長にもつながる

新人もレビューした方がいいの？

>>89 新人の視点は重要だよ わからないことを素直に聞けるのは新人の特権

>>99 確かにベテランだと 「常識だろ」って思っちゃうこともあるもんね

レビューのときって何をチェックすればいい？

>>107 まずは仕様通りに動くかだね バグがないかとか

>>117 それとコードの可読性とかも大事だよね

>>126 ああ変数名がわかりにくいとか ロジックが読みづらいとかね

>>133 あとはチーム内のコーディング規約に沿ってるかもチェックするといいよ

>>139 コーディング規約か 命名ルールとかコメントの書き方とかかな

>>148 そうそう 規約があればみんなコードの書き方が統一されるからね

>>107 パフォーマンスとかセキュリティもレビューで見た方がいいよね

>>160 パフォーマンスはボトルネックになりそうな部分をチェックするといいね

>>165 でも完璧を求めすぎるとレビューが終わらなくなるから程々に

>>170 そうだね 重要な部分に絞ってレビューするのが良さそう

セキュリティはインジェクション脆弱性とかチェックするのが鉄板だね

>>180 認証周りのロジックとかも見落としがちだから気をつけないとね

指摘事項ってどうやって伝えるのがいいんだろ

>>189 プルリクのコメント欄に書くのが一番楽

>>193 コード中の指摘したい行にコメントできるのが便利だよね

>>189 口頭で伝えるのもアリだけど 記録に残らないのが難点

>>201 口頭だと伝言ゲームみたいになって 意図が正確に伝わらなそう

>>203 レビューは文書で残して 口頭では補足説明するのがいいかもね

指摘の書き方も大事だよね 上から目線だと萎縮しちゃう

>>220 そうだね ダメ出しじゃなくて一緒に改善していく姿勢が大事

>>221 「こうした方がもっといいコードになるよ」って言い方がいいよね

>>224 あとはよくできてる部分は褒めるのも忘れずに

褒められると次も頑張ろうって思えるもんな