Webエンジニアとして働いていると、新規機能の設計レビューや実装レビューをすることがよくありますよね。エンジニアなら当たり前のようにやっている業務です。
ですが、「よくよく考えてみると設計レビューや実装レビューの方法をしっかり時間を使って学んだことってないなぁ...。」という方も意外と多いのでは。
ぼく自身どうやってレビューしてるっけな？と振り返ってみると、「なんとなくコードを読んで、仕様漏れがないか、考慮漏れでバグになるケースがないかをチェックしている」くらい。
普段Webエンジニアとして働いている方の中でも、自分の中でしっかりとレビューの方法を確立できていない方も多いのではと思います。
今回は、Webエンジニアが設計やコードのレビューをするときに意識しておきたいこと、エンジニア初期のころに知っておきたかったレビューの方法と考え方をまとめました。
よりよいレビューの方法と考え方を知っておくことで、レビューをするときに役立てることができるし、レビューをお願いするときにもレビュー者の視点でレビューされやすいコード・依頼方法を心がけることができるので、一度はしっかりと学んでおきたいですよね。
レビューに関してしっかり学んだことがない方にとって、少しでも参考になれば幸いです。
Webエンジニアが行うレビューとは何をするもの？
そもそも、Webエンジニアがおこなうレビューとは何をするものなのか。
ひとくちにレビューといっても、様々な種類があることがわかりますね。
ぼくはこれまで2社の事業会社でエンジニアとして働いてきましたが、業務ではピアレビューしかしたことがないと思います。
Webエンジニアがレビューを行う際に気をつけること
Webエンジニアがレビューを行う際に何に気をつけるべきなのかがよくまとまっています。
レビューを行う前に、だいたいの仕様と設計方針、実装の方針はレビュー担当者と合意を取っておくこと。
そうすることで、あとから根底から覆されるようなレビューをされて手戻りが発生することが少なくなるというのは激しく同意しますね。
これはレビュー担当者も、レビューをお願いする側も意識しておきたい。
ソニックガーデンの西見 公宏（@mah_lab）さんのスライド。
レビューにおいて大事にしたい考え方が簡潔にまとまっています。Webエンジニア初期の頃は毎月読みたいくらい有益なスライド。
- レビュー前の観点を明確にすること。
- わが身に返ることを恐れずに指摘すること。
- なぜ悪いコードなのかを論理的に説明すること。
- いいコードについて共通認識を持つこと。
- 小さい単位でレビューを繰り返すこと。
スライド中で指摘されている、↑これらの点について開発チームで合意が取れていれば、よりよいコードレビューが相互に行われて、いい開発チームになるのではないでしょうか。
特に、「いいコードについての共通認識を持つこと」が重要だなと思っていて、開発チームでモブプログラミングやペアプログラミングをする時間をとって、一つの機能を例にとって、いいコードの設計とはどのようなものか？を議論しながら実装を進めていくとチーム間の合意が取れてよいです。
もしも、いい設計・いいコードの認識がチーム内で共有できていない状態で、新規メンバーが独自に実装すると、レビュー担当者が期待していたものとは全く異なるコードがあがってきて、期待値のズレによって強めのレビューが行われてしまい、レビューを受けた側に精神的な打撃を与えてしまうことがあります。
チームとしてよい設計、よい実装方法の合意を取らないままに実装を進めてしまうと、実装レビューの嵐になってしまう可能性があり、レビューする側は意図していなくても指摘の多さとそれによる言葉遣いの配慮の省略によってレビューを受ける側は精神的打撃を受けてしまう可能性がある。
そのPull Requestでもらうコメントを見ると死にたくなってくる。特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。
↑この話とか、実はあるあるだと思います。
その会社のコードに詳しくなり、エンジニアとして経験を積めば積むほど「これくらいできるでしょ...？」の期待値が上がっていくはずなので、新人や新規にチーム配属された経験の浅いメンバーに対して、期待値とあがってきたコードのギャップに驚き、強く当たってしまうことがある。
レビュー担当者もレビューを受ける側も気持ちよく働けるためにも、チームでよい設計・コードの合意をとる時間を定期的につくっておきたいですね。それによって、言語化されていない仕様やコーディング規約について新規のメンバーが理解できて、その後のチーム全体の生産性が上がるので。
ペアプログラミングのメリットとやり方に関しては、Yahoo!の事例のこちらの記事がめちゃくちゃ参考になります。
設計レビューのよくあるアンチパターンとそれを防ぐための方法に関して頭にいれておきたいという方は、こちらの本を読んでみるとよいです。
設計レビューでよくある失敗から、その失敗を防ぐために何をすればいいのか具体的な例をもとに開設されているので、業務でいきる知識が学べます。
レビューで初歩的な指摘をされないために気をつけること
開発チームとして、どのような設計・コードがいいのか合意をとるためにペアプログラミングやモブプログラミングをするといいと書きましたが、とはいっても最低限「よい設計とは？よいコードとは？」に関して自分の中で仮説を持っていないエンジニアは、いつまでたってもよい設計・よい実装をすることができるようになりません。
原理原則としてどんな考え方をして設計をすればいいのか、どんなアンチパターンがあるのかを理解していないと、個別具体の事例を見て「よいコードとは？」と議論してもその状況によって最適なコードを考える力がつかないはずなので。
最低限、「いい設計とは？いいコードとは？」の考えを持つ上で読んでおきたい本を3冊紹介しておきます。
可読性の高いコードとは？を知れる：『リーダブルコード』
エンジニア1年目に多くのWebエンジニアが読むであろう本のうちの一冊『リーダブルコード』。
エンジニアの仕事の大半はソースコードに費やされることから、いかに読みやすいコードを書くか？が大事だという観点から、読みやすいコードの実例が満載になっているので、可読性の高いコードとはどんなコードなのか？に関して自分なりの考えが持てていない方はぜひとも読んで欲しい本ですね。
負債となりやすいコードとは？を知れる：『レガシーコード改善ガイド』
仕事でコードを書く場合、そのコードが数年間、もしかしたら十年以上運用され続ける可能性もありますよね。その寿命の長いコードが長期的にみて変更しづらい・処理が追いづらい（読みづらい）コードになってしまわないようにするにはどうすればいいのか？を具体的なコードの例とともに学べる『レガシーコード改善ガイド』。
この本は、プロダクト初期のコードを書くエンジニアにも、長期的に運用されていて負債がたまってきているプロダクトでコードを書くエンジニアにも読んでみて欲しい一冊ですね。
よく使われる実装パターンを学べる：『Java言語で学ぶデザインパターン入門』
コードを書いていく上で、どのような設計にするのか、そのよくある設計パターンをまとめたGoFのデザインパターン23種類がJava言語ではどのように実装されるのかが紹介されている良書『Java言語で学ぶデザインパターン入門』。
デザインパターンは言語によらないプログラミングの基礎知識で、いい設計とは？を考える上で議論の前提となる知識なので、ぜひともパターンの内容を頭にいれておきたいですね。
これら3冊を読んでおけば、「いい設計とは？いいコードとは？」の議論をチームでしたときに、自分なりの考えを表明していい設計・コードへの理解を深めることができると思います。
まとめ
以上、「よいレビューの方法とは？全エンジニアがレビュー前に知っておきたいことまとめ」でした。
エンジニアとして働くなら避けては通れないレビューに関して、基本的なこととして知っておきたいことをまとめてみました。
自分がレビューをする立場としても、レビューをお願いする立場としても、一度しっかりとレビューのアンチパターンと、それを防ぐ方法、いい設計・いいコードとは？を学んでおくことで、その後のレビューの質と速度は格段によくなるはずです。
今回紹介した内容に関連して、エンジニアとして働き始めた初期の頃に知っておきたかったことをまとめています。こちらの記事もぜひ読んでみてください。
では。
