ほとんどの場合、開発されたプロジェクトの品質を制御するために静的コード分析が使用されます。 ただし、コード分析が使用される異常なタスクがさらにあります。 この短い記事では、それらのいくつかについて説明したいと思います。
トレーニング
静的分析は、トレーニング目的に使用できます。 原則として、教師は生徒の課題を評価し、自分が書いたコードを調べて、プログラムのテストを行います。 生徒が多く、教師が1人しかないため、静的コードアナライザーを使用して注意をさらに強化できます。 そのため、彼は生徒に作品を作り直すよう依頼する理由を見つける可能性が高くなります。
トレーニングにアナライザーを使用する別のオプションは、若いプログラマーのコードをチェックすることです。 これにより、多くのエラーをすばやく見つけて説明できます。 また、インデント、変数の命名などを分析する機能により、組織で快適なコーディングスタイルの一部としてコードの記述をすばやく開始できます。
プログラムを別のシステムに転送する
特に当初はこれが計画に含まれていなかった場合、移植可能なプログラムを書くことは非常に困難です。 したがって、プログラムを別のオペレーティングシステムまたは別のハードウェアプラットフォームに転送することは、常に非常に苦痛です。 別のシステムのプログラムを待っているすべてのニュアンスを事前に知ることはほとんど不可能です。さらに、コード内のすべての安全でない場所を見つける方法を知ることはほとんど不可能です。 専用のコードアナライザーがここで役立ち、潜在的に危険な場所をすべて指し示します。 アナライザーは、型の次元の変更、データの整列の規則、バイト順の変更、古い関数の使用などが破損する可能性がある場所を示します。
ブラックホール検索
静的分析は、善のためだけでなく、損害のためにも使用できます。 コード分析は、開発者がバッファオーバーフロー、スタックオーバーフロー、およびその他の類似の欠陥を検出するのに役立つため、攻撃者も同じことができます。 脆弱な場所を探索することにより、ハッカーは攻撃するオブジェクトをすばやく選択できます。 つまり、大量のコードを表示する必要はありません。 彼のための仕事の一部は、静的アナライザーによって実行されます。 彼は、コードが脆弱な場所を示し、ハッカーは次の作業段階に進むことができます-コードで見つかった欠陥を使用できるかどうか、もしそうなら、どのように使用するかを理解しようとします。
多くの場合、攻撃者はプログラムのソースコードにアクセスできません。 ただし、バイナリ実行可能コードで直接動作する静的アナライザーを使用することは可能です。
当然のことながら、穴の探索は祝福に変えることができます。 たとえば、多くの企業は、プログラムの脆弱性を発見した人々に報いる。 静的アナライザーを使用すると、このような脆弱性を探すのがはるかに簡単になります。
サードパーティのソースを使用する
プログラマは多くの場合、さまざまなオープンソースコードを使用します。 言い換えれば、オープンな無料ライブラリまたはそのフラグメントを使用します。 多くの場合、同じタスクはさまざまなサードパーティの開発を使用して解決できます。 そして問題は選択方法です。 珍しい興味深い方法は、静的解析の使用です。 結局、見つかったエラーが少なければ少ないほど、より良い、より信頼できるコードである可能性が高くなります。
メンテナンスと開発のためにサードパーティのプロジェクトがチームに引き渡されると、静的分析によりプロジェクトの最も恐ろしい場所が明らかになるため、システムのどの部分に最大限の注意を払うべきかを推測できます。
コードリファクタリングの必要性の正当化
多くの場合、プログラマーはプロジェクトが複雑になりすぎてバラバラになり始めることを認識しています。 彼らは、プロジェクトをリファクタリングする必要があるという結論に達します。そうしないと、プロジェクトが完全に失敗しないように、サポートとバックアップの作成がほとんど常に消費されます。 しかし、プログラマーには常に緊急のタスクがあります。 また、なぜ別のダイアログを作成する価値がないのかを正当化するために、古いダイアログの1つを書き直す必要があるのはそれほど簡単ではありません。 ここで、引数の1つは静的アナライザーである可能性があります。これは、大きすぎる関数、グローバル変数の多重使用、複雑すぎるクラス階層、廃止された安全でない関数の使用、その他の恐怖について叫びます。
おわりに
もちろん、すべてをリストしたわけではありませんが、私が思い出したものをリストしました。 静的コード分析によって解決できる他の多くのタスクがあります。
静的分析方法論を使用する興味深い非標準の方法がある場合に書いてください。