このブログについて

ソフトウェア開発におけるエラーの予防やプロジェクト管理、品質管理を支援するParasoft製品のTIPSなどを、国内総販売代理店テクマトリックスのサポートスタッフが紹介しています。
ラベル 継続的インテグレーション の投稿を表示しています。 すべての投稿を表示
ラベル 継続的インテグレーション の投稿を表示しています。 すべての投稿を表示

2016年5月11日水曜日

ソースコードに技術的負債を溜め込んでいませんか?


“とりあえず動く”コード

 納期間際になって不具合が見つかった状況を考えてみます。選択肢は2つあります。一つは設計から見直し、コードを変更してテストも行うことですが、納期に間に合わないかもしれません。

 もう一つはとりあえず不具合を解消するよう深く考えずにソースコードを変更することです。納期に間に合ってプログラムも正常に動いている模様ですが、その後の変更時に影響範囲が大きかったりソースコードの意味が分からなかったりして、不具合の修正や機能追加が大変になる、あるいはコードをいじれない、という事態が待ち受けています。

 あなたのプロジェクトは2つ目のような事態に陥ってはいませんか?

技術的負債とは?

 2つ目の選択肢のような「とりあえず動くが、後から変更が大変なコード」は「技術的負債」と呼ばれています。技術的負債は単にソースコードが汚くて読みにくいコードだけでなく、次のようなコードも当てはまります。
  • テストケースが作られていないコード
  • 設計を推敲せずに書かれたコード
  • 別のところからコード断片をコピー&ペーストしたコード
 これらが溜まってくると、コードを修正して良いのかどうか、何のためのコードなのかが分からなくなってきます。その結果、次のような問題に発展していきます。
  • 変更に時間がかかる
  • テスト工数が膨らむ
  • リリースが遅れる
  • リリース後も障害が起きる
 このような問題に発展する前に、リリースまでに技術的負債を極力減らしておく努力が必要です。作られてしまった技術的負債を減らす方法は唯一、リファクタリングを行い、地道にコードをきれいにすることです。しかしリファクタリングを行うにも工数が必要ですから、技術的負債の量や、技術的負債に対処しなかった場合のビジネス上の影響、プロジェクトの進捗などといったものとのバランスを見て行わなければなりません。

技術的負債の計測と可視化

 では技術的負債の量はどのように求めたら良いでしょうか? 技術的負債の構成要素としては、コーディング規約違反の件数、メトリクスの超過/過少の量、単体テストの失敗件数、テストで未到達なコードの量、等が考えられます。一例として、SQALEメソッドにおいて技術的負債の計算方法が例示されていますので、参考になると思います。

 技術的負債を定義したら、次は技術的負債の構成要素を計測します。計測方法は要素によって異なりますが、コードレビュー時に確認したり、単体テストを実行したり、静的解析や構造解析のツールを利用することが一般的です。弊社取扱製品であるParasoft JtestParasoft dotTEST, Parasoft C++testといったテストツールももちろん利用できます。

 最後に、各要素から技術的負債を計算してプロジェクトメンバーに提示します。先程例として挙げたSQALEメソッドに従うと、技術的負債は単純な四則演算で計算できますので、表計算ソフトでも計算できます。あるいは弊社取扱製品であるParasoft Development Testing Platform (Parasoft DTP) を使用すると、技術的負債を計算する手段が予め提供されている他、技術的負債がモジュールや品質特性ごとに計算され、かつWebブラウザで確認できます。WebブラウザでParasoft DTPにアクセスすれば、下図のようにどこにどれくらいの技術的負債が溜まっているかをいつでも誰でも確認できるため、技術的負債を減らすためにリファクタリングを開始する動機付けが可能になります。


 また、継続的インテグレーションの中に技術的負債の計測を組込むことで、現在のプロジェクトの技術的負債の状況をリアルタイムに近い形で確認することが可能になります。技術的負債が増加していることをリアルタイムに把握できれば、リーダーの方がリファクタリングを開始するよう指示して早期にプロジェクトを軌道修正することも容易に可能になります。

