SPIDERPLUS Tech Blog

建設SaaS「スパイダープラス」のエンジニアとデザイナーのブログ

やっぱりコードレビューはしたほうがいい、というお話

皆様こんにちは。プロダクトマネージャーの池田です。
私はゲーム機開発現場でプログラマーとして経験を積んだのちに漫画の編集会社でモバイルアプリ事業の立ち上げを経て、スパイダープラスに参加してからは建設の現場に関わるようになりました。
今回はスパイダープラスで実施しているコードレビューについて、私自身の経験も踏まえて書いていきます。

コードレビューなんて知らなかった頃のこと

さて、冒頭の自己紹介でも少し書きましたが、新卒でゲーム会社に入り、ゲームセンター用のゲーム機開発に携わりました。プログラマーとして経験を積み重ねていたある日、ゲームセンターでテストをする班に配属されたのですが、そこである日思わぬ経験をすることになりました。大規模クラッシュに遭遇したのです…!

当時携わっていたのはプロがいる分野のもので、ゲームセンターでイベントを開催し、そこに参加するとオンライン上でプロと対戦できるという企画があったのです。
テストの段階ではユーザー数が少ないため、本番さながらにプロと対戦できるという状況でマッチングしてみるとゲームがクラッシュするという事態が起きました…。

原因は私が実装したコードにあり、プロのユーザーに割り振られているIDが、特定のIDになると変数に正しい値が入らない、という内容になってしまっていたのです。
その時在籍していた組織を悪く言う意図は全くありませんが、当時はコードレビューというものをしていなかったので、レビューが必要、という考えもありませんでした。

とはいえ、このプロとの対戦イベントは一番の売りだったはずなのに、プロとのマッチングという幸運が、ゲームをクラッシュさせる不運のスイッチになってしまいました。

コードレビュー作業体験

スパイダープラスに入ったことで、コードレビューを自らやるようになりました。

こちらも今となっては信じられないくらいですが、参画当時はまだオール人力で指摘作業をしていたものです…。

導入が広がっていく中でそのあたりも改善されていくことになりましたがそのお話はまた別の機会に。

さて、指摘をしながら自分自身も学ぶことが色々ありました。

中でも大きかったのは仕事の仕方について「相談方法を身につけることができたこと」です。

また、コードレビューを進めるにあたってルールも大きく2つ作りました。

  • 指摘コメントに種別を定めて、対応可否を明確化
  • 指摘事項のガイドを作成し、人による指摘のブレをなくす

具体的なコメント例を紹介します。

コードレビューでは、実際にコードを作ったのとは別の人間が指摘するし、作ったのとは違う人間が言葉を介して行う以上、解釈のゆらぎを完全にゼロにすることは難しいです。
その一方で、指摘事項の表現について共通の見解を持っておくことで、指摘を受け取る側はその内容に納得して、対応していくことができるようになるはずです。

レビューする側になってみて思ったこと

指摘しながら気づいたこと

大きく3つありまして、

1.他の人のコードの書き方を知ることができる

コードレビューでは自分では思いつかなかったスマートなコードを見る機会に恵まれることがあります。これはとても勉強になります。逆にアンチパターンを見た際には自らに対する戒めにもなります。

自分自身が指摘をする以外にも、他の人の指摘内容からも新たな発見につながることがあります。例えば、自分が実装していない部分の仕様の把握、などです。

2.コードレビューの心理安全

こちらも相手も人間で、適切、正しいという以前に感情を持った生き物です。

お互いに不快にならず、感情的要因によって仕事が妨げられないことはとても重要です。

指摘を受けることで凹んでしまう方もいらっしゃるかもしれませんが、逆にその指摘を修正することでレビューした側にとっては「お墨付きコード」と映ります。

経験の少ない方でもベテランが実装したコードに匹敵するものに昇華させることだってできるのです!

一度100以上の指摘が出た時は流石に大丈夫だろうかと心配になりました。

が、実際はポジティブに受け取ってもらえて、一安心ということがありました。

レビューする側も、躊躇せずに指摘することによって、実装した人にとって「負の遺産」を渡すことを避けるためにも指摘は積極的にしましょう!

+339  -427 の修正レビューにおいて、 	藤田(登):100件 	池田:131件 の指摘

1度の指摘でもこれだけの件数が表示され、レビュー完了までには合計200以上もの指摘が(+339 -427 の修正レビューにおいて、私が131件、もう1名が100件の指摘登録…)

3.レビューからも色々学ぶことがある
コードレビューは担当している役割や作業という以上に、なんだかんだ、自分にとっても勉強になる機会だと思っています。

レビューする側もいち実装者、つまり人間です。そこには当然間違いもあります。
指摘を受け取る側がすべて鵜呑みにするのではなく、指摘内容を見た上で実装に理由がある場合、それを率直に話してもらえることで、こちらもレビュー内容を見直したり、改めてより適切な回答を行うことができます。
コードレビューをめぐるコミュニケーションによって、こちらも成長させてもらえるのです。

まとめ

・コードレビューはやったほうがいい

最初のほうで、昔のクラッシュ体験を書きましたが、SPIDERPLUSというサービスは建設業者が使います。何か駄目なことがそのまま気づかれずに使われると、現場で働く方はもとより、竣工後などに建物を利用する、いわばエンドユーザも含めて命に関わりかねないです。

そういう点で、コードレビューは本当にやったほうがいいと思います。

・対ユーザ以外でも、やっぱりコードレビューはやったほうがいい

サービスの開発はお客様、つまり受け手がいることが大前提です。

一方、開発の途上というのもその中に身を置くものとしてはやはりとても大切で、コードレビューを通じて仕事の進め方から技術的なことまで新たに学ぶことの少なくない貴重な機会です。

自分自身のためにもコードレビューは、やっぱり本当にやったほうがいいと思っています。

ところで、スパイダープラスでは仲間を募集中です。

スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。最後までご覧くださり、ありがとうございます。