処理時間のバグへの対策を以下に示します。
要求仕様で処理時間を記載する場合、無理のない現実的な値を定義しましょう。この値によっては、プロジェクトの進行が大きな影響を受ける可能性があります。また、応答性能を実現できなかった場合、どのように対処するか、事前に考えておきましょう。
応答性能がクリティカルなソフトウェアでは、要求仕様定義の段階で、コアになる部分を2、3日でコーディングして実行し、目標とする応答性能が可能であることを事前に確認しましょう。「この応答性能を出すには、東京−大阪間の通信を120nsで終了しなければならない」といったような「物理的に不可能な桁違いの処理要求」を検出できます。
パフォーマンス解析ツールを使用し、ボトルネック(プログラムのどこに時間を取られているか)のランキングを作成しておきましょう。あらかじめ調べておけば、応答性能系のバグ発生時に慌てることなく対処できます。
処理時間が重要なプログラムの場合、以下の記述方法に気を付けましょう。
上記は、昔ながらの処理高速化の手法ですが、少しでも改善したい場合は効果があります。また、シニアエンジニアに聞くと、マニアックな改善手法を提案してもらえるかもしれません。
今回のまとめを以下に示します。
ハードウェアの能力は昔と比べて格段に向上しましたが、性能要求を満たせず慌てることが少なくありません。今回は、その中でも、処理時間のバグを紹介しました。
処理時間のバグが発生すると、どうやって目標の応答時間内に収めるか、対処法をキチンと考えねばなりません。また、実機でやってみないと確かめられませんので、未然防止が非常に難しいバグです。処理時間が求められる製品を開発しているエンジニアは、常に頭に置いておくべきバグです。
今回でシリーズの12回目となり、いろいろなバグの知識や、バグを見つける嗅覚が身に付いたことと思います。他のバグを知りたい方は、本連載の過去記事や、前シリーズの「バグ検出ドリル」、以下に紹介する書籍版の「ソフトウェア技術者のためのバグ検出ドリル」をご参照ください。
山浦恒央先生が執筆した書籍「ソフトウェア技術者のためのバグ検出ドリル」が日科技連出版から発売中です。本連載「山浦恒央の“くみこみ”な話」とTechFactoryの連載「組み込みエンジニアの現場力養成演習ドリル」をベースに、大幅加筆、改訂した内容になっています。
内容は、「デバッグの詰将棋」で、要求仕様定義、設計、コーディング、テスト、保守の5フェーズでの「バグを埋め込んだ仕様記述やソースコード」を読んで、バグをピンポイントで見つける問題集になっています。全部で31問あり、難易度は初級から上級まで、いろいろです。興味のある方は、Amazon.comや書店でチェックしてください!
東海大学 大学院 組込み技術研究科 非常勤講師(工学博士)
Copyright © ITmedia, Inc. All Rights Reserved.