組み込み開発者がプログラムコードの静的分析に役立つツールである3つの理由を簡単に定式化することにしました。
第一の理由：いくつかの間違いを探すのに苦労して時間を無駄にしない
静的コード分析==デバイスのテストとデバッグのコストが安い。 エラーが早く発見されるほど、修正のコストは安くなります。 静的分析は、コードの作成段階でも、または少なくともサーバーでの夜間の起動中にエラーを検出します。 その結果、多くのエラーを見つけて修正する方がはるかに安価です。
静的分析は、組み込みシステムをデバッグするときに特に役立ちます。 このようなプロジェクトでは、開発者はプログラムのエラーだけでなく、デバイス自体のエラーや低品質のモックアップ（接触不良など）に直面します。 その結果、エラーを見つけるプロセスは、多くの場合、どこで探すべきかが不明確であるため、引きずられる可能性があります。 プログラマーがコードが正しく記述されていると考えると、回路設計者やハードウェア部分を担当する他の同僚が関与する長い研究につながる可能性があります。 さらに不愉快なのは、後でプログラムコードに戻り、最終的に愚かなタイプミスを見つけることです。 時間とエネルギーの途方もなく非効率的な支出。 静的アナライザーがこのようなエラーを検出した場合に最適です。
ある友人が私に似た状況をどのように説明したかを次に示します。
「まだマスターですが、カスタムメイドのさまざまな小規模デバイスを製造する会社で働き始めました。 たとえば、温室の自動化や、どこにも漏れがなく過熱していない企業のセンサーからの情報収集。
私は別の典型的なタスクに直面しています。それは文字通り数時間で対処でき、彼らが作成したデバイスのファームウェアのために2人の同僚にそれを与えることができます。 同僚は、彼がすべてを迅速に行ったことに驚き、誇らしげに宣言していることを称賛します。 同僚はフラッシュドライブで削除され、そこでマイクロコントローラーファームウェアのバイナリファイルを作成しました。
そして、私はこのことを忘れています。 他のより大きくて興味深いタスクがあります。 さらに、彼らは来なかったので、すべてが大丈夫です。
そして彼らは来ました。 しかし、一週間後にのみ。 彼らは、私たちは何も理解していないと言います。 彼らは私の頭全体を骨折しました。 スタンドは機能しません。 むしろ、それは動作しますが、期待どおりにはいきません。 私たちはすでにそれを再びはんだ付けし、電気機械式のエグゼクティブパーツを交換しました。 うまくいかない...たぶん見ますか？ 多分、結局のところ、プログラムに何か問題があります...
コードを開くと、すぐにエラーが表示されます：
uchar A[3]; .... for (uchar i = 0; i != 4; i++) average += A[i]; average /= 3;
私の他のプロジェクトは基礎として取り上げられ、コードの大部分はCopy-Pasteメソッドによって作成されました。 ある場所では、4を3に置き換えるのを忘れていました。私はとても恥ずかしくて、2人を1週間働かせました。」
2番目の理由：プログラムの更新に費用がかかる、不可能、または遅い
組み込みデバイスのエラーは、大量生産が開始された場合、修正が不可能またはほとんど不可能であるという点で非常に不快です。 数十万台の洗濯機がすでに発売されており、買い物をしている場合、特定のモードで洗濯機が正しく動作しない場合はどうすればよいですか？ 一般に、2つの修辞的および実際のオプションがあります。
- さまざまなサイトで否定的な顧客レビューを投稿して受信するには、評判を損ないます。 もちろん、「このようにしない」アプリケーションだけでなく、弱いオプションをリリースして指示に送信することもできます。
- シリーズを呼び出して、ファームウェアをアップグレードします。 高価なエンターテイメント。
さらに、デバイスの循環が大きいか小さいかに関係なく、エラー修正は問題が発生したり遅れたりする可能性があります。 ロケットが落ち 、エラーが検出されましたが、遅れました。 患者は死亡し 、エラーが見つかりましたが、それは人々を返しません。 ミサイル防衛システムは見逃し始めており、エラーが発見されましたが、この話には楽しいものはありません。 車の速度は落ちず 、エラーが見つかりましたが、このプロセスの犠牲者はいませんでした。
結論は非常に簡単です。 組み込みデバイスのコードは、特にエラーが被害者または重大な材料の損失につながる可能性がある場合、可能な限り徹底的にテストする必要があります。
静的コード分析は、コードにエラーがないことを保証しません。 ただし、あらゆる機会を利用して、コードの正確性をさらに検証する必要があります。 静的アナライザーは、さまざまなCode-Reviewを行った後でもコード内に残っているさまざまなエラーを示すことができます。
静的解析によるデバイスのエラーが少ない場合、これは素晴らしいことです。 おそらく、これらの非常にエラーの発見のおかげで、誰も死なず、会社は顧客からの請求によって多くのお金や評判を失うことはありません。
第三の理由：プログラマーは自分が何か間違ったことをしていることを知らないかもしれません
プログラムのエラーは、比two的に2つのタイプに分類できます。 プログラマーは最初のタイプのエラーについて知っており、不注意でランダムにコードに現れます。 第2種のエラーは、プログラマがこのようなコードを書くことが不可能であることを単に知らない状況で発生します。 つまり、彼はそのようなコードを好きなだけ読むことができますが、それでもエラーを見つけることはできません。
静的アナライザーには、特定の条件下でエラーを引き起こすさまざまなパターンに関する知識ベースがあります。 したがって、それらはプログラマにエラーを示すことができます。エラーの存在は、彼自身が推測することはほとんどありませんでした。 たとえば、32ビット型のtime_tを使用すると、 2038年以降にデバイスが不適切に動作する可能性があります。
別の例は、シフト演算子<< / >>の不適切な使用により発生するプログラムの不定の動作です。 これらの演算子は、マイクロコントローラコードで非常に広く使用されています。 残念ながら、プログラマはこれらの演算子を非常に不注意に使用することが多く 、プログラムの信頼性が低くなり、コンパイラのバージョンと設定に依存します。 同時に、プログラムはそれ自体で機能しますが、正しく記述されているためではなく、幸運なためです。
プログラマは静的アナライザーを使用して、このような多くの不快な状況から身を守ることができます。 さらに、アナライザーを使用して、コード全体の品質を制御することができます。これは、プロジェクト参加者の構成が拡大または変更する場合に重要です。 言い換えれば、アナライザーは初心者が悪いコードを書き始めたかどうかを追跡するのに役立ちます。
おわりに
静的コードアナライザーを必ず使用する別の理由があります。 これは、プロジェクトがMISRA Cなどの言語でのソフトウェア開発の特定の標準に準拠する必要がある場合です。ただし、これは管理手段に関連する可能性が高く、トピックから少し外れています。
静的アナライザーを使用することは、あらゆる組み込みプロジェクトに確実に推奨されることを示したかったのです。 この方法を使用すると、次のことができるようになります。
- 検索時間を短縮し、エラーを排除します（ 例 ）。
- 重大なエラーの可能性を減らします。
- ファームウェアの更新の可能性を減らします。
- コードの全体的な品質を監視します（さらにSonarQubeに注目することをお勧めします）。
- 新しいチームメンバーの仕事の質を監視します。
- サードパーティのモジュール/ライブラリのコードの品質を管理します。
遅延と優位性の錯覚を除いて、静的コード分析を使用しない理由はありません。
静的コードアナライザーを使用してください！ たくさんあります 。
当然、最近、多くのARMコンパイラのサポートを開始した PVS-Studioコードアナライザーに注意を払うことをお勧めします。
この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：Andrey Karpov。 組み込み開発者が静的コード分析を使用する必要がある理由 。