こんにちは、広報部の笠川です。今日は先日行われた社内勉強会のレポートを。

社内勉強会も今回で9回目になりました。レポートを書く都合、私も毎回参加しているのですが、それぞれに発表者さんの味付けがあってとても面白くて、非エンジニア勢の佐藤レイさんやタソガレさんが横から聞き入っていることもあるほど。キャラクターが豊富な会社だなとしみじみ感じます。

さて、今回の発表者は開発チームのマネージャーを務める青野さん。Web周りのことはフロントからバックエンドまで広い知識と経験を持つ「Webの事ならなんでもやるマン」で、誇張なしにみなさんからの尊敬を集める完璧超人です。また、なかなかヘビーなお酒好き、TwitterでMOの土地事故を嘆きがちというキュートな一面もお持ちです。

今回は受ける方もする方も苦手意識を持ちがちな『コードレビュー』がテーマ。青野さんがこれまでのエンジニア人生の中で感じたことや経験してきたことを元に、チームとプロダクトがハッピーになるコードレビューのTipsを共有してくださいます。

ちなみにスライドのタイトルは『世界がハッピーになるコードレビュー』。気持ちあやしさのある表題ですが、ご本人にお聞きしたところ「釣り。」という明快な回答をいただきました。

まずはコードレビューとはそもそも何ぞやという確認からスタート。開発の誤りを修正してソフトウェアをより良いものにしていくという目的をまずは共有します。

「コードレビューが苦手…」という方がいる原因として、自分が書いたコードに指摘が入ることで "人格否定" されているように感じられてしまう事がある点がしばしば挙げられます。しかし青野さんはこれを否定して、「自分が考えるコードレビューの一番の目的とメリットは "開発知識の共有" 」と語ります。コードレビューがポジティブなものという共通認識があれば、より良いレビューを行うことができそうですね。

他にもレビューをしている時に考えていることをお伺いしました。コードの保守性や安全性、ビジネスロジックの整合性など、色々な角度からのチェックが行われているんですね…。

続いては、コードレビューを受ける人たちにお願いしたいことについて。受ける側の心構えとしては、「 "レビューはより良い成果物を目指して行うもの" という目的意識を持って、まずは素直に受け止めてみてください…！」との事でした。レビュアーもレビュイーもお互いに人間。共通のポジティブな想いを持ってレビューができれば、チームもプロダクトもより良いものになっていくのではないでしょうか。

お次はレビューあるあるを元に起こりがちな失敗を見ていきます。

なるほど…。コードを見る側も人間、いきなり数千行のコードをチェックするのは大変ですよね。ちなみにこちら、過去の実話とのことで「やる気は伝わりますが、レビュアーの心が追いつきません…」と青野さん。

「レビュアーも人間なので、数十行ごとにコードを見る時と比べると精度が変わってしまう事もある」「そうなると指摘すべき内容が埋もれてしまう可能性も出てきてしまう」と、このケースのリスクを語ります。そうならないように、スムーズでお互いの負担が少なくなるレビューの進め方の一例も合わせて紹介してくれました。

この他にも、GitHubなどのUI上でレビューを行うときにはタイトルにWIP(Work-in-progress/仕掛り作業)の文言をつけて進捗リクエストを送る、リクエストに修正の概要や説明を入れる、伝達が難しそうなときは行単位でコメントを入れておくなど、いろいろな工夫でスムーズなレビューが可能になるとのことでした。

レビューされる側も「何をどうやって作ったのか」をわかりやすくしたり、大きな変更になる場合は事前に進捗共有することが重要で、レビュイーとレビュアーの間でコミュニケーションが取れているほど潤滑にレビューを行うことができると、皆さんで最後にこのパート全体を振り返りました。

パートが変わって、今度はコードレビューをする人たちにお願いしたいことについて。今回の参加者の中にもコードレビューの経験がある方も何人かいらっしゃるようですね。まずはレビュアーがレビュイーからどのように映っていることが多いかを確認します。

レビュイーにとってはどんな指摘が飛んでくるかわからない状態、多少なりとも気構えてしまいますよね。そんな時に無機質な表現で「修正をお願いします」「改善してください」「ここは違います」などの指摘が続くと少なからずストレスも溜まってしまうと思います。

「特にファーストレビューには配慮しましょう」とことわって、青野さんからレビュアーはどんなことを気に掛けたらいいか、お話が続きます。

レビュイーもレビュアーも人間。ポジティブなコミュニケーションに配慮することで、お互い必要以上に身構える必要が無くなり、より良いコードを作り上げるという目的に遠慮せず取り組むことができるのではないでしょうか。

コードレビューの心構えを確認したところで、ここからは今後コードレビューに挑戦する方に向けて、わかりやすいサンプルコードを例にコードレビューの指摘パターンを見ていきます。

日本語ローマ字変数やコード規約の統一は私が見てもなんとなくわかりますね…。ネスト(入れ子)の深さもコードの読みやすさを下げる原因になるようです。まずは小手調べからのスタートです。

シンプルで保守しやすいアプリケーションを作るための『DRYの原則』は、コードレビューの際にはいま一度思い出してほしいとのこと。マジックナンバーについても同様ですが、いざコードに変更を加える段になったときに地獄を見たエンジニアが数知れずいたという話なので、徹底していきたい部分ですね。

セキュリティやDBアクセス、コメントの書き方など、チェックポイントは他にもいろいろありますね。特に安全性や処理速度などサービスに直接関わる部分は、処理を安全で効率よく行える方法を徹底して、経験の少ないメンバーがチームに参加した時には積極的に共有していきたいですね。

また、サービス全体を見渡している人や特定の言語仕様に精通した人がレビューを担当するのがよい内容も。総括として「チェック項目は多岐にわたることが多いけど、それぞれの得意な領域を活かして複数人でレビューをすると、漏れが減ってメンバーの成長にも繋がります！」とまとめてくださいました。

こちらで発表の内容はひとまず終了して、そのまま質疑応答の時間に。「実際のレビュー時のやり取りについて」「スピードとクオリティの両立」「タイポ(タイプミス)を防ぐには？」など、メンバーからの質問に答えたり意見交換を行ったり、より良いコードレビューについて考える時間にすることができました。

この場を借りて、青野さん、参加者の皆さん、お疲れ様でした！ コードレビューに苦手意識を持っていたメンバーには福音となった回だったのではないでしょうか。コミュニケーションの重要性やより良いコードをチームで作るために必要なことなど、当たり前だけどみんなで大切にしたいことを確認することができたのではないかと思います。

また、こちらの記事をご覧になった方のコードレビューが、少しでもハッピーなものになることを青野さんと一緒に願っております。それでは皆さま、よいコードレビューライフを！