今回は、私が業務をしている中で出会った、Clojureを用いて実装されている静的コード解析サービス、CodeSceneについてご紹介します。業務でClojureを採用する際の説得材料の一つになれば幸いです。また、Clojure以外の言語も多数サポートしているので、その他の言語のプロジェクト管理にもオススメです。コミュニティエディションはオープンソースプロジェクトには無料で利用できます。
CodeSceneはスウェーデンの企業で、ソースコードを静的解析して、コード品質や開発チームの効率、メンバーが辞めたときのリスクなどを評価するサービスを提供しています。社名はCrime Scene（事件現場）をもじったもので、Forensics（犯罪科学、鑑識）をソフトウェアに適用していることから来ているものと思われます。
GitHubやBitBucketで管理されているリポジトリをスキャンし、28のプログラム言語を対象に、下記の切り口から情報を提供します。
ユーザーインターフェースはこんな感じです。Clojureの分析結果がデモとして公開されています。
CodeSceneの機能
- コード
- ホットスポット: ソースコードの更新頻度はロングテール分布が一般的です。最近、頻繁に更新されているコードを特定し、着目点を提供します。
- ホットスポットコードヘルス：ファイルサイズ、メソッド/関数の長さ、コードの複雑さ、多すぎる引数など、頻繁に更新されているコードの健全性を示します。
- 変更の関連性：隠れたファイル間の依存性を特定します。
- アーキテクチャ
- システムヘルス：ソースコード単位ではなく、サブシステム単位でみたコードの健全性を表示します。
- ホットスポット：サブシステム単位でのホットスポットを表示します。
- コンウェイの法則：ソースコードのモジュール分割と、チーム単位がどの程度一致しているかを示します。メルヴィン・コンウェイが提唱した、「システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう」という格言、またそれを逆に考えた、Inverse Conway Maneuverの視点を与える切り口です。
- 変更の関連性：サブシステム間の隠れた依存性を表示します。
- チームの活動
- デリバリー効率：開発者ごとの成果物、チーム内の開発者数、在籍期間などから、ブルックスの法則として知られる、人員追加に伴うコミュニケーションコストの増大に伴う生産性の低下が起きていないか確認できるビューです。
- ソーシャル・ネットワーク：同じコードを編集しているメンバーの関連を表示し、コミュニケーションが同一チーム内で閉じているか、チーム間の協業が多くないかを示すものです。ここからコンウェイの法則を検証することができます。
- 個人：コードの主編集者を表示します。新メンバーとペアを組ませる際の参考になります。
- チーム：チームの構成とサブシステム・モジュール設計がどれほど一致しているかを示します。
- 開発者統計：開発者ごとの主担当モジュール、ファイル、コミット数など、分析の基礎となっている数値を表示します。
- 辞めた開発者の検知：最近コードをコミットしていない開発者の一覧を表示し、元開発者として分類すべきかどうか促します。ひとたびその人がチームに所属していない設定になると、チームからそのコードの知識を持っている人がいなくなったリスクとして認識されます。
- システム
- 開発のコスト：JIRAなどのチケットシステムと連携して、計画したコード変更かどうか、タスク、バグなどチケットタイプごとの分類などを通して、開発コストを分析するための情報を提供します。
- ブランチ：ブランチの寿命、協業者の数などから、CIの安定性を損なうリスクを数値化し表示します。
- PRの統計：プルリクエストがコードヘルスの与えた影響を分析し、開発者ごとにコードヘルスを改善しているか、悪化させているかを表示します。
- デリバリーのパフォーマンス
- シミュレーション
- オフボーディング：開発者が辞めた際、知識が失われるコード、サブシステムなどを表示し、退職のインパクトを予想することができます。
Clojureプロジェクトの分析
今回は、このツールを用いて、Clojureプロジェクトの分析を試みたいと思います。対象は、2006年6月11日から2018年2月9日までのコミット分となっています。
分析の概要
552ファイル、延べ開発者164人、現在の開発者2人、コミット数2,761、バグチケットID付きのコミット数が396となっています。
ホットスポット
大きく、ClojureとJavaコードに別れており、Clojure側で頻繁に更新されているのは、core.cljとcore_deftype.cljで、
Java側は、Compiler.java, RT.java, Numbers.javaとなります。
関連する変更
例えば、clojure.lang.PersistentQueue.javaを変更する際は、頻繁にAPersistentMap.javaとASeq.javaが併せて変更されていることが分かります。
コンウェイの法則
全てのコミッターのうち、33コミット以上しているのは、Rich Hickey, Stuart Halloway, Alex Millerの３人しかいません。
サブシステムで分析すると、JVM, ClojureパッケージはRich Hickeyが主開発者、Stuart HallowayがTestパッケージを主担当していることが分かります。
チームデリバリー
2016年には最大7人のコミッターがいましたが、ほとんどの期間は1人で活動しているのが分かります。
まとめ
Clojureプロジェクトは、主開発はRich Hickeyのワンマンプロジェクトで、Stuart Hallowayがテストを担当するという構図が分かります。GitHubのInsightではAlex Millerが３位にランクしているので、このプロジェクトの分析が2018年2月で止まっていることを差し引いても、もう少し多いのではないかと思ってGitHubのコミットログを見たところ、彼の変更のほとんどはRich HickeyかStuart Hallowayの名でコミットされていることが分かりました。https://github.com/clojure/tools.deps.alpha などの周辺リポジトリでは主体的に開発しているものの、コアの変更については常にこの二人の承認の元に変更されているということなのでしょう。
終わりに
私がCTOを務めているParksideでは、開発者がPRを作成した際に、コード品質に与える影響を評価したり、チームマネージャーとリードエンジニアの間で、現在のチーム編成とマイクロサービスのマッピングを評価したりする目的で活用しています。導入時にCodeSceneの開発者とミーティングをしたのですが、Clojureを使っている顧客は初めてということでした。ただし、当然彼らがCodeSceneを実装しているコードそのものをCodeSceneで評価する、いわゆるEat your own dog foodをしているので、Clojureは高い優先度でサポートしているとのことでした。
CodeSceneの開発者が、２冊の本を出版しています。CodeSceneのヘルプドキュメントより深く解説しているので、これらをガイドとして読むと、より理解が進むと思います。
