前回はコードレビューを始める動機や始めるために必要な心得について考えました。
今回はこれからコードレビューを始める組織が、どのようにして具体的にはじめて行くべきなのかを考えます。
コードレビューが定着していない人達がどのようにして、コードレビューを始めるべきでしょうか?
まずは、コードレビューをやってみる
まずは、重圧などはかけずに、気軽な気持ちでやってみてください。今回は「はじめること」が目的です。
コストの高い準備や学習はしない
使い慣れたコードレビューツールがあるれば、それを利用してやれば良いでしょう。なければ、既存のIDEやエディタをプロジェクタで投影しながらやれば良いです。とにかくツールを覚えるコストや準備するコストは、なるべく省きましょう。フットワーク軽くはじめる事が重要です。
実際にやってみることによって学ぶ姿勢
コードレビューをやった経験が十分にないのですから、最初はグダグダになるはずです。そのために多くの準備をする必要はありません。コードレビューをすることによって、コードレビューそのものを学ぶという認識で挑んでください。
一人一人はどう考えるのか
プログラマーは自分で書いたコードを一人のレビュワーとして、参加しながら説明して、コードレビューをやって、受けてください。
自分自身がレビューワーとしてなることによって、気づきが得られるはずです。この気づきは他のレビュワーから教えてもらうのを待つだけではありません。
プログラマー自信がコードを人に見せて説明するということを意識することにより、実際に自分でコードを書いている段階で、少なからずコードの品質を考えるようになります。そして、気づき改善するはずです。
コードレビューを何回か実施する
何度かコードレビューを定例的に実施すると、どんなバグが目立って起きるのか、参加者の間で明らかになります。
それは最初の共有知識となるでしょう。
これにより、知識として共有されるため、コードレビューにくる前の段階で、コードはかなり改善されるはずです。
同時に、レビューする側としての経験を積むことになるので、レビューは効率的になっていきます。
コードレビューが加速する、加速させる
このあたりになってはじめて、教育的なフィードバックを検討し、実施しはじめるべきでです。
教育的なフィードバックとは、良くあるエラーケースを体系的にまとめることや、有用となるであろうプログラミングテクニックを学びあうことなどを指します。
あら探しになるようなことをしない
注意しなければいけないのは、プログラマー個人やチームの統計を取らないことです。
コードレビューは、プログラマの能力に格付けを行うための行為ではありませんし、ましてやチーム同士を競わさせるためのものでもありません。
次回は、コードレビューという機会を実施するための共有しておくべき心得に関するお話です。
前回の記事はこちら
コードレビューに関する話は、今のところ全部で5記事で配信していく予定です。応援や期待、お待ちしております。また、たまたま資料が手元に多くあるので、疑問やこういったことが知りたいという要望がありましたらご連絡頂けると記事にするかもしれません。一緒に学びましょう。
Karl E.Wiegers、大久保 雅一 |
ソフトウェア技術レビューハンドブック―実践的ノウハウに関するQ&A (ソフトウェア・エンジニアリング・シリーズ) ダニエル・P. フリードマン、ジェラルド・M. ワインバーグ、岡田 正志 |