🕌

Code Climate Qualityを使ってコードの品質を可視化した話

2023/01/04に公開約2,700字

この記事を書いている間に年が明け、2023年が始まりました。皆様いかがお過ごしでしょうか?
今回の記事を書いているのもIです。引き続きよろしくおねがいします!

技術的負債

みんせつに限ったことではありませんが、どんなプロダクトにも様々な歴史があります。

仮にそのアプリケーションが今はとても複雑で巨大なモノリスであったとしても、生まれたばかりの頃は、少なくとも今より見通しが良かったはずです。

その世界は(場合によるとは思いますが)機能は今よりも多くないはずで、ファイルの数やクラスの数、メソッド(関数)の数も少なく、依存関係も比較的明快で……。
物事は今よりもっと単純で、過ごしやすい世界だったかもしれません。

しかしプロダクトの成長に伴ってその過ごしやすい世界は拡張され、クラスには贅肉が付き、ファイル人口は増加し、それらの依存関係は複雑になっていきます。
それらを動かすインフラやミドルウェアも、開発リソースの不足などの理由でメンテナンスがおざなりになってしまうかもしれません。

成長のためスピードを重視する必要がある等の理由があるとき、我々はこれを技術的負債と呼び、一時的には受け入れると思います。
しかしその負債をすぐに返済できるとは限りません。

  • リファクタリングに割けるほどのリソースがない
  • リファクタリングの手段が定まっていない
  • まだそのフェーズではない
  • そもそもアプリケーションの完成とは何なのか

組織によって理由は他にもあると思いますし、そもそも技術的負債にもいくつか種類があるかもしれません。
こういった諸問題をここで細かく見ていくことはできませんが、みんせつ開発チームはこれらの技術的負債を一気に解消していくべきフェーズに入りました。
(もっと背景が知りたい方はココを参照してください)

みんせつにCode Climate Qualityがあらわれた

負債の解消フェーズへと移行して間もなく、私の上司に当たるT郎さんがJoinしました。
そのT郎さんがCode ClimateのQualityというツールを連れてきてくれました。

技術的負債を大まかに見積もることが目的とのことだったのですが、当初私は見方がよくわからず、具体的にどう活用できるのかも見えていませんでした。
同僚も私と同じような疑問を抱えていたため、これ is 何?を実際に一緒に触りながら考えてみました。

先に私と同僚の感想を記すと、とても便利そう! です。

ダッシュボード

dashboard

私と同僚は、このダッシュボードが何を意味するのか?から見ていくことにしました。

結論だけ記載すると以下です

  • MAINTAINABILITYは品質ランク的なもので、修正までにかかる時間も表示される
  • 私達のアプリケーションは、今後絶対に負債が増えないとしても、リファクタリングだけで1年はかかるらしい
  • Code Climate Qualityのデフォルト基準が一般的に厳しいかどうかはわからないが、今の我々には厳しすぎる(GitHubと連携させると、プルリクエストでの指摘が多すぎて対応できなかった)
  • パンドラの箱を開けた気分になった

要約すると最後の一つに尽きるのですが、少しでも現状を良くすることにつながればと思い、改善を続けていきます。
T郎さんの貢献も多分にあり、メインの業務として改善や信頼性の向上に注力できるようになったのですから!

trends

(他のタブは機密情報にあたるものが多いため飛ばしています)
このタブのこの項目を見たとき、私と同僚はこれがどういうもので何に役立つのか、そもそもChurnとは何なのかを知りませんでした。

公式ドキュメントによると、Churnは一定期間内のファイルの変更回数で算出されるそうです。

Churnだけでなにかの役に立つというわけではなく、品質と一緒にみて現状を把握するために使うそうです。
そのためにChurn vs. maintainabilityがあるのです。
(ちなみに、グラフにある1つの丸は1つのファイルです。)

私と同僚がこのように分けられるのでは?と思ったことを表とともに記すと下記です。
groups
赤青緑でおおまかにこの付近はこうかな?と思ったことをまとめてみました。

  • 赤: 変更量が多く品質も低いため、複雑になりすぎる前に多少リファクタリングしたほうがいいかも?
  • 青: 変更がない割に品質が低いため、今が修正チャンスかも。そもそも使われていないモノであれば対処を考えるべき……?
  • 緑: 良くも悪くも安定している物が多いゾーン。特に右上付近は悪化しないように注意しなければならないかも?

これが正しいのかわからないので、初見時の感想として受け取ってください。
活用事例などあればぜひ教えて下さい!

まとめ

Code ClimateのQualityを使って、定義された基準とどれだけ乖離しているか(どこがどれだけ品質が低いか)を見ました。
今後みんせつでこのツールを積極的に活用していくかはわかりませんが、私と同僚は今どういった状況かをより具体的に把握できたはずです。

他にも同様のツールがいくつかあるので、こういったツールを本格的に利用する時が来たら、使い勝手を比較しながら選定を行う予定です。
また新しくツールを触った際は、使い勝手を比べてみながら記録として書き記そうと思います。

2023年も継続してアプリケーションの信頼性向上を行っていきます。
小さく確実に完了できるところから鋭意改善中です。

Discussion

ログインするとコメントできます