こんにちは。タイムリープ株式会社でソフトウェアエンジニアをやっております 
id:moznion です。
タイムリープ株式会社は遠隔接客サービス RURA (https://timeleap-rura.com/) を提供しているテクノロジースタートアップです。 このサービスは主としてブラウザで動作するReactアプリで構築されており、通信のバックボーンにはWebRTCを利用しています。 バックエンドのサーバーサイドコンポーネントはGoで作られていて、GraphQLとgRPCのServer-Streaming RPCを用いて通信することでサービスを実現しています。
さて色々なことがあり、このたび我々タイムリープ株式会社はテックブログを開始する運びとなりました。よろしくお願いいたします。
タイムリープのアプリケーションは7年間程度開発運用されており、その間何度かの改修を経て、現在はビジネス規模の拡張・拡大に応えるために新機能開発をしながら大規模なリファクタリング・リアーキテクティングが行なわれている状況となっています。
その改善作業の中、以下のような課題感が発生してきました:
- プロジェクト内のどの部分が不具合を生みやすいホットスポットなのかが定量的にわかりにくい
- 改善作業がどのように効いているのかを実感することができない *1
こういった課題に対応すべく、ソフトウェア工学的なアプローチによってこのあたりを可視化しようという取り組みを最近始めています。
ccccはRustで書かれたLanguage-agnosticかつ高速な循環的複雑度と認知的複雑度の測定ツールです。ccccおよび循環的複雑度と認知的複雑度の紹介は先月開催されたFindy オフラインシリーズ感謝祭 〜先陣たちの宴〜 で発表しましたので、そちらのスライドも併せて参照いただければと思います:
タイムリープでは、このccccによる循環的複雑度と認知的複雑度の測定をGitHub Actionsとk1LoW/octocovを用いて継続的に行なっており、例えばpull-requestが作られると以下のようなコメントが付くようになっています:
また、以下のようなリーダーボードが各GitHub Actionのサマリにも表示されるようにもしています:
こういった数値をトラッキングすることで、どのコードがホットスポットなのか (つまり数値が高いのか) を可視化できるようになり、なおかつ実際に発生した不具合と突き合わせることによって「実際にここがバグの温床になっているので、ここを優先度高く直しましょう」というようなコミュニケーションができ、ファクトに基いた開発ができるようになってきました。
一方、この数字だけをKPIとして追うこと自体にはあまり意味は無いのではないかと思っています。もちろん数値は低いに越したことはなく、また過度に大きな数値を持っているコンポーネントは明確に何かがおかしいと言えると思いますが、「数値を低くすること」だけを追い求めるようになるとそのための本質的ではないハックが横行することに繋ると思っています *2。 そもそもこの数値は一概に「何ポイント以下が良い」というふうに閾値を設けにくいものだと感じているため *3、これはある種のトレンド的なメトリクスとして追うのが良いのではないかと思っています。
例えば、
- 数値が増加傾向にあるコンポーネントはなんらか責務過多に陥いっているのではないかという兆候を察知する
- 大規模なアーキテクチャ変更を行なった時、その影響が全体的な数値として現われることによってターニングポイントとして認識する
- (あるいはその逆で) 数値が大きく変わったタイミングで何か大きな変更がもたらされたことを知覚する
- などなど
というような使い方が有意義なのではないかと今のところは考えています (上記スライドにも書いたこととして、AI時代は若干事情が変わるかもしれませんが……)。
最後に我々が利用しているGitHub Actions関連の設定を付記しておきます。ccccと併せてぜひご利用ください。
タイムリープでは複雑さと真っ向勝負できるエンジニアを募集しています。
