mixiのコードレビューについてご紹介

こんにちは技術部たんぽぽグループのmasartzです。でも今日はコードレビューアのmasartzとしてお送りします。

mixiの開発フローにはコードレビューという工程が含まれています。
今回はこの工程を行うコードレビューアな人々と、その業務内容、今後（の予定）などをお話しようと思います。

コードレビュー業務

mixiのサービスがスタートしたのは2004年2月の事ですが、コードレビュー業務が始まった正確な日時は残念ながらわかりません。
レビューツールもemailのやりとり->Tracのチケット->JIRAチケットと変遷があるため、最古のものをトラッキングできないのですが、おそらく5年以上前から様々な変遷を経て、今に至ります。

開発者が増えると、開発されるコード量も増えます。つまりレビューする量が増えるため、コードレビューアも増加します。
そんなこんなで現在ではアプリ開発者に対して、コードレビューアの割合は約1割強という世帯構成になっています。
（androidやiOSの公式アプリなど環境が異なるチームは別体制なのと、JSは管轄が違うため、以後はperlに限った話で進めさせていただきます）

mixiの一般的な開発フローとコードレビューアの関係を流れで示すと、以下のようになります。

• 案件立ち上げ
• 仕様検討・設計
  • （任意）プリレビュー
• 実装・開発
  • （必須）コードレビュー
• QA
• リリース

プリレビューは、特に案件の規模が大きい場合やコアなモジュールに変更がある場合などに任意で実施されてきました。これはコードの実装に対してではなく、主に設計面・負荷相談など実際の開発の前段階に相談を受けるフローを指します。
コードレビューは、コードレビューアのメイン業務であり、以前はsvn、最近ではgitのコード差分をチェックする作業を指します。
mixiでは、一部の例外（設定ファイルなど）を除き、全てのコードはコードレビューを通すことになっています。
そのため、レビュー対象物は最小だと1byteの差分から大きいものだと相当な時間がかかるものも・・・
作業の規模感については、年間で数千レビューチケットが発行される程です。最も多い人は、1日1個以上のペースで消化していました。
全コードレビューアの平均だとはもちろんこれより低いのと、コードレビューアへの加入時期や他の業務との調整度合い、個々のチケットの重み（差分の量の違い）などなどバラつきはあるので参考程度に捉えていただければと思います。
実際上記の値も、コードレビューア内でネタとして年末に年間のレビュー数を振り返ってみた時の物が元ネタになっています。

独自のツール群

「差分をチェックする」は読んで字の如く、基本は目視チェックになります。
しかし、当然ながらそれだけでは色々と限界があるため、それを補うための数々なツール群が作られてきました。

codereview.pl

対象ファイル群のsyntax check、PerlCriticの実行、機械的にチェックできるmixi独自の規約、などを実施してくれます。
なおPerlCriticのチェック項目はいくつか調整しています。

template-validator

テンプレートファイルにはプログラムから渡された変数を展開する記述がありますが、この際のセキュリティバグを防止するため、変数展開の際に適切にエスケープしているかをチェックするためのツールです。

inspect-package

以前このエンジニアブログでも語られた「静的解析モジュール」です。

さらに詳しいことは当時のエントリをご参照ください。

他にもいくつかありますが、それら全てコードレビューアはもちろん、全開発者が利用できるようになっており、コードレビュー業務のみならず開発業務全般の手助けとなっています。

コードレビューアの役割

コードレビューアの目的という社内wikiの項目には「mixiらしさを維持するため、事故を起こさないように」と書かれています。
ここで言う事故とは、主にmixiというサイト特有の突発的な負荷やデータ不整合などを指します。
つまり、コードレビューにおいては、メンテナンス性の高さやデータの扱いに関するお作法に則っているか、などがチェックポイントとなります。
逆に案件固有の仕様に関するバグなどを全て防ぐ事を目的とはしていないとも言えます。
もちろんバグを見つけられるに越した事はありませんが、作業の性質上コードから仕様を把握してバグまで発見するというのは現実問題難しいため、これらの部分は単体のテストファイルやQAの工程によって担保する、というスタンスを取っています。

また、これらのチェック項目をコーディングガイドラインとしてまとめる作業もありますが、その内容についても緩すぎず、キツすぎず、というような温度感になるよう配慮しています。

中の人

そんなコードレビューアはどんな人たちがいるのかというと、一言で言うと色んな人たちです。というか、それ以上の説明がしにくいのですが、ポイントは「最もコードが書ける人から順番にコードレビューアになっている訳ではない」という点です。
これに関しては目的の所ともリンクしますが、求められるのが「mixiらしさ・メンテナンス性の維持」であるため、逆に尺度となるのはmixiのソースコードに触れているか、という点になります。
かく言う自分がコードレビューアなのも、とりたててコードが書けるという訳ではないので、そんな事情があるからなのかなぁと感じています。

まとめ＆今後（の予定）

それなりの歴史があって、その中で一定の成果を出して来たと思われるコードレビュー業務ですが、いくつか問題点が出てきたというのも事実です。
特に開発者の増加に伴ってレビューアも増加してきましたが、グループとして維持していく事の難しさやコストが単純に増加しつづけている事を考えると、今後はスケールする以外の別のアプローチも考えていく必要があると感じています。
これらの動向については、またいつかの機会にお伝えできればと思います。