アットマーク・アイティ @IT@IT情報マネジメント@IT自分戦略研究所QA@ITイベントカレンダー  
 
 @IT > @IT ソフトウェアテスト・ミーティング レポート > テクマトリックス
 
@IT[FYI]

 

ソフトウェアの品質を上げるのは「良いコード」

ソフトウェアの品質を下げる悪いコードとは?

テクマトリックス 技術本部 第一技術部 プロダクトソリューショングループ グループリーダー 西田啓一氏

 そもそもソフトウェアとは、膨大な数のプログラムから成り立っているものだ。こうした観点で考えて「そのソフトウェアのコードが高品質であれば、ソフトウェア自体も高品質だといえます」と述べるのが、テクマトリックス 技術本部 第一技術部 プロダクトソリューショングループ グループリーダーの西田啓一氏だ。その理由として、西田氏は次のように続ける。「良いコードとはすなわち、第三者が見ても理解しやすい“読めるコード”であること。読めるコードであるということは、バグが少なく品質も安定している。また可読性が高いため、保守もしやすいというメリットがある」(西田氏)。

 確かにコードの良し悪しはソフトウェアの品質に深く関係する。例外処理で、ネストの深いtry-cahch文を不用意に使うとセキュリティホールを作ってしまうこともある。また、変数の生存期間が非常に長かったり、プログラム間の依存度が高くモジュール化できないものであるならば、その後の拡張性に支障を来たす恐れがある。もう少し詳しくプログラムの中味に入ると、たとえばdefaultのないswitch文や()を省略したif-else文、本体がなく空回りしているループ文なども「悪いコード」の1種だ。

 これらのコードは可読性を損なうだけでなく、デプロイ先の環境によってはパフォーマンスのボトルネックになるケースもある。つまり「良いコード」で書かれたソフトウェアは、必然的に品質が高いものであるといえる。「テスト工程の前段階で、いかに品質を高めることができるかを常に考えるべき」(西田氏)。

 そこでどうするか。西田氏は「良いコードをたくさん読むことが、品質の高いソフトウェアを作る道筋になる」と指摘する。「現在、オープンソースのコードがあふれているので、これを利用しない手はない」(西田氏)とも。参考にするコードの基準は、バグがないか、あるいはバグを招きがちなパターンが存在しないものであること。構造が単純化されているコードは、一見して可読性が高いと判断できる。こうしたものを参考に、自分の手でコードを書くことが、高品質なソフトウェアの開発につながるという。

ベア・プログラミングの重要性

 とはいえ、淡々とソースコードを読むだけで、本当に品質の高いソフトウェアが実現できるわけではない。西田氏はこの点に関して、3つの取り組みを薦める。「1つは、開発プロジェクトの中で優れたコードを書く先輩を見つけ、その人に直接教えを請うこと。かつてはOJTなどで、1本のプログラムを2人がかりで書くこともあったが、そうした慣習がなくなった現在、参考になるコードを書く人を真似てみるのも勉強の1つ」(西田氏)。

 確かにコードの「良い」「悪い」を判断するには開発経験がモノをいう。GUIベースの開発ツールに慣れすぎると、関数の知識も大雑把になり、それがソフトウェア全体の処理を遅くすることにもなりかねない。こうした事態を避けるためにも、開発経験の豊富なエンジニアと組み、ノウハウを習得することが必要になる。

欠陥コードの知識を蓄える

 2番目の取り組みとして西田氏が薦めるのが、テストツールの静的解析機能を利用し、ソースコードを解析してみること。プログラムの静的解析を行い、欠陥部分を指摘する「Jtest」などのツールを利用すれば、膨大なステップ数のプログラムも簡単に解析できる。

 もともと解析ツールは、コードの欠陥部分を警告することでソフトウェア自体の品質を向上させるという役割がある。西田氏は「テストフェイズで解析ツールを使うのではなく、普段の開発の中で積極的に利用することが、高品質のソフトウェアを作る近道」と述べる。Jtestの場合、バグの可能性や複雑な構造を持つ箇所、可読性の低い記述、保守性や移植性の低い箇所を指摘し、開発者への注意を促す。逆にいえば「良いコードを見つけてくれるツール」でもある。コードの段階からソフトウェアの品質を向上させるには、開発者自身が解析ツールを使いこなすことが必要だという。

 続けて西田氏は、JtestによるJakartaプロジェクトの分析結果を提示。対象となったのはECサイトのデモ用フレームワーク「PetShop1.2」、アプリケーションサーバ「Tomcat 4.x」、MVCフレームワーク「Struts」の3種類。「時間がなかったので、全部のコードの解析は未完了」(西田氏)としながらも、それぞれについて得られたMcCabe、バグ数、静的エラーの数を発表した。この結果によると、3つのうち検出されたバグ数が最も少なかったのがTomcat 4.xだ。また、静的エラーの数が最も少ないのはPetShop1.2。バグが少ないということは、それだけエンドユーザーの目に見えるエラーも少ないということにつながる。また静的エラーが少なければ、ソフトウェアのパフォーマンスが高いということだ。バグや静的エラーの発生率を少なくするパターンを身に付ければ、コードの質も向上する。

ノウハウの共有がソースコードの品質を上げる

 最後に、こうした取り組みの中で得たノウハウを開発チーム全体に還元することが挙げられる。西田氏は「JtestのRuleWizardを利用すれば、バグを起こしやすいパターンを登録することでソースコードにチェックをかけられるので、大規模プロジェクトにおいても一定の品質を保つことができる」と説明する。前述したような「悪いコード」のサンプルパターンを多数登録しておけば、それだけコーディングの段階でバグの発生率を抑えられるというわけだ。

当日行われたプレゼンテーション資料のダウンロード(PDF)が可能です。
ダウンロードボタンをクリックしてください。→



主催:アイティメディア株式会社
協賛各社(順不同):マイクロソフト株式会社、
エンピレックス株式会社、
テクマトリックス株式会社、
マーキュリー・インタラクティブ・ジャパン株式会社
株式会社ベリサーブ
掲載内容有効期限:2005年7月24日
 

関連リンク

テクマトリックス
テクマトリックス 製品ダウンロード

− @IT PR −

ITアーキテクト フォーラム

ソフトウェア開発の課題を分析・設計から考える情報フォーラム

@IT 関連コンテンツ

隣のテストチームが優秀ないくつかの理由(前編)
(IT Architect)
隣のテストチームが優秀ないくつかの理由(後編)
(IT Architect)
電気通信大学 西康晴氏に聞く、テスト技術の未来
(IT Architect)
テスト計画の立案
(IT Architect)
テスト駆動開発はプログラマのストレスを軽減するか?
(Insider .NET)
継続的インテグレーション&テスト環境の構築
(IT Architect)
モデル駆動型ソフトウェアテストの可能性
(IT Architect)
テスト設計の基本とさまざまなテスト技法
(IT Architect)
テスト計画が失敗する原因、その回避策
(IT Architect)
テストという破壊的な作業の建設的なやり方
(IT Architect)
テスト設計の方針は千差万別
(IT Architect)
テストの自動化、その最新事情
(IT Architect)
システムの内部動作を視覚化する
(IT Architect)
システムの不具合を予防する方法
(IT Architect)


 
@ITトップ@IT Special インデックス会議室利用規約プライバシーポリシーサイトマップ