ゼロバグソフトウェアの神話
すべてのソフトウェアにはバグがあります。これはソフトウェア開発に携わったことがある人なら誰でも知っている事実です。どんなに複雑なアプリケーションであっても、あらゆる小さな欠陥を根絶しようとするのは、途方もなく費用がかかりすぎます。ソフトウェアテストは結局のところ、問題の存在を証明するだけで、存在しないことを証明するものではないという点はさておき、そうは言っても、修正が必要な欠陥やソフトウェアバグの種類は存在します。
参照:採用キット: バックエンド開発者(TechRepublic Premium)
いつもの容疑者
ソフトウェアエラーの原因となる要因は数多くあります。以下に、最も一般的なものをいくつか挙げます。
- 期待される行動の曖昧さ
- 外部サブシステムまたはコンポーネント
- 不十分なテストとタイムライン
- プログラミングエラー
原因が何であれ、キャリアのある時点で、あなた自身、あるいは誰かが、欠陥に対処する必要があると判断するでしょう。この判断方法は様々ですが、通常は顧客の行動、行動、損失許容度、そして損失の最小化といった要素が組み合わさって行われます。有能なソフトウェア開発者のほとんどは、原因が明らかになれば問題を解決できます。原因を突き止めるプロセスは、トラブルシューティングまたはデバッグと呼ばれます。
トラブルシューティングとデバッグ
簡単に言えば、デバッグはトラブルシューティングの一部です。デバッグなしでもトラブルシューティングは可能ですが、トラブルシューティングなしでデバッグすることはできません。この説明が分かりにくいように思われるかもしれませんが、実際そうなのです。
トラブルシューティングはデバッグよりも抽象度の高いレベルで行われることが多く、システムの多くのコンポーネントに適用されます。これは、システム内で問題を引き起こしているコンポーネントを解析するプロセスです。トラブルシューティングはあらゆるシステムに適用でき、問題が解決されることを意味するのではなく、根本原因の発見と理解に重点が置かれます。
一方、デバッグはコンピュータコードに特有のものです。開発者として、ソフトウェアモジュールのデバッグを担当する場合、望ましくない動作を引き起こしている命令を見つけ出し、それを修正することが求められます。これらはすべて、可能な限り同じセッションの中で行う必要があります。
バグの文書化
ソフトウェアの望ましくない動作のトラブルシューティングとデバッグの第一歩は、問題が適切に文書化されていることを確認することです。これにより、関係者全員が同じ認識を持つことができ、プロセスの後のステップで役立つ情報を得ることができます。適切に文書化されたバグには、少なくとも以下の内容が含まれます。
- 説明
- 再現手順
- 再生産率
- 期待される結果
- 実績
- 環境とバージョン
バグ修正の見積もり
開発者として、バグの発見と修正にどれくらいの時間がかかるかを見積もるよう求められることがよくあります。残念ながら、明確な答えはありません。推奨される方法は、最初の作業を4時間または半日程度に時間制限を設けることです。この最初のセッションでは、重要な情報をいくつか見つけ出すことに集中する必要があります。
- 問題を再現できますか?
- 根本的な原因はご存知ですか?
- 領域またはコンポーネントに絞り込んでいますか?
最初のタイムボックス内に問題を発見し、解決できた場合は、おめでとうございます。もし解決できなかった場合は、初期のデバッグ作業に基づいたTシャツのサイズの見積もりを関係者に提示するのが適切でしょう。以下は一般的なガイダンスですが、状況によって結果が異なる場合があることをご承知おきください。
- 小: 解決するには 4 ～ 8 時間かかります。
- 中: 解決するには 2 ～ 3 日かかります。
- 大規模: 解決に 1 週間以上かかる場合があります。
- 特大: 解決するには追加のチーム メンバーや計画が必要になります。
この時点で、バグ修正の見積もりがそれほど不正確な科学であるなら、なぜ見積もりを出す必要があるのかと疑問に思うかもしれません。真実は、透明性を提供することが全てです。ステークホルダーの期待を管理しやすくし、修正が利用可能になるまで何もしないことが選択肢にないことが明らかになった場合、あるいはその選択肢がなくなった場合に、プロダクトオーナーに選択肢を提供するためです。アルバート・アインシュタインはかつてこう言いました。「問題を作り出したのと同じレベルの思考では、問題を解決することはできない。」
実証済みのデバッグ手法
最新のIDEには、豊富なデバッグオプションが搭載されています。これらは通常、プログラミング環境に固有のものであり、開発者の作業を楽にするためのものです。とはいえ、基本的な機能も見逃さないでください。
印刷物：いろいろ
ログ記録は、依然として問題のトラブルシューティングに最も効果的な方法の一つです。ログ記録によって、トラブルシューティングの対象となっているコードが実際には呼び出されていないことが何度も明らかになることに、きっと驚かれることでしょう。
エラーメッセージを読む
エラーをGoogle検索するのは、先人たちがどのように問題を解決したかを知るのに最適な方法ですが、まずはエラーメッセージをじっくり読むようにしてください。最近の言語やフレームワークのほとんどは、エラーの内容を明確に示してくれますし、エラーが発生した瞬間の状況に応じた修正方法を提案してくれるものも多いです。
すでに動作しているコードから始める
開発者がソース管理を使用するのには理由があります。動作するバージョンにロールバックしてコードベースを比較すれば、問題のあるコードセクションをより迅速に絞り込むことができます。たとえエラーが最近発見されたばかりであっても、多くの場合、数バージョン前まで遡り、望ましくない動作が再発するまで更新を1つずつ適用することで、問題の原因をある程度把握することができます。
変更を加えるたびにコードを実行する
面倒に聞こえますが、真剣に言えば、コードを実行して動作の変化をできるだけ頻繁に検証することで、トラブルシューティングの手順を後戻りする必要がなくなります。
分割して征服する
見落とされがちですが、問題がなくなるまでコードを単にコメントアウトすることは、問題のある命令を探し出すための手っ取り早い方法になり得ます。
ラバーダックデバッグ
ソフトウェアのトラブルシューティングは時にチームスポーツとなり、型破りな思考が求められます。そのような手法の一つに「ラバーダック・デバッグ」があります。これは、ソフトウェアのトラブルシューティングにおいては、スピードを落とす必要がある場合があるという前提に基づいています。ラバーダック・デバッグの手順は以下のとおりです。
参照: 採用キット: Python 開発者(TechRepublic Premium)
- ゴム製のアヒル（お風呂用）を乞う、借りる、盗む、買う、作る、またはその他の方法で入手する。
- そのゴム製のアヒルを机の上に置き、これからコードをいくつか確認するだけだと伝えます — もしよろしければ。
- コードが何をするべきかをアヒルに伝え、その後、コードを 1 行ずつ詳しく説明します。
- ある時点で、あなたはアヒルに自分のコードが何をしているのかを説明しているうちに、実際にはそうではないことに気づくでしょう。アヒルは得意げにあなたを見つめるでしょう。
- アヒルに時間を割いてくれたことに感謝し、コードを修正してください。
慌てないでください。人生におけるほとんどのことと同様に、ソフトウェアのトラブルシューティングは経験と練習を重ねることで容易になります。重要なのは、プロセス全体を通して関係者に透明性を保ち、アプローチを体系的かつ体系的に行うこと、そして同僚のプログラマーに助けを求めることをためらわないことです。
TechRepublic Academy の以下のリソースを活用して、IT スキルセットを強化し、コーディングをマスターしましょう。
- コーディング101ブートキャンプ初心者向けバンドル
- Linux & Docker コーディングバンドル
- Pythonコーディング：開発者を目指す人のための究極のトレーニングバンドル
- オールインワンコーディングスキルバンドル
