コミュニケーションが雑すぎて会社員に向いてない

毎日が楽でみんな笑顔なら良い。よく寝て美味しいものが食べられたら幸せだ。責任は持ちたくないし持たせたくない。

ソースコードレビューの際に気をつけること(備忘録)

コードレビューどうやるんだっけ?

プログラミングのレベルは大して上がっていないんですが
業務上ではプログラミングをするよりコードレビューをする場面が多くなってしまいました。
それにあたって、自分なりに判断基準をもってソースコードレビューを行うために本記事にまとめる。

ポイント

  • プロダクトのバグを減らすのと保守性向上のために行う
  • 開発者、レビュアーともにプロダクトの仕様理解につながる
  • チェックリストを用いて漏れなく迷いなくレビューを行う

ソースコードレビューはなぜやるか?

レビューに関わるのは開発者とレビュアーになります。
レビュー後にプロダクトはどうなるかと登場人物の行動を考えてみる。

開発者

  • レビュー指摘を持ってソースコードを修正する
  • 仕様の知識が増える
  • コードの知識が増える
  • 効率の良い処理の記述方法を知る

レビュアー

  • プロダクトの仕様がわかる

プロダクトはどうなる?

  • ロジックのミスが少なくなりバグが減る
  • ソースコードの可読性が高まり追加開発の際に効率がよくなる

レビューで辛いこと

現時点でレビューでの辛みを考えてみた。
今回の記事はレビュアーとして視点だけれども
両者からの観点でつらみを考えてみる。

開発者観点

  • PRの説明を書くのがめんどくさい
  • レビューをもらうのが怖い

レビュアー観点

  • 開発者の意図がわからない
  • そもそも仕様理解も必要
  • 辛いレビューをするのが大変
  • そもそも自分がそんなに知識がない → わたし

ソースコードレビューでのチェックリスト

これは開発者とレビュアーが両方使えるチェックリストになる。
PRとDIFF(ソースコードの差分)ごとに用意した。
これを漏れなくチェックすればソースコードレビュー漏れはないかもしれない。
少なくともレビュー時にチェックリストを思い出す脳内メモリが節約できる。
チェックリストが埋まらない部分があればすぐ聞くことである。

PR

  1. 説明文で仕様がわかるようになっている
  2. PRのタイトルと説明文が一致している
  3. UI変更がある場合にスクリーンショットもしくは動画が記されている
  4. 設計思想がわかるようになっている

DIFF

  1. 変数名に誤植がない(名詞、動詞のスペルミスはないか)
  2. コメントに誤植はない
  3. インデントに誤りがない
  4. プロダクト全体の設計パターンから大幅にずれていない
  5. 既存のライブラリの再開発を行っていない
  6. 冗長な処理を記述していない
  7. 共通のオブジェクトを用いている場合、オブジェクトの中身が保証されている
  8. 処理の順番が実現したいことに大して等しい

参考資料

コードレビューの際に気をつけること - Qiita