[ライブ]の検索結果

＋ 

A デバッグを効率的に進めるための９の心得

－ 

A デバッグを効率的に進めるための９の心得

バグのないソフトウェアはない、というくらいソフトウェアにはバグがつきものですが、ソフトウェアの開発プロジェクトには期間や予算に上限があるため、バグの修正に手間取ると十分なテストを実施することができず、...

バグのないソフトウェアはない、というくらいソフトウェアにはバグがつきものですが、ソフトウェアの開発プロジェクトには期間や予算に上限があるため、バグの修正に手間取ると十分なテストを実施することができず、品質が低い状態でリリースされてしまうことになります。テストを円滑に進めソフトウェアの品質の高めていくためには、バグを迅速かつ正確にバグを修正していく必要があります。

しかし、オブジェクト指向プログラミング（OOP）やデザインパターンなどプログラムの作り方についての解説書や記事はたくさんあるにも関わらず、「バグは本来あってはいけないもの、あるはずが無いもの」という意識があるためか、デバッグに関して語られている情報源はあまり多くありません。そのため、デバッグのテクニックについてはせいぜい「開発現
場の先輩に教えてもらう」というのが実情です。

知識を共有するために、私がこれまでのソフトウェア開発の経験から得た、デバッグを効率的に行なうための心得をいくつか挙げてみたいと思います。

1. バグの原因は自分が作っているプログラムにある可能性が最も高い
ソフトウェアを構成する要素として、OS、開発ツールに付属するライブラリ、市販ライブラリ、プロジェクト内で作成されたライブラリなどがありますが、バグの原因は自分が作っているプログラムである可能性が最も高いと考えたほうがすばやくバグを見つけられます。なぜなら、今まさに開発が行なわれているプログラムこそが最もテストされていないプログラムだからです。問題の原因をマイクロソフトのせいにする前に自分のプログラムを調べましょう。

2. テストの実施を妨げているバグを優先する
当然のことですが、テストができなければバグを見つけることができません。効率的にバグが発見できるように、めったに行なわれない操作によって発生するバグよりも、必ず行なわれる操作で発生するバグを優先的に修正していく必要があります。

3. 問題を確実に再現できるようする
問題が発生する条件（操作手順、データなど）を必ず特定しなければなりません。これができないと動作確認は不可能ですので、修正したつもりが実は直ってなかったという事態にもなりかねません。この作業自体はソースコードがなくても可能なので、テスト担当者の協力を得られるのであれば、情報を交換しながらテスト担当者と開発担当者が並行して調査を進めるのが良いでしょう。

4. 一度でも問題が発生した場合はバグがある可能が高いので必ず調査する
一度でも問題が発生した場合は、単にバグが発現する条件がわかっていないだけで、必ずどこかにバグがあります。開発作業中はいろいろプレッシャーがあるので難しい面もありますが、見つけた時点で調査しておいた方がいろんな面で良いでしょう。

5. ソースコードを見ただけで正しい処理が行なわれていると判断しない
プログラムはプログラマが思っている通りに動くのではなくコンパイラが解釈した通りに動くものです。コンパイラについての知識が豊富なプログラマが犯しがち問題ですが、プログラマがコンパイラの仕様について誤解しているために生じるバグもよくあります。プログラマ自身は正しいと思っているためソースコードを見ただけではバグを発見することが困難ですがが、このようなバグは実際にプログラムを動かしてみることで簡単に原因を発見することがきます。

6. 想定外の操作や想定外のデータが使用されていないかチェックする
プログラムはプログラマが想定していなかった操作が行なわれたり、想定外のデータが入力されたりした場合は正しく動作しないことが多いものです。問題を発生させる操作やデータがプログラムで想定されているかチェックしてみましょう。

7. バグの原因となっているソースコードは必ず特定する
関係の無いところを直しても問題の現象が発生しなくなる場合もありますが、それでバグが無くなったわけではありません。そのような場合は、また別のところで別のかたちで問題が発生することになりかねません。バグは必ずソースコードレベルで原因を特定し確実に修正すべきです。

