NoVerify：VKontakte TeamのPHPのlinterはパブリックドメインになりました

git pushのたびに変更をチェックし、PHPで500万行のコードベースで5〜10秒でそれを行うのに十分高速であることが判明したリンターをどのように作成したかを説明します。 これをNoVerifyと呼びました。



NoVerifyは、定義への移行や使用の検索などの基本的なことをサポートし、 Language Serverモードで動作できます。 まず、ツールは潜在的なエラーの検索に焦点を合わせていますが、スタイルをチェックすることもできます。 今日、そのソースコードはGitHubのオープンソースに登場しました。 記事の最後にあるリンクを探してください。

リンターが必要な理由

2018年半ばに、PHPコードのリンターを実装する時が来たと判断しました。 2つの目標がありました。ユーザーに表示されるエラーの数を減らすことと、コードスタイルへの準拠をより厳密に監視することです。 主な重点は、典型的なエラーの防止にありました。コード内の宣言されていない変数や未使用の変数、到達不能なコードなどの存在です。 また、静的アナライザーがコードベース（執筆時点で500万から600万行のPHPコード）で可能な限り迅速に動作することを望んでいました。



おそらくご存知のように、ほとんどのサイトのソースコードはPHPで記述され、 KPHPを使用してコンパイルされているため 、これらのチェックをコンパイラに追加することは論理的です。 しかし、実際には、すべてのコードがKPHPを介して実行する意味がない場合があります。たとえば、コンパイラはサードパーティライブラリとの互換性が弱いため、サイトの一部では通常のPHPが引き続き使用されます。 これらも重要であり、リンターがチェックする必要があるため、残念ながら、KPHPに統合する方法はありません。

NoVerifyを選ぶ理由

PHPコードの量を考えると（500万から600万行であることを思い出します）、すぐに「修正」して、リンターでチェックに合格することはできません。 それでも、変化するコードが徐々にクリーンになり、コーディング標準に厳密に従い、エラーも少なくなるようにしたいと思います。 そのため、リンターは、開発者が起動する変更をチェックでき、残りを誓う必要はないと判断しました。



これを行うには、リンターはプロジェクト全体のインデックスを作成し、変更前後のファイルを完全に分析し、生成された警告の差を計算する必要があります。 新しい警告は開発者に表示されます。プッシュを行う前に修正​​する必要があります。



ただし、この動作が望ましくない場合があり、開発者はローカルフックなしでプッシュできますgit push --no-verify



ます。 オプション--no-verify



およびlinterに名前を付けました:)

代替案は何でしたか

VKのコードベースはほとんどOOPを使用せず、基本的に静的メソッドを持つ関数とクラスで構成されます。 PHPのクラスが自動ロードをサポートする場合、関数はサポートしません。 そのため、大幅な変更を加えずに静的アナライザーを使用することはできません。これは、オートロードがすべての欠落コードをロードするという事実に基づいて作業を行います。 そのようなリンターには、例えば、 Vimeoの詩 salが含まれます。



次の静的分析ツールを調べました。

• PHPStan-シングルスレッド、オートロードが必要、コードベース分析は30分で30％に達しました。
• ファン -20プロセスのクイックモードでも、20分後に分析が5％停止しました。
• 詩 sal-自動読み込みが必要で、分析には10分かかりました（さらに高速になりたいです）。
• PHPCS-スタイルをチェックしますが、ロジックはチェックしません。
• phpcf-フォーマットのみをチェックします。

記事のタイトルから推測できるように、これらのツールはいずれも要件を満たしていないため、独自のツールを作成しました。

プロトタイプはどのように作成されましたか？

まず、本格的なリンターを作ってみる価値があるかどうかを理解するために、小さなプロトタイプを作成することにしました。 リンターの重要な要件の1つはその速度であるため、PHPではなくGoを選択しました。 「高速」とは、できるだけ早く、できれば10〜20秒以内に開発者にフィードバックを提供することです。 そうでなければ、「コードを修正し、リンターを再度実行する」サイクルが開発を著しく遅くし始め、人々の気分を台無しにします:)



Goはプロトタイプに選択されているため、PHPパーサーが必要です。 それらのいくつかがありますが、 php-parserプロジェクトは私たちにとって最も成熟したように見えました。 このパーサーは完全ではなく、まだ完成中ですが、私たちの目的には非常に適しています。



プロトタイプの場合、最も単純な、一見したところ、検査の1つである未定義変数へのアクセスを実装しようとすることが決定されました。



