Slide 7
Slide 7 text
似たコードがたくさんある場合にまとめられないか、DRYかどうか
railsのバージョンが古い場合とかにもコメントする
テストコードがないと気になる
Rubocopの指摘を対応させる
インデント・スペース・改行のレベルで違和感・統一感を指摘する
5行の変更のコードにコメント5個つくことある
あとで泣きを見そう、と感じたコードはapproveしない(経験上、こういうことをやるとあとで痛い目を見るんだよな、と嗅覚が働いたコードはapproveしない)
設計がいけてなかったらそもそもまで戻る
レビューが終わって無ければ本番にデプロイさせない
空行や変数名なども含めて、コードの全てに「なんとなく」がないか確認する
改行の意図もわからなかったら確認する
コードレビューしにくい読めないコードは途中でレビューやめてやり直してもらう
変数名、関数名はとことん拘る
レビュアーがパッと見て何をしようとしているコードなのか理解できる変数・メソッドのネーミングや設計・構造
1行1行に意志をもって何が起こるか理解できるコードになっているか
コメント書いたら負け(コードの説明)
思想についても(好み)としてコメントする
意図がわからないコードになっていたらメンテできないので妥協したくない
その処理はそこに書くのが正しいのか? (責務)
rubocop や formatter などにまかせられることは自動化して、レビューしたくない。
ソニックガーデンメンバーが考える「妥協しないコードレビュー」