コードレビューをし合える文化がチームを強くする

コードレビューしてますか？

「コードレビューをしよう - pblog」でも触れたのですが、 今回はコードレビューの話です。

コードレビューって何からして良いか分からなかったり、レビューアーに負担なんじゃないか、、、って尻込みしがちですが、レビューしてもらう前に気を付けること、なにをレビューしてもらうのか、そして逆にレビューするのか、そして何が起きるのかあたりを考えていきましょう。

レビューして貰う前に気を付けること

レビュアーの負担を減らすのは大事です。

コーディング規約に沿っているか？といった簡単なレビューは、犬にやらせるという方法もありますが、そもそもgit-pushする前に、ローカルのgit-commit時点で対処しておくというのもありです。

犬 is rubocopですし、

rubocopやjshintなどをgit-hookにまとめて設定できるpre-commit gemが便利そう（メモ） - Qiita

こんな感じでgit-hookに仕込んでおくとよいでしょう。

レビューして欲しい箇所を明確にする

git-flowやgithub-flowに則っていればおのずと、レビュー対象となる対象はbranch単位となっているでしょう。branchは明確な単位で作られているとレビューしやすいです。

• 目的は何か
• 相談したいところ

を分けて書いておくとよいでしょう。

「この辺きになるんですよねー」とか自らfiles changesに書き込んでおきましょう。

レビューしてもらう

チームによっては、アサインする相手が決まっていたり、当番制だったり、ランダムだったり、その日の気分だったり、はたまた自分しかいなくて自分で見ていたり、イロイロです。

今回の「目的」を把握している人に、仕様確認の意味で見てもらう。技術的に明るい人に実装方法を相談したりアドバイスを貰う。なんかあまり話したことない人にあえて振ってコミュニケーションのきっかけを掴む。などなど。

コードレビューはコミュニケーションなので、普段接してない人をアサインしてみるのも面白いかも知れません。

レビューをする

レビュアーは、チームの認識を合わせながらレビューすることが大切です。その指摘が「論理的にどういう理由でなぜこうするのがベストと考えるか」を明確にしましょう。

もちろん、チームの認識は「育てていくナマモノ」なので、チーム内のコミュニケーションとしてコードレビューを活用すると、コードレビューするために必要なチームの共通認識はコードレビューをしているうちにいつの間にやら出来上がっていた。みたいな感じになります。

またレビューするのは、アサインされている人だけではなく、なるべく顔を突っ込んだほうがいいと思っています。毎朝、昼の後、帰る前好きなタイミングにpull request(merge request)を眺めて議論に参加しましょう。repositoryでのactivityをhookしたメールなどのnotificationを監視しておいて、チームで何が起きているかを把握することを心がける。そうしてチーム内の共通認識を育て、チームの底力を上げていく。それがチームにおけるレビューの意義だと思います。

過熱する議論

熱い議論になってきて、「ちょっとこれは炎上感ただような」と感じたらどちらかが席まで赴いて、気の利いた言葉をかけつつ対面で話をしましょう。対面は大事です。文字だけでの議論は齟齬を生みガチですし、文章だけ見ていると険悪な雰囲気になってしまったりします。

和やかなムードを醸し出すために、LGTMやmisawaをすぐに出せるよう にしておくことが大事です。絵文字もいいですね)

レビューをする際の共通認識

私は、railsで作られたアプリケーションのレビューをするのが多いのですが、railsは規約に則っているので、「どうすればrailに乗って開発効率がアップするか？」といった共通認識を持ちやすいのでやりやすいです。

githubやgitlabなどコード管理システム上でだけでなく、対面でレビューしたり、複数人でコードを肴に酒を飲むのもよいでしょう。そうして活発な議論を通して共通認識を育ててゆくのがチーム開発の醍醐味です:)

コードレビューをし合える文化がチームを強くする

コードレビューを自然とし合える文化がチームを強くすると思います。コードを書く際の共通認識が生まれますし、コミュニケーションも豊かになります。お互いがお互いを尊敬し合い意見を交わすことは強いチームに必要不可欠です。

コードレビューをするぞ

コードレビューを体験したい方やプルリクエストをしてみたい方は、おもてなしの心でコードを書こう | マネーフォワード エンジニアブログで題材にしたppworks/furikaeriは小さいアプリですし、オススメです。そうです、チームじゃなくたってプルリクやコードレビューは出来るのです。良い時代です。

おや、こんなプルリクエストがありますね。「Design:p by ppworks · Pull Request #5 · ppworks/furikaeri」レビュー待ちかな？

github触ったとのない方は最近出た本だと、以下の本が入門に良いです。

Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール

ぜひぜひ。