※本記事は、Geminiによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。
原文
Famous Programming Errors That Everyone Should Learn From - DEV Community
意訳+要約
有名なプログラミングエラーから学ぶ：歴史に残る失敗から未来を変える
このブログ記事では、有名なプログラミングエラーをいくつか紹介し、そこから何を学ぶべきかを探ります。
1. マリナー1号：符号ミスで火星行きが台無しに
- 原因：符号ミスにより、ロケットの姿勢制御システムが誤作動
- 結果：火星探査計画が失敗
- 教訓：符号ミスは深刻な結果をもたらす。徹底したテストとレビューが不可欠
2. アリアンス5号：64ビット整数オーバーフローで打ち上げ失敗
- 原因：64ビット整数のオーバーフローにより、ロケットの制御システムが誤作動
- 結果：衛星打ち上げ失敗、損害額数十億円
- 教訓：データ型には注意が必要。適切なデータ型を選択し、オーバーフローの可能性を考慮
3. セルsius：熱暴走で100万台以上のスマホがリコール
- 原因：ソフトウェアのバグにより、熱暴走が発生
- 結果：100万台以上のリコール、莫大な損害
- 教訓：ソフトウェアテストの重要性。異常な状況を想定したテストを実施
4. Therac-25：放射線治療装置の誤動作で患者が被曝
- 原因：ソフトウェアのバグにより、過剰な放射線が照射
- 結果：患者が被曝、死亡事故も発生
- 教訓：医療機器開発における厳格な安全対策の必要性。ソフトウェアの品質保証が不可欠
5. Y2K問題：2000年問題で世界が震撼
- 原因：2桁の年数表記による誤動作の可能性
- 結果：世界規模でのシステムトラブルが懸念
- 教訓：将来を見据えた設計の重要性。保守性や拡張性を考慮
これらのエラーから学ぶべき教訓
- 徹底したテストとレビュー
- データ型の適切な選択
- 異常な状況を想定したテスト
- 医療機器開発における厳格な安全対策
- 将来を見据えた設計
まとめ
歴史的な失敗から学び、同じ過ちを繰り返さないことが重要です。これらの教訓を活かし、より安全で信頼性の高いコード開発を目指しましょう。
GeminiへのQA
Ｑ：徹底したテストとは、どれくらいやればいいのでしょうか？
徹底したテストとは、コードのすべての可能性を網羅するテストを行うことです。そのためには、できるだけ多くのテストを記述する必要があります。
大規模なプロジェクトでは、複数の領域が混在しているため、協力が非常に重要です。また、バックアッププランを用意しておくとよいでしょう。
具体的には、以下のテストを実施することが考えられます。
- 単体テスト：コードの単一のユニットをテストする
- 統合テスト：複数のユニットを組み合わせてテストする
- システムテスト：システム全体をテストする
- 負荷テスト：システムの負荷耐性をテストする
- セキュリティテスト：システムのセキュリティをテストする
また、テストの自動化も重要です。自動化することで、テストの実行を効率化することができます。
徹底したテストを行うことで、バグの早期発見と修正が可能になり、システムの品質を向上させることができます。
なお、徹底したテストとは、すべてのバグを検出できるという意味ではありません。しかし、バグの検出率を高めることで、システムの信頼性を向上させることができます。
Ｑ：実機を使ったテストはしないのでしょうか？
実機を使ったテストは、必ずしも必要ではありません。しかし、以下の場合には、実機を使ったテストを行うことを検討する必要があります。
- シミュレーションでは再現できない問題がある場合
- 実際の環境で動作を確認する必要がある場合
実機を使ったテストを行う場合には、以下の点に注意する必要があります。
- テスト環境の構築
- テストデータの準備
- テスト結果の分析
実機を使ったテストは、時間とコストがかかります。そのため、必要最低限のテストに留めることが重要です。
また、実機を使ったテストを行う前に、シミュレーションなどの他のテスト方法で可能な限り問題を洗い出しておくことが重要です。
以下は、実機を使ったテストを行うべき具体的な例です。
- ハードウェアとの連携が重要なシステム
- リアルタイム性が求められるシステム
- セキュリティが重要なシステム
これらのシステムでは、シミュレーションでは再現できない問題が発生する可能性があります。そのため、実機を使ったテストを行うことで、より高い信頼性を確保することができます。
実機を使ったテストは、開発の最終段階で行うのが一般的です。しかし、システムによっては、開発の初期段階から実機を使ったテストを行う必要がある場合もあります。
実機を使ったテストを行うかどうかは、システムの特性や開発スケジュールなどを考慮して判断する必要があります。
Ｑ：データ型を最初に定義しなかったのでしょうか？それとも想定が不足していたのでしょうか？
データ型を定義しなかった可能性も、想定が不足していた可能性も考えられます。
データ型を定義しなかった場合、コンパイラやインタープリターがデフォルトのデータ型を割り当てます。しかし、デフォルトのデータ型が想定と異なる場合、エラーが発生する可能性があります。
また、データ型の範囲や精度を考慮せずにデータ型を定義すると、オーバーフローやアンダーフローなどのエラーが発生する可能性があります。
これらのエラーを防ぐためには、以下の点に注意する必要があります。
- データ型を適切に定義する
- データ型の範囲や精度を考慮する
- 必要に応じて、データ型変換を行う
データ型を適切に定義することで、コードの信頼性を向上させることができます。
以下は、データ型を適切に定義しなかったために発生したエラーの例です。
- 整数型変数に小数点数を代入したために、誤った結果が出力された
- 文字列型変数に数値を代入したために、エラーが発生した
これらのエラーを防ぐためには、データ型を定義する前に、変数に格納するデータの種類と範囲を明確にすることが重要です。
また、データ型変換を行うことで、データ型間の互換性を確保することができます。
データ型変換を行う際には、変換後のデータ型が想定と異なる場合にエラーが発生する可能性があることに注意する必要があります。
感想＋雑記
失敗から学ぼうにも、それに至る経緯や実装方式、バグレポートがしっかりしてないとダメだと思う。
やり取りとか内容見てて、実機のテストが不足しているのでは？って印象うけたけど、違うんかな？
あと、符号やデータ型とかは、想定がどうだったのか次第だろうと思う。
想定通りの型定義でダメだったのなら、それは、ソフトウェアのせいなのか？って感じる。
２０００年問題はあったなぁ。。。
結局、そんな大事にはならなかったけど、実際は何かあったのだろうか？
日本だと、みずほのシステム開発がここに名を連ねるのだろうな。。。