技術的負債を計測しませんか?

 いかがでしたでしょうか。技術的負債とは何か、技術的負債が溜まるとどうなるか、技術的負債を算出して可視化する方法をご説明いたしました。読者の方が技術的負債を返済し、将来の変更の労力を少しでも減らすことができればと思います。

 最後に、上記で紹介しました弊社取扱製品はすべて2週間無償でご評価いただけますので、購入を検討されたい方は下記からぜひお試しください。またParasoft DTPのユーザー様向けに、技術的負債を計算するためのプラグインも提供しておりますので、ぜひご利用ください。



Parasoft DTPプラグイン提供ページ

2015年10月8日木曜日

Jtest DTP・Parasoft DTP を利用した短期・高品質開発

短期・高品質開発を実現する仕組みとは?

今回は、Jtest DTPとParasoft DTPを組み合わせた短期・高品質開発を実現する仕組みをご紹介します。

短期・高品質開発を実現するJtest DTP、Parasoft DTPの仕組みは以下の通りです。
図の仕組みに関して詳細にご説明いたします。

①継続的インテグレーションによる問題早期発見

継続的インテグレーション導入により、ビルド・インスペクション・テスト・パッケージング・リリースを継続的に実行し、開発・テストプロセスで発生する問題の早期発見が可能です。「問題点→対策」の一例を以下に示します。

  • ビルドが壊れた!→コンパイル不能なコードを特定しビルドが通るように修正
  • インスペクションで指摘が発見された!→バグの場合は早期に修正
  • テストが失敗した!→バグの場合は早期に修正
  • 上記すべてを合わせて、リリース可能なモジュールか判断可能!

特に、Jtest DTPによるインスペクション・テスト自動化により、コーディング工程で結合レベルのバグを早期発見したり、人の目では追えない複雑な処理(Exception発生時の処理等)で発生する問題を特定することができ、早期に品質を向上させるための基盤を整えることができます。

※Jtest DTPで検出できる指摘については詳しくはJtestとOSSとの違いを参照ください。

②Parasot DTPによる問題点可視化・リスク分析

継続的インテグレーションで発生した問題を眺めているだけでは、何も解決しません。問題が改善しているのか、リアルタイムで確認する必要が出てきます。

Parasoft DTPでは、インスペクション、テスト、メトリクス、ビルド等さまざまな情報を一元的に収集して表示できます。ウィジェットの一例を示します。

問題の発生状況をリアルタイムで確認

ウィジェット概要
指摘事項の傾向を表示し、改善しているかを確認できます。
ソースコードメトリクスに順守して開発しているかを表示します。赤は指摘、緑は順守していることを示します。
Jenkinsのジョブの状況を表示します。

多角的なデータからリスクを特定し、自動的に優先度付け

ウィジェット概要
モジュールのビジネスリスク・セキュリティリスク・指摘数からリスクのあるモジュールを特定します。
Googleのバグ予測スコア・サイクロマチック複雑度・コードボリュームから複雑でバグの混入確立が高いコードを特定できます。

③優先度付けされた指摘の取り込み、修正と生産性の高い開発

開発者は優先度付けされた指摘事項やテスト結果をIDEに取り込めます。 普段使いなれたIDE上で確認ができるので 生産性の高い開発も実現できます。

EclipseとIntelliJ IDEAに指摘を取り込んだ画面



開発者の手元でも解析を行えるので、チェックイン前のコードの品質を高めることができます。

最後に

いかがでしたでしょうか。Jtest DTPとParasoft DTPを組み合わせることで早期に問題を発見し、改善状況をリアルタイムにモニタリングできます。また、多角的な情報からリスク分析することで、ソフトウェア開発をより潤滑に進められるのではないでしょうか。

今回ご紹介した Jtest DTP、Parasoft DTPに関するセミナーを10月23日に実施いたします。

セミナーにつきましては、以下の記事で詳しく紹介していますので、ぜひこちらも御覧ください。

「2015年10月23(金)開催セミナー JALインフォテック様における旅客システム開発の品質向上事例紹介!」



また、Parasoft DTPの体験版もご用意しておりますので、ぜひお問い合わせください。