このような検査を実装するための基本的な考え方は単純に見えます。各ブランチ（たとえば、if）に対して、個別のネストされたスコープを作成し、その出口で変数のタイプを組み合わせます。 例：

 <?php if (rand()) { $a = 42; //  : { $a: int } } else { $b = "test"; $a = "another_test"; //  : { $b: string, $a: string } } //   : { $b: string?, $a: int|string } echo $a, $b; //       , //   $b   
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

シンプルに見えますよね？ 通常の条件文の場合、すべてがうまく機能します。 ただし、たとえば、ブレークなしで切り替えを処理する必要があります。

 <?php switch (rand()) { case 1: $a = 1; // { $a: int } case 2: $b = 2; // { $a: int, $b: int } default: $c = 3; // { $a: int, $b: int, $c: int } } // { $a: int?, $b: int?, $c: int }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

$ cが実際に常に定義されることは、コードからすぐにはわかりません。 具体的には、この例は架空のものですが、リンターにとって（そしてこの場合も人にとって）難しい瞬間がどのようなものであるかをよく示しています。



より複雑な例を考えてみましょう。

 <?php exec("hostname", $out, $retval); echo $out, $retval; // { $out: ???, $retval: ??? }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

exec関数のシグネチャを知らないと、$ outと$ retvalが定義されるかどうかはわかりません。 組み込み関数の署名は、リポジトリgithub.com/JetBrains/phpstorm-stubsから取得できます。 ただし、カスタム関数を呼び出すときに同じ問題が発生し、その署名はプロジェクト全体のインデックスを作成することによってのみ見つけることができます。 exec関数は、参照によって2番目と3番目の引数を取ります。つまり、変数$ outおよび$ retvalを定義できます。 ここで、これらの変数へのアクセスは必ずしもエラーではなく、リンターはそのようなコードを誓うべきではありません。



参照による暗黙の受け渡しに関する同様の問題がメソッドで発生しますが、同時に、変数タイプを出力する必要性が追加されます。

 <?php if (rand()) { $a = some_func(); } else { $a = other_func(); } $a->some_method($b); echo $b;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのクラスでsome_methodというメソッドを後で見つけるには、some_func（）およびother_func（）関数が返す型を知る必要があります。 そうして初めて、変数$ bが定義されるかどうかを判断できます。 多くの場合、単純な関数とメソッドにはphpdocアノテーションがないため、状況は複雑です。そのため、実装に基づいて関数とメソッドのタイプを計算できる必要があります。



プロトタイプを開発するとき、最も単純な検査が正常に機能するように、すべての機能の約半分を実装する必要がありました。

言語サーバーとして働く

リンターのロジックをデバッグしやすくし、リンターが発行する警告を見やすくするために、PHPの言語サーバーとして動作モードを追加することにしました。 Visual Studio Codeとの統合モードでは、次のようになります。







このモードでは、仮説をテストし、複雑なケースをテストするのが便利です（その後、もちろんテストを書く必要があります）。 パフォーマンスをテストすることも良いです：Goのphp-parserが大きなファイルであっても良い速度を示します。



言語サーバーのサポートは、リンタールールをデバッグすることが主な目的であるため、理想とはほど遠いものです。 それでも、このモードにはいくつかの追加機能があります。

1. 変数名、定数、関数、プロパティ、およびメソッドのヒント。
2. 派生型の変数を強調表示します。
3. 定義に移動します。
4. 用途を検索します。

「遅延」型推論

言語サーバーモードでは、次の作業が必要です。1つのファイルのコードを変更してから、別のファイルに切り替えると、関数またはメソッドで返される型に関する更新済みの情報を操作する必要があります。 ファイルが次の順序で編集されていると想像してください。

 <?php //  A.php,  1 class A { /** @var int */ public $prop; } //  B.php,   class B { public static function something() { $obj = new A; return $obj->prop; } } //  C.php,   $c = B::something(); // $c   int //  A.php,  2 class A { /** @var string <---   string */ public $prop; } //  C.php,   $c = B::something(); // $c   string,   B.php,  C.php  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

開発者に常にPHPDocを書くことを強制しないので（特にそのような単純な場合）、関数B :: something（）が返す型に関する情報を保存する方法が必要です。 そのため、A.phpファイルが変更されると、C.phpファイルの型情報はすぐに最新の状態になります。



考えられる解決策の1つは、「遅延型」を保存することです。 たとえば、B :: something（）メソッドの戻り値の型は、実際には式の型（新しいA）-> propです。 このフォームでは、リンターはタイプに関する情報を保存します。これにより、各ファイルのすべてのメタ情報をキャッシュし、このファイルが変更された場合にのみ更新できます。 これは、タイプに関する誤った特定の情報がどこにも漏れないように、慎重に行う必要があります。 また、型推論ロジックが変更されたときにキャッシュバージョンを変更する必要があります。 それにもかかわらず、このようなキャッシュは、すべてのファイルの繰り返し解析と比較して、インデックス作成フェーズ（後で説明します）を5〜10倍高速化します。

作業の2つのフェーズ：インデックス作成と分析

覚えているとおり、最も単純なコード分析であっても、少なくともプロジェクト内のすべての関数とメソッドに関する情報が必要です。 つまり、プロジェクトとは別に1つのファイルのみを分析することはできません。 そしてまだ-これは1つのパスで行うことはできません。たとえば、PHPでは、ファイルでさらに宣言されている関数にアクセスできます。



これらの制限により、リンターの操作は2つのフェーズで構成されます。プライマリインデックス作成と、必要なファイルのみの後続の分析です。 次に、これら2つのフェーズについて詳しく説明します。

インデックス作成フェーズ

このフェーズでは、すべてのファイルが解析され、メソッドや関数のコード、およびトップレベルのコードのローカル分析が行われます（たとえば、グローバル変数のタイプを決定するため）。 宣言されたグローバル変数、定数、関数、クラス、およびそれらのメソッドに関する情報が収集され、キャッシュに書き込まれます。 プロジェクト内のファイルごとに、キャッシュはディスク上の個別のファイルです。



プロジェクトに関するすべてのメタ情報のグローバルディクショナリは、将来変更されることはなく、個々のピースからコンパイルされます。



*言語サーバーとしての動作モードに加えて、変更されたファイルのインデックス作成と分析が編集ごとに実行されます。

分析フェーズ

このフェーズでは、メタ情報（関数、クラスなど）を使用して、すでにコードを直接分析できます。 以下は、NoVerifyがデフォルトでチェックできるもののリストです。

• 到達不能コード;
• 配列としてのオブジェクトへのアクセス。
• 関数を呼び出すときの引数の数が不十分です。
• 未定義のメソッド/関数を呼び出す;
• 欠落しているクラスプロパティ/定数へのアクセス。
• クラスの欠如;
• 無効なPHPDoc
• 未定義の変数へのアクセス。
• 常に定義されているわけではない変数へのアクセス。
• スイッチ/ケース構造におけるケースの後の「ブレーク」の不在;
• 構文エラー。
• 未使用の変数。

リストはかなり短いですが、プロジェクト固有のチェックを追加できます。



リンターの操作中、最も有用な検査は最後の（未使用の変数）だけであることが判明しました。 これは、コードをリファクタリング（または新しいコードを記述）して変数名に封印するとよく起こります。このコードはPHPの観点からは有効ですが、ロジックに誤りがあります。

作業速度

プッシュしたい変更はどれくらいの期間チェックされますか？ それはすべてファイルの数に依存します。 NoVerifyを使用すると、プロセスには最大1分かかることがあります（これはリポジトリ内の1400ファイルを変更したときでした）が、編集が少ない場合、通常すべてのチェックは4-5秒で合格します。 この間、プロジェクトは完全にインデックス付けされ、新しいファイルとその分析が解析されます。 PHP用のリンターを作成することができました。これは、大規模なコードベースでもすばやく動作します。

結果は何ですか？

ソリューションはGoで記述されているため、すべての関数とクラスの定義をPHPに組み込むには、 github.com / JetBrains / phpstorm-stubsリポジトリを使用する必要があります。 その見返りとして、高速な作業（1秒あたり100万行のインデックス付け、1秒あたり10万行の分析）が得られ、git pushフックの最初のステップの1つとしてリンターを使用してチェックを追加できました。



新しい検査を作成するための便利なベースが開発され、PHPStormに近いレベルのコード理解が達成されました。 差分計算を使用するモードがすぐにサポートされているという事実により、コードを徐々に改善し、新しいコードで潜在的に問題のある新しい構成を回避することができます。



diffのカウントは理想的ではありません。たとえば、1つの大きなファイルがいくつかの小さなファイルに分割された場合、git、したがってNoVerifyはコードが移動されたことを判断できず、リンターは見つかったすべての問題を修正する必要があります。 この点で、差分計算は大規模なリファクタリングを妨げるため、このような場合、多くの場合無効になります。



Goでリンターを作成することにはもう1つの利点があります。ASTパーサーはPHPよりも高速でメモリ消費量が少ないだけでなく、PHPで実行できるものに比べて後続の分析も非常に高速です。 これは、リンターがコードのより複雑で詳細な分析を実行しながら、高いパフォーマンスを維持できることを意味します（たとえば、「遅延型」機能では、処理中にかなりの数の計算が必要です）。

オープンソース

GitHubのオープンソースで利用可能なNoVerify



プロジェクトでの使用をお楽しみください！



UPD： WebAssemblyで機能するデモを準備しました。 このデモの唯一の制限は、phpstorm-stubsの関数定義がないことです。したがって、リンターは組み込み関数を誓います。



VKontakteインフラストラクチャ部門の開発者Yuri Nasretdinov