8. できるだけ他の処理に影響を与えないようにソースコードを修正する
他の処理に影響を与えるような修正を行なった場合、これまで問題なく動いていた部分に新たなバグを埋め込んでしまう可能性が高いものです。別の問題を引き起こさないように、影響範囲に注意してソースコードを修正します。しかし、単なるコーディング上の間違いであればプログラムの修正は比較的簡単で他の処理に影響を与えることは少ないのすが、設計に問題がある場合は他の部分の影響を与えないようにバグ修正を行なうのが難しい場合があります。そのような場合は、本質的な問題の解決にはならないとしても、影響範囲を限定するために暫定的な対処を行なった方が良いでしょう。

9. ソースコードを修正した場合は必ずテストする
たとえ簡単な修正であっても間違った修正を行なう可能性は常にあります。また、修正が思わぬところに影響を与えることもあります。当たり前ですが、ソースコードを修正した場合は必ずテストを行ないましょう。テスト作業を手を抜くよりも、テストを行なった方がトータル見れば開発者自身にとっても負担が少ないはずです。

[67] Posted by buzei at 2007/09/11 04:59:32
0 point | Link (2) | Trackback (0) | Comment (0)

＋ 

A C++ 言語

－ 

A C++ 言語

C++は、広く普及しているプログラミング言語のC言語にオブジェクト指向的な拡張を施したプログラミング言語で、クラスや標準ライブラリである、STL(標準テンプレートライブラリ)を利用することで効率的にプログラムを...

C++は、広く普及しているプログラミング言語のC言語にオブジェクト指向的な拡張を施したプログラミング言語で、クラスや標準ライブラリである、STL(標準テンプレートライブラリ)を利用することで効率的にプログラムを作成することができる。

Bjarne Stroustrup's Homepage
C++の開発者、Bjarne Stroustrup 氏のホームページ（英語）。

猫でもわかるプログラミング
超初心者を対象とするC/C++言語のプログラム教室。Windows SDKについての解説もある。

C++ Glossary
C++関連の難解語の簡単な解説。

Visual C++ ホームページ
マイクロソフトのVisual C++のページ。製品情報、技術情報、サービスパックなどのダウンロード。

プログラミング言語C++第3版 Bjarne Stroustrup C++言語によるプログラムの構成について、C++の開発者自身が解説。豊富なサンプルを用いて、C++の文法規則や言語の基本から、標準ライブラリであるSTLの使い方まで詳しく解説されている。C++のバイブル。

[35] Posted by buzei at 2007/05/27 13:41:01
0 point | Link (4) | Trackback (0) | Comment (0)

＋ 

A ライブドア事件

－ 

A ライブドア事件

ライブドア事件とは、2006年1月16日に東京地検特捜部がライブドア本社および代表取締役社長である堀江貴文氏の自宅への強制捜査を行なったことから明るみになった事件で、ライブドアグループが2004年10月に関連会社の...

ライブドア事件とは、2006年1月16日に東京地検特捜部がライブドア本社および代表取締役社長である堀江貴文氏の自宅への強制捜査を行なったことから明るみになった事件で、ライブドアグループが2004年10月に関連会社の出版社買収をめぐって虚偽の事実を公表したことが、証券取引法で禁止されている偽計取引、風説の流布にあたるとされた。

2006年02月10日には、証券取引等監視委員会によって、ライブドア前社長堀江貴文容疑者、ライブドア前取締役宮内亮治容疑者、ライブドアマーケティング前社長岡本文人容疑者、ライブドア前執行役中村長也容疑者の４人とライブドア本体、関連会社ライブドアマーケティング（旧バリュークリックジャパン）が東京地検特捜部に告発され、同年2月13日には東京地方検察庁によって起訴された。

この事件を契機に、それまで上昇基調にあった新興株式市場が低迷することとなった。

2007年3月16日に、東京地方裁判所によって堀江貴文被告が懲役2年6カ月（求刑懲役4年）、宮内亮治が懲役1年8カ月（求刑懲役2年6カ月）の実刑判決を言い渡されている。また、法人であるとしてのライブドアに対しても、証券取引法違反（有価証券報告書の虚偽記載、偽計・風説の流布）で2億8000万円の罰金判決が下されている。

[22] Posted by buzei at 2007/05/14 13:27:54
0 point | Link (4) | Trackback (0) | Comment (0)