読者です 読者をやめる 読者になる 読者になる

mixi engineer blog

ミクシィ・グループで、実際に開発に携わっているエンジニア達が執筆している公式ブログです。様々なサービスの開発や運用を行っていく際に得た技術情報から採用情報まで、有益な情報を幅広く取り扱っています。

きっと何者にも成れないモジュールたちに告げる~静的解析、しましょうか~

mixi Perl

たんぽぽグループのhirokiです。たんぽぽグループとはmixi内の「刺身にたんぽぽをのせる仕事をなくす」ことを目的とした技術者集団です。

  • 「あれは、たんぽぽではない食用菊である」
  • 「スーパーの生鮮食品バックヤードが片手間にやってるよ。」

というご批判・ご指摘をうけ、今後は「道路に片方だけの軍手を落とす仕事をなくす」ことを目的としていこうかなどの検討を重ねました結果、「細けぇこたぁいいんだよ。」という結論に至ったことをこの場を借りてご報告させていただきます。今後ともたんぽぽグループを御ひいきによろしくお願いいたします。 と、ご報告をさせていただいたところで、本題にはいります。

YAPC::Asia Tokyo 2011

先日Perlのお祭りことYAPC::Asia Tokyo 2011においてLTをさせていただきました。その資料のご紹介とちょっとした解説をさせていただきます。

slideshareもいいんですが、pptxでダウンロードするとよりアレっぽくなっているのでぜひお試しください。 「静的解析、しましょうか」資料のダウンロード

静的解析

静的解析とはプログラムを動作しないで、コード自体からその品質を評価したり、問題点を指摘したりする解析手段です。より正しくは静的コード解析なんですが、とある事情で4文字熟語にしたかったので端折りました。

どのようなソフトウェアにも設計上のミスはあります。その時点ではサービスの発展性や日々変わりゆく要件を完全に予測することはできないからです。ある時点で正しい設計も、その次のサービスリリースでは、設計上の修正を必要とするかもしれません。これらの変更への粘着性や複雑性のある状態を設計上の負債あるいは技術的負債( Technical Debt )といいます。

しかし、ソフトウェアが巨大になり、開発者数が増加するにつれて、「技術的負債の計画的返済」の必要性が認識されてきました。ミクシィでは、技術的負債を計測したり、問題点を指摘したりするツール群の作成を行って計画的に負債の返済が可能になりました。

技術的負債の種類

LTでは、技術的負債の種類として3つをリストアップして発表しました。 「最長不倒関数」、「王様モジュール」、「複雑な依存関係」です。mixi内のコードを対象にこの3項について評価/レビューを行うscriptを書きました。

最長不倒関数:とても長くて入り組んだ分岐がある関数。すべての経路を通るようなテストケースの数が1関数に対して膨大になりすぎて、もう人類の理力の限界に挑戦している関数

王様モジュール:多くの権限、責務をもち、あらゆる目的を達成するスーパーマンモジュール。こう書くとかっこいいが、しょっちゅうマージ時にコンフリクトしたり、全体を見通せないけどなんとなく機能を追加している人が大量にいて、useするだけで重いような憎いやつ。

複雑な依存関係:いろんなモノに依存しているのにいろんなモノに依存させている状態。正しい設計のコアモジュールであれば、依存されていても依存していないので問題ない。正しい設計のアプリケーション層モジュールであれば、多くのモジュールに依存していたとしても、自身は依存されていないので問題ない。ハタ迷惑なやつ。

その他負債となりうる指標はいくらでも思いつくのですが、ついうっかり見過ごしがちであったり、影響が大きいものに関して評価を行っています。これらを組み合わせて、誰にでもわかりやすく「チーム内での機能追加の難しさの数値」と「サービス全体に対して悪影響をもたらす数値」の二つを算出しています。くわしい計算式などはこちらの記事をごらんください

負債を見える化することの効果

このツールを社内で公開してからしばらくは、あんまりおおっぴらに言わないでCIサーバで継続的にニヤニヤするなどしていましたが、アーキテクチャや設計のポリシーと合わせて公開してからは、いくつかのいい動きが現れてきました。

  • チーム内で目標を決めて継続的に改善していく計画を立てたり
  • コードレビュー時に実行して、指摘をしたり
  • テストに組み込んで、現在の値より大きくならないようにしたり

などなどです。また、数値となっているのでプランナー・マネージャにも問題として認識しやすくなり、みんなハッピーですね。 また、たんぽぽグループとしても明文化しづらいコードレビュー基準から、より機械的な判別で指摘できるようになったため、「指摘して嫌われたらどうしよう」などおとめチックな悩みも減りましたし、身長もチーム平均で5cmくらいは伸びました。

そんなわけで

静的解析で、ソフトウェアの生存戦略、しましょうか。