このブログははてなブログからの移行記事です。

はじめに

この記事はアドベントカレンダー15日目の話です。

qiita.com

大遅刻になってしまったのは社内宴会での新卒芸を用意していたからで、まぁいろいろ言い訳はあるのですがそちらのことはアドベントカレンダーの24日目に…。

コードレビューの話をしよう

今回はコードレビューの話です。

弊社では約1年ほど前から開発フローの改善が積極的に行われており、その改善の1つにコードレビュー文化の醸成があります。

最初はなかなか浸透しなかったものの、1年間かけて社内でのプルリクエストにはほぼ必ずレビューがされる状態になってきたのではないかなと実感しています。

しかし、改善の過程には当然様々な問題が発生しました。今回はそのうちの1つを解決した話をします。

「レビューお願いします」

弊社では以下のような流れでレビュー依頼を出します。

  1. featureブランチを切り、WIPプルリクエスト or プルリクエストを作成する

  2. 実装を完了させる

  3. Slackの該当チャンネルに「レビューお願いします」と言う

  4. 誰か手の空いてる人がレビューする

チームやプロジェクトごとに若干の差異はありますがだいたいこのようなフローです。

問題はこのステップのうち、4番目でした。

手の空いてる人がいない

コードレビューが浸透してくると浮き上がってきた問題で、「レビューがされないからプルリクエストがマージされない」問題がありました。

「誰か見てください」とSlackで呼びかけてもみんな自分の作業が忙しく、レビューされずに忘れ去られてしまうなんてことが多々発生しました。

かといって指名制でレビュアーを選ぶ、ローテーションにする、なんてものは柔軟性に欠けるしどうしたものかと言った感じでした。

Hubotの利用

そこで僕は考えました。厳正で平等な抽選を行うことでレビューを拒否できなくレビュアーを選ぼうと。

ということでhubot choiceというHubot scriptを導入しました。

これは僕の所属していた増井俊之ゼミのslack_hubotから輸入したものです。

使い方はこんな感じ。

f:id:sota1235:20151219182243p:plain

ふっつーに引数からランダムで選ぶだけですね!抽選結果で@をつけているので抽選者にメンションが飛ぶようになっています。

これを利用することでレビュアーが誰もいない問題が緩和されました。

hubot choiceの拡張

最初はただの抽選機能だったのですが、レビュアー選びをより快適にするための機能リクエストが多く、機能が肥大していきました。

なので今はhubot-reviewer-choiceというnpmパッケージとして切り出されています。

www.npmjs.com

ここでは拡張されたいくつかの機能について紹介します。

抽選候補のグループ化

同じプロジェクトで何回もレビュアーを選ぶ際、どうせ打つコマンドは同じなのに毎回打たなきゃいけない問題がありました。

https://i.gyazo.com/e177d90e9b3d94e0a0a8bf1d5d4a83a3.png

毎回毎回7人分の名前を打つのは億劫だね、ってことでグループ登録機能をつけました。

使い方は以下の様な感じ。

構文はhubot choice set ${設定するグループ名} ${設定したいメンバーを空白区切りで}です。

登録したグループから抽選する場合はグループ名に$をつけます。

登録されてるグループ名を忘れちゃった時はhubot choice listします。

グループを組み合わせたり、普通の引数と混ぜることもできます。

ちなみにこのグループはそのチャンネルでしか使えないので他チャンネルに影響はないです。

なので各チャンネルで$reviewerみたいなグループを設定しておくのがよいかなと思います!

抽選対象から自分を除外

先ほどの機能の問題の1つに自分が抽選される可能性の問題がありました。

当然、自分で自分のコードはレビューできないので抽選がやり直しになってしまいます。

そこで抽選対象から自分のユーザ名を除外するようにしました。

hubotに煽られます

応用編

ランチに迷った時。

https://i.gyazo.com/87b4c8afae83d56228495c2c7396a400.png

問答無用で名指しレビューしたい時。

https://i.gyazo.com/d120a0fffdc0f876e7cc1339484a1e0d.png

使えますね。

導入してよかったこと

これを導入してみて、もちろんレビュアーがスムーズに決まったことはもちろん、以下のいいことがありました。

レビュー依頼がライトになった

気軽にレビュアー選びが行われて、普段結構ピリピリしてる人も「しょうがねぇな〜」って感じでやっていただけるようになった気がします。

ユーザの声を聞いて改善する楽しみができた

これは僕個人の話ですが、自分が作ったものに対して苦情や要望がたくさん来たことがとてもやってよかったなと思います。

自分の作ったものが使われてることもそうだし、それに対して要望が来るということは改善の余地があるということで、普通に一人でもくもく開発するよりモチベーションを高く保てました。

想定外の使い方をされていた

レビュアー選びもそうですが、会議の司会者決めや宴会の幹事決めに使われているのを見たりして、自分の作ったものが可能性の壁を壊していく様は爽快でした。

まとめ

レビュアー選びで困っている方はぜひhubot-reviewer-choiceを使ってみてください。

そして弊社は新卒がhubotを好き勝手いじっても「おうおう、やったれやったれ」と背中を押してもらえるようないい会社なのでぜひ!みんな来てくれ!!!

COMMENT: そのアプローチ面白いですね…サジェスト機能作ってみます! COMMENT: git blameしてそのコードの周辺に詳しい人もサジェストするのはどうか