静的コードアナライザーのトピックは使い古されています。 過去6か月間、この問題に関するスピーチなしの会議は事実上ありませんでした。 しかし、彼らは皆、内部からアナライザーについて話し、彼らの仕事のメカニズムを示しています。 同時に、彼らは本来意図されていたものを正しく説明することを忘れます。 ほとんどの場合、静的アナライザーの作業の理論的な部分が考慮され、実際の実装は行われません。 したがって、商用プロジェクトの実際のチームの静的アナライザーが追求する目標についてお話します。 また、当社のさまざまなアナライザーを使用した作業の編成の例を検討してください。
静的分析とは何ですか？
これは、実行せずに実行されたプログラムコードの分析です。 したがって、プログラムの実行時エラーはそれを使用してキャッチできません。 静的分析は、プログラムのテキストコードでのみ機能します。これは、開始するのに数秒かかりますが、バグを見つけるまでの時間を節約します。
アナライザーが機能する方法はいくつかあります。
- 正規表現検索 。 ここではすべてが非常に簡単です。 コード内の規則の下にあるテキストを検索すると、最適なオプションが提供されます。
- 言語の文法の分析 。 コード解析のより複雑なバージョン。 文法はツリーの形で表され、その頂点は言語演算子であり、葉はオペランドです。 正規表現に比べてはるかに複雑な構造を見つけることができます。 実装するのはより困難であるため、ほとんどのアナライザーはレギュラーに基づいてカスタムルールを記述する機会を提供しますが、内部では最初と2番目の相乗効果として機能します。 執筆時点のSwiftについては、構文ツリーに基づいてカスタムルールを作成する可能性を見つけることができませんでした。
静的解析を実装する理由
バグをできるだけ早く見つけるには、アナライザーが必要です。 私たちの場合、これはプロジェクトの編集です。 後のバグが見つかると、開発者とビジネス全体のコストが高くなります。
ただし、この目標はあまりにも一般的であり、特別なセマンティックの負荷はかかりません。 それをいくつかの小さなものに分解してみましょう：
- コード内の重大なバグを見つけます 。 たとえば、必要のないさまざまな強制的な展開です。 循環リンクなど、より複雑なものを検索できるさまざまなユーティリティがあります。
- 自動化作業スタイルガイド 。 「コードのデパーソナライズ」チームでは、メソッドの1つにスタイルガイドの導入があります。これは、コードを記述する基本的なプラクティスを示しています。 多くの場合、数十ページの巨大なドキュメントを取得します。 特に、以前に別のスタイルで書いたチームに新しい開発者が来た場合は、それらを覚えておくことが問題になります。 そして、これは静的アナライザーがうまく機能する場所です。 スタイルガイドに書かれているほとんどのルールを自動化できます。 Swiftより前に登場した言語では、各ルールのスタイルガイドは通常、リンターに追加されるかどうかを示します。 そして、追加された場合、どのような名前で。 これを実装する方法の例を次に示します。
カスタムルールを実装する方法
Swiftlintは現在、 Swiftで最も人気のあるコードアナライザーです。 また、 テーラーを使用します。 最初の方法では、正規表現に基づいて独自のルールを作成できます。これにより、スタイルガイドのほとんどのルールを実装できます。
Swiftlintを使用すると、プロジェクトにある.swiftlint.yml構成ファイルに配置する必要があるカスタムルールを作成できます 。 カスタムルールを記述する言語には、多くのパラメーターがあります。
- 同梱\特定のファイルを含めます。 正規表現のように機能します。 例：「。*。Swift」。 オプションです。
- exclude \特定のファイルを除外します。 正規表現のように機能します。 例：「。* Test.swift」。 オプションです。
- name \ルールの名前。 オプションです。
- regex \検索用の正規表現。
- ルール識別子\ルール識別子。 オプションです。
- match_kinds \検索が発生するコードのタイプ。 それらはたくさんあります。たとえば、コメントやキーワードでのみ検索できます。 オプションです。
- message \正規表現がこのルールを見つけたときに表示されるメッセージ
- 重大度\警告/エラーの2種類があります。 選択した値に応じて、エラーまたは警告としてXcodeに表示されます
たとえば、あなたの会社では弱いもののみを使用し、所有していないものは使用しません。 後者のパフォーマンスは前者よりも高くなっています。 しかし、弱点がアプリケーションをクラッシュさせないという事実は、あなたにとってより重要です。 これは正規表現を使用して簡単に実行でき、カスタムルールを作成できます。
unowned: name: "Unowned" regex: 'unowned' message: "Please use `weak` instead. " severity: error
コメントに関する別の例。 プロジェクトにヘッダーを書き込まないとします。 これには正規表現も理想的です。
no_header_comments: name: "Header Comments" regex: '//\s*Created by.*\s*//\s*Copyright' match_kinds: - comment message: "Template header comments should be removed."
コードアナライザーのシステムを実装する方法
最も興味深い部分は、静的分析プロセスのスケーリングと自動化です 。 これは、複数のプロジェクトがあり、すべてのカスタムルールを同じにする場合に特に重要です。 すべてのアナライザーには、設定が保存される特定の構成ファイルがあります。 プロジェクトには、.swiftlint.yml、.tailor.yml、cpd_script.phpの3つのファイルがあります。
最後のファイルは、phpで記述されたスクリプトです。 迅速なプロジェクトのコピー＆ペースト検出器によって生成されたファイルの分析を開始します。 その構成については、次の記事で説明します。
最も簡単なサポートオプションは、これらのファイル用に個別のリポジトリを作成することです。 このようにします。 サブモジュールを介してプロジェクトに接続できます。 構成ファイルの設定が更新された場合、サブモジュールを更新するだけで十分です。 次に、プロジェクトに実際のルールがあります。
さらに、いくつかの追加のgithub関数を使用できます。 課題システムを使用して、新しいカスタムルールを作成するか、現在のルールについて議論します。 これにより、ルールが拒否された理由を理解できます。 ステータスを便利に監視して、構成ファイルを変更します。
このシステムはCIでうまく機能します。 アナライザーがコード内に少なくとも1つの欠陥を検出した場合、プロジェクト内のすべてのプル要求を維持できないように構成できます。
分析システムを維持することを忘れないでください
静的分析は、アプリケーションのエラーを見つける最も早い方法の1つです。 その結果、最も安い。 静的アナライザーの構成ファイルを保管する最も単純なシステムが、プロジェクトを「同じ」ものにするのに役立つことを願っています。 また、テスト段階の前に複数のバグを見つけることができます。