UIフレームワークだけじゃない！ソフトウェア品質もサポートするQt
「ソフトウェアにバグが多い」「複雑過ぎて読み解くのが困難」「メンテナンス性が悪い」など、ソフトウェア品質に課題を感じている開発者も多い。そんな課題をかかえる開発プロジェクトを支援するソリューションを提供しているのがQt Group（以下、Qt）である。
Qtと言えば、C++アプリケーションのUIフレームワークを提供しているイメージを持つ方も多いだろう。だが、同社は2021年4月、GUIの動的テストツールを提供する froglogic GmbH社を買収。翌2022年8月には、静的解析ツール「Axivion Suite」を提供するAxivion GmbH社を買収した。
「Qtはアプリケーション開発フレームワークから品質改善、テスト自動化まで製品ポートフォリオを拡げ、ソフトウェアの開発サイクル全体を一気通貫でサポートし、開発効率と品質を向上させることをミッションに事業を展開しています」と、QtでAxivion Suiteの営業活動に携わる、シニアアカウントマネージャーの小幡剛士氏は説明する。
Axivionは、ソフトウェアがそのライフサイクルの中で開発や修正が加えられていくことでもたらされる不利益について、過去15年以上にわたり研究していたドイツ・シュトゥットガルト大学の研究チームが、そのアイデアを基にスピンアウトとして設立された企業である。「ヨーロッパではボッシュやシーメンスなど、ソースコードの安全性や妥当性への担保が必要とされる大手企業が導入していることからもわかるように、非常に信頼されているソリューションです」（小幡氏）
ソフトウェア品質が劣化してしまう6つの要因
一般的に静的解析ツールは、クリティカルな不具合をピンポイントで検出するなど、即効性にフォーカスしたものが多い。Axivion Suiteはそれだけではなく「ソフトウェアの劣化」を防ぐことをミッションに掲げている。なぜならソフトウェアは時間の経過とともに、ビジネス要件から求められる機能の追加や、ソースコードの修正などが繰り返されることで、どうしても複雑度が上がり、品質が劣化してしまうからだ。
品質が劣化してしまう要因は「大きく6つに分類できる」とソリューションエンジニアの平井幹生氏は言う。
第一の要因は「アーキテクチャ違反／隠れ依存性」。これはアーキテクチャ仕様に定義されているソフトウェアコンポーネントの依存関係と、実際に実装されている依存関係が一致していなかったり、仕様にない依存性（隠れ依存性）がソースコードに存在していたりする状態を言う。これの何が問題なのか。アーキテクチャ違反や隠れ依存性があると、ソースコードを理解するときに、毎回コードを読まなければならず、新規の変更や不具合の修正を計画する際に、影響箇所の検討などが難しくなるという問題があるからだ。
第二の要因が「コードクローン」。似たようなソースコードが同じプロジェクトの中に複数存在する状態のことを指す。コードクローンは、既に動いているコードをコピー＆ペーストして使ってしまうことで起こるという。「コピー元のコードにバグがあれば、そのバグが拡散され、それらのバグを修正しなければなりません。バグ修正に工数がかかることに加え、どこにクローンがあるか分からない状態になると、バグが残ったままになってしまうという問題が生じます」（平井氏）。
第三の要因が「メトリクス違反」。メトリクスはソースコードの複雑性を定量的に把握するための方法だ。例えば1つの関数内のソースコードの行数などを測ることもその一つだ。例えば関数内の行数を150行以下に抑えるなど、測定対象と閾値を適切に設定してモニタリングすることで、ソフトウェアの劣化が防げる。
第四の要因が「スタイル違反」。これはMISRA（Motor Industry Software Reliability Association）やAUTOSAR C++などの業界で定義されているコーディングスタイルや、プロジェクト独自のコーディングルールに対して違反するコードを指す。「CやC++は、開発者のスキルが如実にコードに表れる傾向があり、ミスしたときの影響も大きいです。プロジェクトで従うコーディングスタイルを決めてしまうことで、コード品質を底上げすることができます」と平井氏は説明する。
第五の要因は「デッドコード」。文字通り、死んでいる＝使用されていないコードのことを指す。単純に動くべきコードが動いていないのは単純なバグだが、「問題はそれだけではない」と平井氏は指摘する。
開発者はソースコードを読むのに多くの時間をかけている。研究結果によると「作業の40％は自分で書いたコードを読むのに使っている」と報告されているという[1] 。デッドコードを読む時間はもちろん、デッドコードに対して単体テストを記述する工数も無駄である。それだけではない。意外と見過ごされているのが、他の部分が進化することでデッドコードが復活してかみ合わなくなり、新たなバグになってしまうこと。デッドコードには復活のリスクもある。
[1] 参照：Zelkowitz et al (1979), Eastwood (1993), Marliss, Ben-Menache (1997), Erlikh (2000)
第六の要因が「循環依存性」。これは依存関係が循環している状態を指す。例えば関数Aが関数Bをコールし、関数Bも関数Aをコールしたり、関数Bがコールする関数Cが、関数Aをコールしていたりするようなケースである。環境依存性のあるコードは無限ループのリスクがあるだけではなく、読むのも大変で、必然的に時間もかかってしまう。
ではこれらの要因をなくし、ソフトウェア品質を保つために開発の現場ではどういった対策がとられているのか。現在、多くの開発現場で行われている手段は、「目視でのコードレビューです」と平井氏は言う。
Axivion Suiteは、これら6つの要因に加え、他のテストでは発見が難しいバッファオーバーフローやリソースリークといったランタイムエラーを検出します。
Axivion Suiteの事例を公開中
Axivion Suiteは、世界的な大企業で広く採用されています。以下より、自動車関連、エレクトロニクス、医療業界の4社の事例をまとめたPDFをダウンロードいただけます。ぜひご覧ください！
