レビューの心得
はじめに
IT業界にはコードレビューという文化があります。プログラマーやシステムエンジニアにはお馴染みのものでしょう。しかし、実際にコードレビューをすると、思うように上手くできないものです。特に新人の内は勝手が分からないのでしょう。そこでコードレビューの気をつけるべきポイントをご紹介します。
目的
コードレビューのコミュニケーションを円滑に行えるようにする。
内容
コードレビューを円滑に行うポイントは以下の3点だけです。
- レビューを事前に意識して準備しておく
- 伝える相手や内容によって伝え方を変える
- 説明の流れをイメージしておく
さっそく、見ていきましょう。
レビューを事前に意識して準備しておく
レビューを円滑に進めるには、実はコードを書くときからその準備を意識しておく必要があります。何故ならば我々が納品するものは、お客様にお出しする成果物だからです。当然、自分が作ったものが「どういうもの」なのか説明できなければなりません。同時に説明をするには、具体的な流れをイメージできてなければなりません。レビューのみならず、質問をする時にも役立ってくるはずです。
そのため、以下の点は
- 自分が作るものが「どういうもの」なのか説明できる
- 具体的な説明の流れをイメージできている
コードを書くときから意識しておいてください。
これが意識できるとコードもスムーズに書けてしまったりするものです。
レビューはコードを書くときから始まっているのです。
伝える相手や内容によって伝え方を変える
コードレビューの多くの場合は、プログラマーやシステムエンジニアが主体です。しかし、開発に関わる関係者の全てが技術者なわけではありません。場合によっては、営業マンやクライアントが参加することもあります。そのため、伝える相手や内容によって伝え方を変える必要があることを意識しましょう。
①コードを書く時や質問する場合
コードを書く時や質問する時は、「TO DO（どのように）」の伝え方をしましょう。
技術者の関心の多くは、「WHY（なぜ、なんのために）」ではありません。ビジネスロジックと呼ばれる「TO DO（どのように）」に関心があるのです。細かいコードの説明や質問などの場面では、「TO DO（どのように）」を意識して伝えるようにしましょう。
②レビュー時やエンジニア以外に説明する場合
レビュー時やエンジニア以外に説明する時は、「WHY（なぜ、なんのために）」の伝え方をしましょう。
エンジニア以外の人の関心の多くは、「WHY（なぜ、なんのために）」にあります。大袈裟に言えば、動きさえすれば「TO DO（どのように）」なんて気にしないのです。聞いても分からない話を延々とされるのは苦痛です。せっかくの説明の機会なのに話を聞いてもらえなくなってしまうかもしれません。
また、レビュアーを担当するエンジニアも「WHY（なぜ、なんのために）」から確認をはじめます。本人は一生懸命に作ったので、作ったものが「どのように（TO DO）」動くのか説明したくて仕方ないのも理解できます。しかし、それでは話が噛み合わなくなってしまいます。まずは、心を落ち着けて説明するのが良いと思います。
このように、レビュー時やエンジニア以外に説明する時は、「WHY（なぜ、なんのために）」から伝えていきましょう。
説明の流れをイメージしておく
冒頭に申し上げた通りに、自分が作ったものが「どういうもの」なのか説明するには、具体的な流れをイメージできてなければなりません。
説明の具体的な流れは以下の通りです。
①要件説明
- 納品物の説明（掲示板を作っています など）
- 前回までにどこまで実装したのかの簡単な説明
- 今回はどの機能を作ろうとしているかの説明
- 実現できたかの【結果】を先に伝えておく
②範囲説明
- 実装箇所のディレクトリ名とファイル名を伝える
- ファイル内の実装箇所を伝える
③機能説明
- 要件に対して「WHY（なぜ、なんのために）」作ったものか伝える
- 機能が「TO DO（どのように）」実現しているか流れを説明する
※ 画面を使って視覚的にアプローチすると効果的です - 最後に感想を伝える
④レビュー
- レビュアーからの指摘やアドバイスを受ける
- 必要に応じて質疑応答をする
- 指摘を受けた部分のコードを修正する（あるいはメモしておく）
この流れを意識しておくと、自分が何のために「どういうもの」を作っているのか、どのような流れで説明するのか、そういうことをイメージできるようになります。コードレビューの直前には、この流れを確認しておくと良いでしょう。レビューを円滑に進めることができるはずです。
まとめ
如何だったでしょうか。レビューと言えば、「どのように伝える」かに注目されがちですが、本当は事前準備が重要だったりします。そして、ここで説明をしていることは、実は特別なことではありません。相手や内容によって伝え方を変えることは普通のことですし、コードを書く時に「なんのために（WHY）」作って、「どのように（TO DO）」動かすのか、それを考えることは自然なことです。大事なことは、それらが具体的にイメージできて、論点整理されて準備できているかということです。それは心得として意識していれば事足る程度のことです。プログラミングだけがエンジニアの技能ではありません。この機会にコミュニケーションも磨いていただければと思っております。
Discussion