[3]の検索結果
バグのないソフトウェアはない、というくらいソフトウェアにはバグがつきものですが、ソフトウェアの開発プロジェクトには期間や予算に上限があるため、バグの修正に手間取ると十分なテストを実施することができず、品質が低い状態でリリースされてしまうことになります。テストを円滑に進めソフトウェアの品質の高めていくためには、バグを迅速かつ正確にバグを修正していく必要があります。
しかし、オブジェクト指向プログラミング(OOP)やデザインパターンなどプログラムの作り方についての解説書や記事はたくさんあるにも関わらず、「バグは本来あってはいけないもの、あるはずが無いもの」という意識があるためか、デバッグに関して語られている情報源はあまり多くありません。そのため、デバッグのテクニックについてはせいぜい「開発現
場の先輩に教えてもらう」というのが実情です。
知識を共有するために、私がこれまでのソフトウェア開発の経験から得た、デバッグを効率的に行なうための心得をいくつか挙げてみたいと思います。
1. バグの原因は自分が作っているプログラムにある可能性が最も高い
ソフトウェアを構成する要素として、OS、開発ツールに付属するライブラリ、市販ライブラリ、プロジェクト内で作成されたライブラリなどがありますが、バグの原因は自分が作っているプログラムである可能性が最も高いと考えたほうがすばやくバグを見つけられます。なぜなら、今まさに開発が行なわれているプログラムこそが最もテストされていないプログラムだからです。問題の原因をマイクロソフトのせいにする前に自分のプログラムを調べましょう。
2. テストの実施を妨げているバグを優先する
当然のことですが、テストができなければバグを見つけることができません。効率的にバグが発見できるように、めったに行なわれない操作によって発生するバグよりも、必ず行なわれる操作で発生するバグを優先的に修正していく必要があります。
3. 問題を確実に再現できるようする
問題が発生する条件(操作手順、データなど)を必ず特定しなければなりません。これができないと動作確認は不可能ですので、修正したつもりが実は直ってなかったという事態にもなりかねません。この作業自体はソースコードがなくても可能なので、テスト担当者の協力を得られるのであれば、情報を交換しながらテスト担当者と開発担当者が並行して調査を進めるのが良いでしょう。
4. 一度でも問題が発生した場合はバグがある可能が高いので必ず調査する
一度でも問題が発生した場合は、単にバグが発現する条件がわかっていないだけで、必ずどこかにバグがあります。開発作業中はいろいろプレッシャーがあるので難しい面もありますが、見つけた時点で調査しておいた方がいろんな面で良いでしょう。
5. ソースコードを見ただけで正しい処理が行なわれていると判断しない
プログラムはプログラマが思っている通りに動くのではなくコンパイラが解釈した通りに動くものです。コンパイラについての知識が豊富なプログラマが犯しがち問題ですが、プログラマがコンパイラの仕様について誤解しているために生じるバグもよくあります。プログラマ自身は正しいと思っているためソースコードを見ただけではバグを発見することが困難ですがが、このようなバグは実際にプログラムを動かしてみることで簡単に原因を発見することがきます。
6. 想定外の操作や想定外のデータが使用されていないかチェックする
プログラムはプログラマが想定していなかった操作が行なわれたり、想定外のデータが入力されたりした場合は正しく動作しないことが多いものです。問題を発生させる操作やデータがプログラムで想定されているかチェックしてみましょう。
7. バグの原因となっているソースコードは必ず特定する
関係の無いところを直しても問題の現象が発生しなくなる場合もありますが、それでバグが無くなったわけではありません。そのような場合は、また別のところで別のかたちで問題が発生することになりかねません。バグは必ずソースコードレベルで原因を特定し確実に修正すべきです。
8. できるだけ他の処理に影響を与えないようにソースコードを修正する
他の処理に影響を与えるような修正を行なった場合、これまで問題なく動いていた部分に新たなバグを埋め込んでしまう可能性が高いものです。別の問題を引き起こさないように、影響範囲に注意してソースコードを修正します。しかし、単なるコーディング上の間違いであればプログラムの修正は比較的簡単で他の処理に影響を与えることは少ないのすが、設計に問題がある場合は他の部分の影響を与えないようにバグ修正を行なうのが難しい場合があります。そのような場合は、本質的な問題の解決にはならないとしても、影響範囲を限定するために暫定的な対処を行なった方が良いでしょう。
9. ソースコードを修正した場合は必ずテストする
たとえ簡単な修正であっても間違った修正を行なう可能性は常にあります。また、修正が思わぬところに影響を与えることもあります。当たり前ですが、ソースコードを修正した場合は必ずテストを行ないましょう。テスト作業を手を抜くよりも、テストを行なった方がトータル見れば開発者自身にとっても負担が少ないはずです。
しかし、オブジェクト指向プログラミング(OOP)やデザインパターンなどプログラムの作り方についての解説書や記事はたくさんあるにも関わらず、「バグは本来あってはいけないもの、あるはずが無いもの」という意識があるためか、デバッグに関して語られている情報源はあまり多くありません。そのため、デバッグのテクニックについてはせいぜい「開発現
場の先輩に教えてもらう」というのが実情です。
知識を共有するために、私がこれまでのソフトウェア開発の経験から得た、デバッグを効率的に行なうための心得をいくつか挙げてみたいと思います。
1. バグの原因は自分が作っているプログラムにある可能性が最も高い
ソフトウェアを構成する要素として、OS、開発ツールに付属するライブラリ、市販ライブラリ、プロジェクト内で作成されたライブラリなどがありますが、バグの原因は自分が作っているプログラムである可能性が最も高いと考えたほうがすばやくバグを見つけられます。なぜなら、今まさに開発が行なわれているプログラムこそが最もテストされていないプログラムだからです。問題の原因をマイクロソフトのせいにする前に自分のプログラムを調べましょう。
2. テストの実施を妨げているバグを優先する
当然のことですが、テストができなければバグを見つけることができません。効率的にバグが発見できるように、めったに行なわれない操作によって発生するバグよりも、必ず行なわれる操作で発生するバグを優先的に修正していく必要があります。
3. 問題を確実に再現できるようする
問題が発生する条件(操作手順、データなど)を必ず特定しなければなりません。これができないと動作確認は不可能ですので、修正したつもりが実は直ってなかったという事態にもなりかねません。この作業自体はソースコードがなくても可能なので、テスト担当者の協力を得られるのであれば、情報を交換しながらテスト担当者と開発担当者が並行して調査を進めるのが良いでしょう。
4. 一度でも問題が発生した場合はバグがある可能が高いので必ず調査する
一度でも問題が発生した場合は、単にバグが発現する条件がわかっていないだけで、必ずどこかにバグがあります。開発作業中はいろいろプレッシャーがあるので難しい面もありますが、見つけた時点で調査しておいた方がいろんな面で良いでしょう。
5. ソースコードを見ただけで正しい処理が行なわれていると判断しない
プログラムはプログラマが思っている通りに動くのではなくコンパイラが解釈した通りに動くものです。コンパイラについての知識が豊富なプログラマが犯しがち問題ですが、プログラマがコンパイラの仕様について誤解しているために生じるバグもよくあります。プログラマ自身は正しいと思っているためソースコードを見ただけではバグを発見することが困難ですがが、このようなバグは実際にプログラムを動かしてみることで簡単に原因を発見することがきます。
6. 想定外の操作や想定外のデータが使用されていないかチェックする
プログラムはプログラマが想定していなかった操作が行なわれたり、想定外のデータが入力されたりした場合は正しく動作しないことが多いものです。問題を発生させる操作やデータがプログラムで想定されているかチェックしてみましょう。
7. バグの原因となっているソースコードは必ず特定する
関係の無いところを直しても問題の現象が発生しなくなる場合もありますが、それでバグが無くなったわけではありません。そのような場合は、また別のところで別のかたちで問題が発生することになりかねません。バグは必ずソースコードレベルで原因を特定し確実に修正すべきです。
8. できるだけ他の処理に影響を与えないようにソースコードを修正する
他の処理に影響を与えるような修正を行なった場合、これまで問題なく動いていた部分に新たなバグを埋め込んでしまう可能性が高いものです。別の問題を引き起こさないように、影響範囲に注意してソースコードを修正します。しかし、単なるコーディング上の間違いであればプログラムの修正は比較的簡単で他の処理に影響を与えることは少ないのすが、設計に問題がある場合は他の部分の影響を与えないようにバグ修正を行なうのが難しい場合があります。そのような場合は、本質的な問題の解決にはならないとしても、影響範囲を限定するために暫定的な対処を行なった方が良いでしょう。
9. ソースコードを修正した場合は必ずテストする
たとえ簡単な修正であっても間違った修正を行なう可能性は常にあります。また、修正が思わぬところに影響を与えることもあります。当たり前ですが、ソースコードを修正した場合は必ずテストを行ないましょう。テスト作業を手を抜くよりも、テストを行なった方がトータル見れば開発者自身にとっても負担が少ないはずです。
当サイト(掲示板 59bbs.org)で開発、サイトの運用に使用しているレンタルサーバー向けの掲示板フリーソフト(GPL)「59bbs」を無料で配布しています。
59bbs の特徴
59bbs はオープンソースのブログソフトウェアである「59Tracker」をベースに、掲示板として必要な機能を絞りこんで実装したフリーの掲示板ソフトです。プログラムはPerlで記述されており、PerlのCGIが利用可能なレンタルサーバーやホームページスペース、イントラネットサーバー等にインストールして利用します。MySQLやPostgreSQLなどのデータベースサーバーは必要ないため、格安レンタルサーバーやISPのホームページスペース等のデータベースやPHP、ASP.netが利用できないサーバーでも設置可能です。
- 検索機能を中心としたシンプルで使いやすいユーザーインタフェース
- 無料で商用利用やカスタマイズが可能なオープンソースライセンス(GPLv2)
- 複数ユーザー対応(ライセンス上も機能的にも上限なし)
- RSSフィードの配信
- ユーザー毎、記事毎の広告管理機能
- トラックバックPingの受信機能及び送信機能(登録ユーザーのみ)
- ブログエディター(XML-RPC API)対応
- データベースシステム不要
- 更新Ping送信
- サイトマッププロトコル対応
59bbs のインストールにおすすめのレンタルサーバー
59bbsをインストールに最も適したレンタルサーバーは、当サイトでも利用(※)している「さくらインターネット」です。 さくらインターネットのレンタルサーバーであれば、特に追加のモジュール等は必要とせずに、59bbsのファイルをアップロードしCGIファイルの属性を設定するだけで利用することができます。※掲示板 59bbs.org ではさくらのレンタルサーバ・スタンダードプランを利用しています。
59bbs のレンタルサーバーへの設置方法(さくらインターネット、ハッスルサーバー編)
ダウンロード
59bbs 3 のダウンロード 最新版59bbs 2.2のダウンロード
59bbs 2.1のダウンロード
59bbs 2.0のダウンロード
技術情報
59bbs 3.0 仕様書 59bbs 2.2 リリースノート59bbs 2.1 仕様書
59bbs 2.1 リリースノート
59bbs 2.0 仕様書
関連記事
オープンソース掲示板ソフト(PHP、MySQL)無料サーバー、格安レンタルサーバー(MT、WordPressも利用可能)
警視庁が北沢署地域課の巡査長の私物PCから警察情報を含む約1万件の情報が流出したと発表。
警視庁の警察情報など1万件がWinnyに流出 巡査長のPCがウイルス感染
http://blog.livedoor.jp/dqnplus/archives/988545.html
掲示板サイト「2ちゃんねる(http://2ch.net/)」に警察情報が流出していると書き込まれたことから、調査を進めた結果、流出を確認。巡査長の私物PCが、Winnyを通じてファイルを流出させるウイルス「仁義なきキンタマ」に感染していたとされる。
流出した捜査資料の中には広域暴力団山口組系後藤組の関係者名簿も含まれており、その中で情婦と記載されていた芸能人のブログが炎上、コメント欄が閉鎖される騒ぎになっている。
また、この件の情報収集のために2ちゃんねるに企業(テレビ東京、朝日新聞など)や政府機関(衆議院、総務省など)のからアクセスした人が、2ちゃんねるのフシアナトラップ(名前欄にfusianasanと入力すると投稿者のホスト名が曝されるトラップ、http://ansitu.xrea.jp/guidance/?fusianasan)に引っ掛かりホスト名を曝されるという事態も発生し、2ちゃんねるでは「祭り」状態となっている。
なお、警察庁は2006年3月に警察官の私物PCについてもWinnyの使用を禁止する通達を出している。
警視庁の警察情報など1万件がWinnyに流出 巡査長のPCがウイルス感染
http://blog.livedoor.jp/dqnplus/archives/988545.html
掲示板サイト「2ちゃんねる(http://2ch.net/)」に警察情報が流出していると書き込まれたことから、調査を進めた結果、流出を確認。巡査長の私物PCが、Winnyを通じてファイルを流出させるウイルス「仁義なきキンタマ」に感染していたとされる。
流出した捜査資料の中には広域暴力団山口組系後藤組の関係者名簿も含まれており、その中で情婦と記載されていた芸能人のブログが炎上、コメント欄が閉鎖される騒ぎになっている。
また、この件の情報収集のために2ちゃんねるに企業(テレビ東京、朝日新聞など)や政府機関(衆議院、総務省など)のからアクセスした人が、2ちゃんねるのフシアナトラップ(名前欄にfusianasanと入力すると投稿者のホスト名が曝されるトラップ、http://ansitu.xrea.jp/guidance/?fusianasan)に引っ掛かりホスト名を曝されるという事態も発生し、2ちゃんねるでは「祭り」状態となっている。
なお、警察庁は2006年3月に警察官の私物PCについてもWinnyの使用を禁止する通達を出している。
副島隆彦氏が率いる物書き集団「副島国家戦略研究所」が、属国日本のウソ・欺瞞・虚妄を暴きあげる。1.安倍晋三の奇怪な変節と「ザ・カルト・オブ・ヤスクニ」2.大衆世論を操縦せよ!3.日本銀行はロスチャイルドがつ...
C++は、広く普及しているプログラミング言語のC言語にオブジェクト指向的な拡張を施したプログラミング言語で、クラスや標準ライブラリである、STL(標準テンプレートライブラリ)を利用することで効率的にプログラムを...
「Happy Hacking Keyboard(ハッピーハッキングキーボード、HHKB)」は、PFUがパワープログラマ向けに開発したコンパクトで機動性が高い小型キーボードで、デスクトップタイプの標準キーサイズのままキー数を必要最小...
ボディラインがくっきりと浮かび上がったセクシーなスーツに身を包んだ「草薙素子少佐」のフィギュア。攻殻機動隊S.A.C. Solid State Society 草薙 素子 (1/8スケールPVC塗装済み完成品) amazon.co.jp 限定価格:15,...
ライブドア事件とは、2006年1月16日に東京地検特捜部がライブドア本社および代表取締役社長である堀江貴文氏の自宅への強制捜査を行なったことから明るみになった事件で、ライブドアグループが2004年10月に関連会社の...
アクセスランキング
今日のアクセスランキング(上位10件)
今月のアクセスランキング(上位10件)
- 2NN (2ch News Navigator) (347 PV)
- プリンセスガーデンホテル女性社長の「片岡都美」氏はフジモリ元大統領夫人 (128 PV)
- 小林興起元衆議院議員がタレントの杉本彩さんにキスを迫る (61 PV)
- 2ちゃんねる(2ch)検索 掲示板 - スレタイ、過去ログ、全文検索 (49 PV)
- ログ速(ろぐそく、logsoku) - 過去ログ スレタイ検索 全文検索 (28 PV)
- 読売新聞「石井誠」記者変死事件 (25 PV)
- 5ちゃんねる(5ch.net、旧2ちゃんねる)掲示板 (23 PV)
- 掲示板フリーソフト - 無料で利用できる掲示板CGI (21 PV)
- PHP、MySQLで動くオープンソース掲示板ソフト (14 PV)
- UseBB(ユースビービー) - フォーラムソフトウェア (14 PV)
アクセス統計
ディレクトリ
- 59bbs.org - 掲示板
- Amalink - 画像付きamazon商品リンク作成ツール
- Mailform Std - オープンソースライセンス(GPLv2)のメールフォームCGI(Perl)
- ThreadPlus - オープンソースライセンスの(GPLv2)掲示板CGI(Perl)
- 2ちゃんねる掲示板検索
関連サイト
- 語句ログ - オープンソースブログソフト59Trackerを利用した情報共有ブログ
- 株価と為替レート(FX)の掲示板
- CommentPP - オープンソース掲示板システム(PHP/MySQL)のダウンロード
- BBS10 - CommentPP を利用したインターネット掲示板