組み込みC ++での抽象化と適切なコードプラクティスにより、デバッガーの必要性を排除できますか？
私は組み込みシステムのC開発者です。 YouTubeは最近、「組み込みシステム向けC++」の講演を推奨し始めました。それらのいくつかを見て、彼らは私の興味をそそりますが、彼らの誰もが私に残した質問に答えません。
これらの講演（特に 組み込みシステムにおける最新のC++ Michael Caisseによる）では、以下の代わりに、それによって開発プロセスを提唱しています。
- コードの作成と編集
- デバッグして機能することを確認します（または、デバッグして、何が悪いのか、ここからどこに進むのかを確認します）
- 働くまで繰り返す
...デバッガを完全に回避し、言語の選択と適切な実践によりバグが発生しにくくなるため、デバッガの必要性がなくなります。
しかし、アナログ回路を制御するマイクロコントローラーのファームウェアを書く人として、私の問題の多くはハードウェアが予期しない動作を示し、コード全体にブレークポイントをスローして待機することによってのみこの動作（特にイベントのタイミング）を調査できることがわかりましたイベントが順不同で発生するか、まったく発生しないかを確認します。
これにより、誤って構成されたレジスター、またはマイクロコントローラーの周辺機器の1つによる予期しない動作が明らかになります。これは、デバイスのマニュアルからは明らかではなく、小さなコードの再設計が必要です。これらの話は私の注意を引いていますが、私のような人々を助けるはずのこれらのテクニックが実際にハードウェアの問題で私を助けるのかわかりません。
抽象化と優れたコードの実践（私はそれがすべてです）によって、デバッガー（ハードウェアのバグに対処するために必要と思われるもの）の必要性を排除できますか？
「組み込みシステムにおける最新のC++」ビデオのメッセージを誤って伝えていると思います。要点は、コードを記述し、デバッガーでコードを実行してテストし、意図したとおりに機能することを確認する組み込みの世界の人々がいるということです。彼は、コンパイラーがコードに関する特定の仮定が保持していることを検証できるように、抽象化を使用するのがより良い代替策であると主張しています。
この方法でも、デバッガを使用してバグ、特にハードウェアの問題を見つけることができます。デバッガーを使用してコードを理解するだけでなく、そのように記述して理解可能で正しいコードにする必要があります。
より高い抽象化を使用して仮定を検証する利点は、特定のタイプのバグがあることです。 f(int mode, int value)と呼ばれる関数f(value, mode)を持っているため、完全に回避できます。 Michael Caisseは、適切なツールを使用すると主張しています。 C++の強力な型はこれを軽減するため、使用する必要があります。
いいえ、まったくありません。
もちろん、抽象化と優れた実践により、エラーのリスクを減らすことができます。例えば：
言語の抽象化により、コンパイラーはコードを生成できます。それ以外の場合は自分で作成する必要があります。たとえば、C++オブジェクトモデルでは、構築されたオブジェクトが想定どおりに破棄され、肩に余分な注意を払う必要がありません。
これらの抽象化により、 [〜＃〜] raii [〜＃〜] 、または スマートポインター など、コードで使用できるより安全な構成を構築して、メモリ管理に関連するタスク。
豊富な コンテナライブラリ と 強力なアルゴリズムライブラリ を使用すると、テスト済みで高度に最適化された実装を使用して、エラーが発生しやすいコードを自分で多数作成する必要がなくなります。
しかし、これはすべてバグの可能性を減らすだけです。バグが完全になくなることは決してありません。したがって、引き続きデバッガとログファイルを使用して追跡します。
この質問は、基本的には「毎回バグのないコードを初めて書けるか」ということになります。答えは常にノーになるでしょう。
はい、役立つ可能性のあるプラクティスがあり、モジュールを分離できます。組み込みとデスクトップの両方をコンパイルしてから、デスクトップでテストおよび開発できます。これらのモジュールの分離に役立つハードウェアアブストラクションレイヤーを作成できるため、PCでのモジュールのテストとデバッグが容易になります。
組み込みプラットフォームでのデバッガーの使用を減らすことには確かに価値があります。デバッガーは通常PCよりもはるかに遅く、したがってREPLははるかに遅いためです。
しかし、最終的には何らかのデバッガが必要になる何かが出てきます。これはJTAGデバッガーである場合もあれば、オシロスコープ、またはLEDが点滅している場合もあります。
ソフトウェアのバグには2つの基本的なタイプがあります。
- コードが意図したとおりに機能しません。
- あなたが意図したのは間違った行動でした。
言語の選択などは、最初のタイプのバグに影響を与える可能性があります（または与えない場合もあります）が、2番目のタイプのバグにはまったく影響がありません。 「意図したこと」とは、内部の設計上の決定ではなく、ソフトウェアの実際に観察可能な動作を意味することに注意してください。
現実世界の組み込みシステムの場合、あなたが完全に理解した可能性すべて現実世界がソフトウェアに投げかける可能性は、現実的にはゼロです。だからバグハンティングに行くことを期待してください！
あなたがするすべてが完璧であれば、デバッガは必要ありません。誰も完璧ではありません。
私の経歴の中で筆者として説明できる主要なクラスのバグがありますthought彼らはコードが何をしているか知っていましたが、実際には別のことをしました。これが発生した場合は、コンピュータが行ったと思ったことではなく、コンピュータが行ったことを正確に示すツールが必要です。そのツールはデバッガー（またはハイパーパラノイアレベルのロギングのような関連ツールのスイート）です。
左のモーターと右のモーターを混同することを文字通り妨げるフレームワークは、あまりにも制限が多すぎて興味深いことを行うことができない可能性があります。このポイントに到達するのに十分な一般化されたフレームワークをカスタマイズすると、適切なサイズのコード本体ができますデバッガが必要です。実際、私は最近このようなケースに遭遇しましたが、デバッガー、優れたソフトウェアドキュメント、およびいくつかのレゴモデルを同時に適用することで解決しました。私はこれらの基本的なツールのどれかが欠けている問題を解決したくなかったでしょう。
デバッガなしのアプローチを行うプログラマがいます。ドナルド・クヌースは、プログラムを最初から最後まで考えてからコードを書き始めたことで有名でした。私が理解したところによると、彼のコードは著しくバグがなく、多くの場合、初めてコンパイルして実行しました！しかし、ファームウェアが原因でタイムアウトが原因でPCI-e例外がスローされる場合は、デバッガーに感謝するでしょう！
デバッガーは、多くのことに役立つツールですが、定義上、主にデバッグ用です。したがって、あなたの質問は、良い実践とサードパーティのコードへの依存がバグを完全に排除できるかどうかに帰着します。
[...]言語の選択と適切な実践により、バグが発生する可能性が低くなり、デバッガーの必要がなくなります。
あなたが言ったように、あなたの言語/フレームワークと良い習慣がバグを少なくすることを信頼するとしても、あなたはすべてのバグを排除していませんが、それらの発生の可能性。デバッガー（またはロギングなどの同様のアプローチ）がない場合、まだ発生しているバグをどのように診断しますか？
さらに、誰もが自分の言語とフレームワークを100％信頼している場合、言語/ライブラリ自体の欠陥はどのようにして発見されるのでしょうか。 GitHubでメインストリームプロジェクトを開き、報告されている問題の数を確認します。
グッドプラクティスは確かに ソフトウェアの欠陥を減らす ですが、ベストプラクティスやツールを使用しても、デバッガーのユーティリティがなくなることはありません。
あなたの答えはあなた自身のコメントにあると思います：
[...]ハードウェアが予期しない動作を示す場合、私の問題の多くが見つかります
バグの問題は、バグが来るのを見たことがないことです！
組み込み開発のコンテキストで、2つの特定のユースケースを分離します。
開発ツールとして、デバッガは無菌で制御された環境でコードと実行状態をテストするために不可欠です。
診断ツールとして、組み込みファームウェアの障害モードを診断および理解するためにデバッガーは不可欠です。
したがって、no、少なくとも完全に排除することはできません。
組み込みデバイスは実際の状況と相互作用するため、組み込みファームウェアの最終テストは、デバッガーが誘発するストレス（環境およびアプリケーションのストレステスト）ではなく、現実の世界で行われます。純粋にソフトウェアエンジニア（SE）の開発領域である「ソフトウェアバグ」と、ファームウェアが組み込みアプリケーションの実際の状態と相互作用するときに発生するバグである「システムバグ」があります。
組み込み開発中、SEは、電子エンジニア（EE）、機械エンジニア（ME）、プロジェクトマネージャー（PM）と協力して、ファームウェア機能の公称動作条件と期待される機能を定義します。この開発活動では、デバッガーとICE/SWDデバイスは、
- システム監視
- コードエラー検出
- 制御されたテスト条件
組み込みシステムでは多くの副作用と複雑さを伴う可能性のあるロギングと比較して、これは公称条件が現実世界に近く、すべての即時の「ソフトウェア」バグが排除されることを確信を持って開発およびテストする特に邪魔にならない方法です。
ファームウェアが名目上完成した後、認定とテストサイクルが必要です。純粋なソフトウェアとは異なり、通常、組み込みデバイスに対する物理的な実世界のコンポーネントと、関連するファームウェアの効果があります。環境は次のものに影響を与える可能性があります
- 入力と割り込みの割合
- 外部センサーからのデータの品質
- さまざまなプロトコルとI/Oインターフェースの動作条件と基本エラー率
- その他の環境依存の条件。
これはすべて、組み込みファームウェアにストレスを与え、すべてのサイドロジックとエラー状態のチェックがストレステストされるポイントまで機能します。あなたは開発環境と比較して、いわば荒海にいます...
したがって、組み込みデバイスのテストサイクルは、
- 環境ストレス（振動、熱、電気）
- I/Oストレス（外部プロトコルとインターフェース）
- アプリケーションのストレス（要求性能）
- その他の該当するストレス
システムのストレステストを行うために、次に組み込みファームウェアをテストします。
そのコンテキストでは、ICE/SWDと組み合わせたデバッガーは、
- バグまたはグリッチの性質を理解する
- ハードウェアを台無しにしたことについて、EEを非難する
- 弱点が現れた後にシステムを診断および監視する
したがって、ここでもno、デバッガは非常に貴重なツールです。