コードレビューでポジティブフィードバックを返す方法を整備した話(Lambig)

本記事は
エンジニア組織の開発生産性・開発者体験向上の取り組みをシェアしよう！ by Findy Advent 
参加記事です。

こんにちは、株式会社クラス システム開発本部 Lambigです。

今回はコードレビューに関して。弊社ではコメントにタグ文字列を付けてコメントのタイプを区別するようにしています。例えばこんな感じ。

[提案](性能、コードスタイル)
サイズが固定っぽいのと、この量なので
件数定数化してnew ArrayList(SIZE_OF_HUNDARARA)としたほうがよさげです

ところで、コードレビューは改善点を挙げるだけでなく、よさげなアイデアや行動をパクるための場としても有効です。なのでポジティブフィードバックを積極的に返すとパクリどころが目立つほかいいことがいろいろあります。とはいえ、実行に移すのはなかなか難しかったりするものです。

であれば仕組み化しちゃおう、というのが今回の話。別に難しいことはありません、レビューコメントがカテゴライズされていれば、そこにポジティブフィードバックのためのカテゴリを作ってしまえばよいのです。もしカテゴリがないのであれば強調のためにカッコでくくるだけでもよいですね。弊社では「いいね」というカテゴリを追加しました。

[いいね](ドキュメント)
ボーイスカウト感謝！そういう意味だったのか……

もちろん、運用に載せたら実例を作っていく必要があるのでそこは率先してガンガン褒めていきましょう。弊社の場合は何度かやっているうちに、真似をしてくれる人が現れました。こうなればしめたものです。「こういう運用があるんだ」という前提が軽く頭に入っていれば、レビューの際にも良いと思った点をコメントする->レビューしながら良い点を探す、という正の連鎖が期待できます。

さらに発展させると、これらを例えば「技術的に見習いたいポイント」「スタンス、取り組み的に見習いたいポイント」などのカテゴリごとに分けられるかもしれません。

[うまい](コードスタイル)
こうすればワンライナーなんですね、パクります。

[率先](保守性)
横展開あざますー！

こんな具合に。あとで集計なりなんなりしてなんぞやの指標として使ったり使わなかったりしてもよいです。

改善のための指摘と違う点として、同じ内容のフィードバックを何度も行うと意味が薄れるという問題はありますが、そのあたりは実際にケースに遭遇した際にうまくやっていくしかないのかな、と考えています。(同じ内容の指摘が繰り返されるのもそれはそれで問題ですが……)

というわけで、5分で作れる「コードレビューでポジティブフィードバックを返す仕組み」のお話でした。いい技術、いい姿勢はガンガン盗んでハッピーに行きましょう。