はじめに
私はコードレビューするのもされるのも好きです。自分の知らないことをたくさん知れる良い機会ですし、それを簡単にみんなに共有できる場でもありますし、場合によっては熱い議論の場になることもあります。色々なきっかけを作ってくれます。
自分以外のコードレビューの内容をメールで届くようにして、それらすべてに目を通していました。その場でふむふむと思ってもいざ自分で書いた時に忘れてることもよくありましたが・・・無意味。
コードレビューの様子を1年間観察してみて、色々思うところがあったので、だらだらと書いていきます。コードレビューに対する自分なりの心構えや姿勢について書いています。具体的なコーディング規約に関する話は一切しません。具体的には以下のようなことです。
- なぜを意識した指摘内容になっているか
- レビュー対象はソースコードだが、それを見るのは人間
- レビューは本当に人がやらなければいけないのか
なぜを意識した指摘内容になっているか
「なぜその修正が必要か」を書かずに「このように修正しなさい」だけ書かれた指摘をよく目にしました。
プログラマになってまだ日の浅い人やプロジェクトに配属されて日の浅い人は、指摘された理由がわからないこともあります。指摘されたからとりあえず直すという状態になってしまうと、せっかくの学習機会が失われてしまいます。自分で調べて自己完結するのも良いですが、コードレビューという対話の機会を活かすのも手だと思います。
理由を理解せずに修正した場合、誤った修正をしてしまうことが多いです。誤った修正をすると追加の修正に余計な時間がかかるだけでなく、精神的ダメージも大きいです。理由が理解できていると修正が的確になることに加え、議論が深まりやすいです。議論の末、より良い修正案やコーディング規約の変更などに発展することもあります。これはすごく良いことだと思います。
指摘する側は、理由を書くことを意識し、指摘される側は、理由が書かれていなければ質問する、といったようにお互い意識することが大事かと思います。
レビュー対象はソースコードだが、それを見るのは人間
テンションが下がってしまいそうな言葉使い・口調の指摘を何度か目にしたことがありました。
レビューの対象はソースコードですが、指摘を確認して修正するのは人間です。指摘事項を読んだ人のテンションが下がったり、嫌な思いをしないかを意識するのは大事だと思います。コードレビューが気分が乗らないものと認識されてしまうと、前述した議論の発展はほとんど望めないと思います。
ちなみにですが、これは指摘を控えなさいということではありません。指摘することはしっかり指摘して、それが嫌な思い出として残ってしまわないように配慮しよう!ということです。
そのレビューは本当に人がやらなければいけないのか
プロジェクトごとにコーディング規約があるかと思います。コーディング規約には、「少し細かいことだが、そのプロジェクトでは必要とされていること」が定められている場合もあります。
些細な指摘の内容によっては、レビューする側もされる側もうんざりしてしまうことがあります。コーディングは楽しい作業であるはずなのにうんざりした気持ちになってしまうのは悲しいです。些細なことだとそれが何度か繰り返されることもあります。何度か繰り返されると、繰り返した分だけうんざりしてしまうわけです。
「そもそもその規約が必要なのか?」をまず考えると思います。不必要であれば規約から排除してしまえばいいと思います。必要だと判断される場合はそうもいきません。必要であれば、それを機械に任せられないかどうか考えます。一般的なコーディング規約であれば、世にある様々な便利ツールやLintを使えば対応できます。コードをコミットする前にツールにかけて規約から外れている箇所を検出し、それを修正する。これであれば、自分で完結しているのでストレスにならないかと思います。
しかし、プロジェクト特有のコーディング規約の中にはツールでフォローできないことも多いかと思います。C#であれば、RoslynのAPIを使って独自の静的解析ルールを拡張したりもできます。独自の静的解析ルール追加にはそれなりにコストがかかります。時間効率が良くなり、うんざりもしなくなると思えば、コストに見合う効果があると思います。
さいごに
精神的なストレスを緩和するような話が大半となってしまいました。毎日のように行われることなので、ストレスなく進められるかどうかは非常に重要だと思います。コードレビューが辛くなってしまうと、ただのプロセスの1つと捉えられがちです。これでは良いレビューはできないと思います。
変なことを色々と書いているかもしれませんが、これを読んで「コードレビューを幸せなものにしよう!」という意識が少しでも芽生えたなら嬉しい限りです。