最近起こった境遇の変化といえば、コードレビューをする機会が増えたことだ。
これまでは自分の書いたソースコードをレビューしてもらうことがほとんどだったが、いざ自分がレビュアーという立場となってみると、いきなり上手にはできないものだと実感した。
コードを評価することの難しさはもちろん、プログラマに対するフィードバックの仕方(主にコミュニケーション)に関しても、日々よりよい方法がないか試行錯誤している段階である。
たまたま、定期的に読み返している一冊『プログラマが知るべき９７のこと』の一節にコードレビューに関するエッセイが収録されていたので、この機会に改めて読み直してみた。
書籍『プログラマが知るべき９７のこと』について
はじめに、『プログラマが知るべき９７のこと』という書籍について触れておくと、世界中の達人プログラマ書き下ろしのエッセイ９７本(+10本)を収録した一冊で、技術への見解はもちろんプログラマとしてのマインドセットや習慣まで話題に富んだ内容となっている。
１エッセイあたり２ページ程度のため、読み物としても負担なく楽しめることだろう。しかしながら内容は決して薄っぺらなものではなく、読み直す度に新たな視点を得られる、時に背筋が伸びるような一冊である。
新人エンジニアからシニアエンジニアまで必読の名著と個人的には思う。
マティアス・カールソンに学ぶコードレビュー
さて、今回の本題であるコードレビューに関するエッセイを、スウェーデンのJavaユーザグループリーダーとして活躍しているマティアス・カールソン氏が綴っている。
なお後述するが、このエッセイは以下より無料で読むことが可能だ。
マティアス・カールソン『コードレビュー』-『プログラマが知るべき９７のこと』
マティアス氏による以下の見解は、示唆に富んだ内容ではないかと思います。
コードレビューの目的は、ただコードの誤りを修正するだけではありません。重要なのは、チーム全員に同じ知識を共有させること、またコーディングにおいて全員が守るべきガイドラインを確立することです。(collective code ownership)
レビューにおいては、みんな友好的な態度をとるべきです。コードについて何か意見を述べるときは建設的であるように心がけ、辛辣(しんらつ)な批判は絶対に避けましょう。
レビューで最も大事なのは人です。(中略) できるだけ砕けた雰囲気になるよう心がけ、主目的をメンバー内で知識を共有することに置くようにするといいでしょう。
「できるだけ砕けた雰囲気になるよう心がける」ということについて、工夫の余地がありそうです。
現在のチームで意識しているのは、テキストベースのやりとりで完結させるのではなく、実際にメンバーと対話することでそのこのが達成できるのではないかということです。
文字ベースのフィードバックのみではどうしても淡々とした厳しい印象を与えてしまいかねないため、フィードバック後に対面でコミュニケーションする機会を設けるようにしています。
このことから、お互いの認識のギャップを埋める(要件の伝え方・設計の考慮が不足していたことへの気付き等)だけでなく、他愛もない会話からよりよい実装方法が見つかるなど、新たな価値が生まれることも体験しています。
こういった時間がお互いの更なる理解に繋がったり、次はこうしたらもっと上手くいくのでは？という経験則を築いていくものと思っています。
本書はなんと無料で読める…！(ウェブ版)
実は本書にはウェブ版が用意されており、なんと無料で読むことができる。
軽く目を通すだけでも、きっと何か得られるものがあるのではないだろうか？
私はすっかり気に入ってしまい、紙の書籍も購入。定期的に読み直したい一冊として本棚にノミネートされた。
終わりに
エッセイの導入にもありますが、”軍法会議にでもかけられている”かのようなコードレビューという表現は、自分自身も身に覚えがあります。
特に多重請負構造のプロジェクトに参画していた時には、往々にしてそのような雰囲気に陥りがちだったと思います。
“自分がされて嫌なことを他人にしない”というニュアンスのことを、ナシーブ・ニコラス・タレブは『反脆弱性』の中で述べていましたが、コードレビューに限らず、チームメンバーが最大限のパフォーマンスを発揮できるような一員となることを目指しています。
