セルフレビューのコツ ○

読み返すだけのセルフレビューからの卒業

他人にレビューを頼む前に、一度自分のコードを客観的にレビューを行い、修正する。セルフレビューという概念は、おおよそ全てのエンジニアが習うものだと思います。しかし、具体的なセルフレビューの方法が「コードを読み返し、誤りに気づいたら都度修正を行う」という方法になっていないでしょうか。

読み返しながら都度修正を行うという手法では、「ソースコードを読んでバグを見つける」「バグを修正する」という2つの作業を何度も往復する事になります。これは2つ以上のタスクを頻繁に切り替えながらやっている事に等しく、注意力が散漫になり、どちらのタスクにもミスを招く要因になります。仮に貴方がもう一人いて、その人にセルフレビュー前のコードにレビュー依頼を出した場合を考えてみましょう。ソースコードを読んでバグを見つけるという作業にのみ集中するのだから、読み返して都度修正を行う場合よりも多くの指摘事項を発見できそうです。

逆に言えば、セルフレビューを普段のレビューの手法に近づけ、「レビュー」と「修正」を分離して行えば、セルフレビューの質が上がると考えられないでしょうか。

セルフレビューを普段のレビューに近づけるには

結論から言うと、セルフレビューの時も通常のレビューと同様、指摘事項を記録していく事が最も重要です。つまり、Pull Requestに上がっているソースコードを読み、問題のある行に対して指摘事項を残していくことが基本となります。

単純ですが効果は絶大です。レビューと修正を往復するオーバーヘッドはなくなり、記録した指摘項目はそのまま次の修正のタスク一覧となります。

また、他のレビュアーに対して「私はセルフレビューを行った」というエビデンスにもなります。例え経験やスキルが不足しており、レビュアーが望むだけのバグが取り切れていないとしても、指摘事項や解決の過程を垣間見る事ができれば、レビュアーからより適切なアドバイスを貰う事ができるかもしれません。セルフレビューをちゃんとやったという言葉に対する印象も格段に良くなるでしょう。

気配りのコストを減らし品質アップを狙う

この項こそが筆者の一番主張したかったことです。セルフレビューには、他者の介在する通常のレビューにはないメリットが存在します。それが気配りコストの削減です。

私達は普段、他人のコードをレビューするときに、どうしてもコーディングに対する思想の違いや、レビューイの精神状態や立ち位置、指摘事項の修正確認にかかる時間といった、レビューには直接関係のない要素に左右され、細かい指摘を忖度をしたり、角の立たない指摘文章を考えるのに時間を費やしてしまいます。これが気配りのコストです。ソフトウェアの品質を第一に考えた場合、非常に問題のある行為ですが、現実との折り合いを考えると完全に無視はできません。

しかしセルフレビューの場合、他者へのレビューと違って気配りのコストを限りなくゼロにすることができます、だって自分が相手なんだもの。気に入らないと思った箇所には遠慮なくラフな口調で簡潔な指摘をつけましょう。「関数の命名が気に入らない」、「変数名をtypoしてる」、「関数が長すぎるから分割したい」、「XXXする場合のテストが足りていない」、「コメントの補足がほしい」など、軽い気持ちで指摘をつけていきます。

するとどうでしょう、気配りのコストを減らしたぶん、普段のレビューよりも多くの指摘事項を多く出す事ができるようになります。慣れると指摘項目を増やすことに快感さえ湧いてくるやもしれません。後で他人から指摘されるより、自分で指摘を出して直してしまうほうが、時間的にも精神的にも安上がりなのですから。それがセルフレビュー特有の強みなのです。

Pull Requestの便利な機能を活用する

ここから先はGitHubのPull Requestに備わっている、レビューに便利な機能の紹介です。セルフレビュー特有と言うほどでもなく、知っている人は読み飛ばしてもらって構わない内容です。

読み終わったファイルにはViewedにチェックを入れる

レビューし終えたコードは、Viewedにチェックを入れて表示を省略しましょう。Viewed済みのファイルに変更がコミットされた場合、Viewedのチェックが自動的に外れるのも便利です。Viewedのチェックは個人に紐付いているので、普段のレビューから使って良いと思います。

セルフレビューの指摘事項を解決したらResolve Conversationを使う

PR上の会話はResolve Conversationを押して解決したことにすれば、PRのツリー上から表示を省略する事ができます。しかし、他人からのレビュー指摘に対するResolve Conversationは、解決していない項目を誤って放置してしまう可能性も大きいので、「誰がいつ押すのか」はチームで運用を考える必要がある機能だと感じます。

セルフレビューの場合、解決するたび積極的に押してしまうのが良いでしょう。未解決の項目だけがツリー上に表示されるため、修正の進捗がつかみやすくなります。他人にレビュー依頼を投げる際、全ての会話がResolve Conversation済みになっている事が望ましい形です。

最後に

本稿ではGitHubのPull Requestを活用したコードレビューの場合を例に上げましたが、基本設計や要求仕様などの設計段階でも、考え方を応用することはできます。Pull Requestではなくても、コメントの機能が備わっていれば、それをレビュー指摘とみなし活用することができます。
さて、Pull Requestを抱えていますか？では早速実践しましょう！