内側から外側のパイリント。 彼のやり方

クールなコードを記述するさまざまなアシスタントが、私たち、リンター、タイマー、脆弱性を検索するためのユーティリティをすべて私たちと共に取り囲んでいます。 私たちはそれに慣れており、「ブラックボックス」のような詳細に入らずに使用しています。 たとえば、Pythonコードの最適化と改善に不可欠なツールの1つであるPylintの原理を理解している人はほとんどいません。

しかし、 マキシムマザエフは自分のツールを理解することがいかに重要かを知っており、 モスクワPython Conf ++で私たちに語った。 実際の例を使用して、彼はPylintの内部デバイスとそのプラグインの知識がコードレビュー時間の短縮、コード品質の向上、そして一般的に開発効率の向上にどのように役立つかを示しました。 以下は復号化命令です。

なぜPylintが必要なのですか？

既にそれを使用している場合、「Pylintの内部に何があるのか​​、なぜこの知識が役立つのか」という疑問が生じるかもしれません。

通常、開発者はコードを記述し、リンターを起動し、改善すべき点、コードをより美しくする方法についてのメッセージを受け取り、提案された変更を行います。 これで、コードが読みやすくなり、同僚に見せることを恥じることがなくなりました。

長い間、これは彼らがCIANのPylintで正確に機能する方法でしたが、マイナーな追加がありました：構成を変更し、不要なルールを削除し、最大文字列長を増やしました。

しかし、ある時点で彼らは問題に直面しました。その解決のために、私はPylintの奥深くを掘り下げて、それがどのように機能するかを理解しなければなりませんでした。 この問題とそれを解決する方法は何ですか、読んでください。


スピーカーについて：開発中の5年間、Maxim Mazaev（ バックスラッシュ ）はCIANで働いています。 Python、非同期、および関数型プログラミングを深く学びます。

シアンについて

CIANは不動産業者のいる不動産会社であり、不動産業者の代わりにプログラマーがいることに気づいたとき、ほとんどの人が信じています。

私たちは全米リアルター協会加入者がいない技術会社ですが、多くのプログラマーがいます。

• 1日あたり100万のユニークユーザー。
• モスクワとサンクトペテルブルクでの不動産の販売とレンタルのための最大の掲示板。 2018年、彼らは連邦レベルに入り、ロシア全土で働きました。
• 開発チームのほぼ100人が、そのうち30人が毎日Pythonコードを記述しています。

毎日、数百、数千行の新しいコードが生産されています。 コードの要件は非常に簡単です。

• まともな品質のコード。
• 文体的な均一性。 すべての開発者は、リポジトリに「vinaigrette」なしで、ほぼ同様のコードを記述する必要があります。

もちろん、これを実現するには、コードレビューが必要です。

コードレビュー

CIANのコードレビューは2段階で行われます。

1. 最初の段階は自動化されています。 Jenkinsロボットはテストを実行し、Pylintを実行し、マイクロサービスを使用しているため、マイクロサービス間のAPIの一貫性をチェックします。 この段階でテストが失敗するか、リンターに奇妙な何かが表示された場合、これはプル要求を拒否し、修正のためにコードを送信する機会です。
   
2. 最初の段階が成功した場合、2番目の段階-2 人の 開発者からの承認。 彼らは、ビジネスロジックの観点からコードがどれだけ優れているかを評価したり、プルリクエストを承認したり、修正のためにコードを返したりすることができます。
   

コードレビューの問題

次の理由により、プルリクエストはコードレビューに合格しない場合があります。

• 開発者が問題を効果的または誤って解決した場合のビジネスロジックのエラー。
• コードスタイルの問題。

リンターがコードをチェックする場合、スタイルの問題は何ですか？

Pythonで書く人は誰でも、 PEP-8コードを書くためのガイドがあることを知っています。 他の標準と同様に、PEP-8は非常に一般的であり、開発者としての私たちにとってこれは十分ではありません。 一部の場所で標準を指定し、他の場所で拡張したい。

そのため、コードの外観と動作を内部で調整し、 「Decline Cian Proposals」と呼びました。



「Decline Cian Proposals」-一連のルール、現在は約15あります。これらの各ルールは、プルリクエストが拒否され、修正のために送信されるための基礎です。

生産的なコードレビューを妨げるものは何ですか？

私たちの内部ルールには1つの問題があります-リンターはそれらについて知りません、そして彼が知っていたら奇妙です-それらは内部です。

タスクを実行する開発者は、常にルールを覚えておく必要があります。 ルールの1つを忘れると、コードレビューのプロセスでレビュアーが問題を指摘し、タスクは改訂に進み、タスクのリリース時間が長くなります。 エラーの修正と修正の後、テスターはタスクの内容を覚えて、コンテキストを切り替える必要があります。

これにより、開発者とレビューアの両方に問題が発生します。 その結果、コードレビューの速度が大幅に低下します。 コードのロジックを分析する代わりに、テスターは視覚スタイルの分析を開始します。つまり、リンターの作業を実行します。つまり、コードを1行ずつスキャンし、インポート形式のインデントの不一致を探します。

この問題を取り除きたいです。

しかし、私たちにあなたのリンターを書いてはいけませんか？

この問題は、すべての内部合意について知っているツールによって解決され、実装のコードをチェックできるようになります。 独自のリンターが必要ですか？

そうでもない。 すでにPylintを使用しているため、このアイデアは馬鹿げています。 これは便利なリンターであり、開発者に好まれ、すべてのプロセスに組み込まれています。ジェンキンスで実行され、完全に満足のいく美しいレポートを生成し、コメントの形でリクエストをプルします。 すべてが正常で、 2番目のリンターは必要ありません 。

それでは、自分のリンターを書きたくない場合、どのように問題を解決するのでしょうか？

Pylintプラグインを書く

Pylint用のプラグインを作成できます。これらはチェッカーと呼ばれます。 各内部ルールの下で、それをチェックする独自のチェッカーを作成できます。

そのようなチェッカーの2つの例を考えてみましょう。

例1

ある時点で、コードには「TODO」という形式の多くのコメントが含まれていることが判明しました。リファクタリング、不要なコードの削除、または美しく書き直すことを約束します。 そのようなコメントには問題があります-彼らはあなたに何も義務付けません。

問題

開発者は約束を書き、吐き出し、安心して次のタスクを実行しました。


要約すると：

• 約束のあるコメントは長年にわたって続き、従わない。
• コードが散らばっています。
• 技術的な負債は何年も積み上げられてきました。

たとえば、3年前の開発者は、リリースが成功した後に何かを削除することを約束しましたが、リリースは3年で行われましたか？ たぶんはい。 この場合、コードを削除する必要がありますか？ これは大きな質問ですが、おそらくそうではありません。

解決策：Pylintのチェッカーを作成する

開発者がそのようなコメントを書くことを禁止することはできませんが、追加の作業をさせることができます。トラッカーでタスクを作成して約束を確定します。 その後、私たちは彼女のことを間違いなく忘れません。

TODOフォームのすべてのコメントを見つけ、各コメントにJiraのタスクへのリンクがあることを確認する必要があります。 書きましょう。

Pylintに関するチェッカーとは何ですか？ これは、チェッカーの基本クラスから継承し、特定のインターフェイスを実装するクラスです。

class TodoIssueChecker(BaseChecker): _ _implements_ _ = IRawChecker 

私たちの場合、これはIRawChecker-いわゆる「生」チェッカーです。

生のチェッカーはファイルの行を反復処理し、行に対して特定のアクションを実行できます。 この場合、各行でチェッカーはコメントとタスクへのリンクに似たものを探します。

チェッカーの場合、発行するメッセージのリストを決定する必要があります。

 msgs = { '9999': ('  TODO    ', issue-code-in-todo', ' ')} 

メッセージには次のものがあります。

• 説明は短くて長いです。
• チェッカーコードと、それがどのようなメッセージであるかを決定する短いニーモニック名。

メッセージコードの形式は「C1234」です。

• 最初の文字は、さまざまなタイプのメッセージに対して明確に標準化されています。 [W]警告。 [E]ヨーグ; [F] atal; [R] efactoring。 手紙のおかげで、報告書は何が起こっているのかを即座に示しています。緊急に対処する必要がある合意や致命的な問題を思い出させるものです。
• Pylintに固有の4つの乱数。

チェックが不要になった場合、チェックを無効にするためにコードが必要です。 Pylint：disableと短い英数字コードまたはニーモニック名を書くことができます：

 # Pylint: disable=C9999 # Pylint: disable=issue-code-in-todo 

Pylintの著者は、英数字コードを放棄し、ニーモニックを使用することを推奨しています。これはより視覚的です。

次のステップは、 process_moduleというメソッドを定義することです。



名前は非常に重要です。 Pylintがメソッドを呼び出すため、メソッドはそのように呼び出す必要があります。

nodeパラメーターはモジュールに渡されます。 この場合、それが何であるか、またはどのタイプであるかは関係ありません。ノードには、行ごとにファイルを返すストリームメソッドがあることを覚えておくことが重要です。

ファイルを調べて、各行でコメントとタスクへのリンクを確認できます。 コメントはあるがリンクがない場合は、チェッカーコードと行番号を含む「issue-code-in-todo」フォームの警告をスローします。 アルゴリズムは非常に簡単です。

チェッカーを登録して、Pylintが認識できるようにします。 これは、 登録機能によって行われます。

 def register(linter: Pylinter) -> None: linter. register_checker ( TodoIssueChecker(linter) ) 

• Pylintのインスタンスが関数に入ります。
• register_checkerメソッドを呼び出します。
• メソッドにチェッカーを渡します。

重要なポイント：チェッカーモジュールはPylthonpathに存在している必要があります。これにより、Pylintは後でそれをインポートできます。

登録されたチェッカーは、タスクへのリンクのないコメント付きのテストファイルによってチェックされます。

 $ cat work. # T0D0:   , -! $ pylint work. --load-plugins todo_checker … 

テストのために、Pylintを実行し、モジュールを渡し、 load-pluginsパラメーターを使用してチェッカーを転送し、リンター内で2つのフェーズを実行します。

フェーズ1.プラグインの初期化

• プラグインを含むすべてのモジュールがインポートされます。 Pylintには、内部チェッカーと外部チェッカーがあります。 それらはすべて一緒になってインポートされます。
• 登録-module.register（self） 。 各チェッカーに対して、Pylintインスタンスが渡されるregister関数が呼び出されます。
• チェックが実行されます：パラメーターの有効性、メッセージ、オプション、および正しい形式のレポートの存在。

フェーズ2.チェッカーのプールを解析する

フェーズ1の後、さまざまな種類のチェッカーの完全なリストが残ります。

• ASTチェッカー
• 生チェッカー。
• トークンチェッカー。

リストから、未加工のチェッカーインターフェイスに関連するものを選択します。どのチェッカーがIRawCheckerインターフェイスを実装しているかを確認し、それらを自分用に取ります。

選択したチェッカーごとに、 checker.process_module（モジュール）メソッドを呼び出して、チェックを実行します。

結果

テストファイルでチェッカーを再度実行します。

 $ cat work. # T0D0:   , -! $ pylint work,  --load-plugins todo_checker : 0,0:   T0D0     (issue-code-in-todo) 

TODOを含むコメントがあり、タスクへのリンクがないことを示すメッセージが表示されます。

この問題は解決され、コードレビューの過程で、開発者は目でコードをスキャンしたり、コメントを見つけたり、コード作成者に同意があり、リンクを残すことをお勧めすることを思い出させる必要はありません。 すべてが自動的に行われ、コードのレビューが少し速くなります。

例2。キーワード引数

位置引数を取る関数があります。 多数の引数がある場合、関数を呼び出すときに、引数がどこにあるのか、なぜ必要なのかは明確ではありません。

問題

たとえば、次の関数があります。

 get_offer_by_cian_id( "sale", rue, 859483, ) 

コードにはセールとTrueがあり、それらの意味が明確ではありません。 多くの引数がある関数が名前付き引数でのみ呼び出される場合は、はるかに便利です。

 get_offer_by_cian_id( deal_type="sale", truncate=True, cian_id=859483, ) 

これは優れたコードであり、パラメータがどこにあるかがすぐにわかり、シーケンスを混同しません。 そのような場合をチェックするチェッカーを作成してみましょう。

前の例で使用した「生の」チェッカーは、このような場合に書くのは非常に困難です。 超複雑な正規表現を追加できますが、そのようなコードは読みにくいです。 Pylintが抽象AST構文ツリーに基づいて別のタイプのチェッカーを記述できるようにしてくれるのは良いことであり、これを使用します。

ASTに関する歌詞の余談

ASTまたは抽象構文ツリーはコードのツリー表現であり、頂点はオペランドであり、リーフは演算子です。

たとえば、1つの位置引数と2つの名前付き引数がある関数呼び出しは、抽象ツリーに変換されます。


Call型の頂点があり、次の要素があります。

• funcと呼ばれる関数属性。
• タイプがConstで値が112のノードが存在する位置引数argsのリスト。
• 名前付き引数のリストキーワード。

この場合のタスク：

• モジュールで、タイプCall（関数呼び出し）を持つすべてのノードを見つけます。
• 関数が取る引数の総数を計算します。
• 3つ以上の引数がある場合は、ノードに位置引数がないことを確認してください。
• 位置引数がある場合は、警告を表示します。

 ll( func=Name(name='get_offer'), args=[Const(value=1298880)], keywords=[ … ]))] 

Pylintの観点から見ると、ASTベースのチェッカーはベースチェッカークラスを継承し、 IAstroidCheckerインターフェイスを実装するクラスです。

 class NonKeywordArgsChecker(BaseChecker): -_ _implements_ _ = IAstroidChecker 

最初の例のように、チェッカーの説明、メッセージコード、短いニーモニック名がメッセージリストに表示されます。

 msgs = { '9191': (' ', keyword-only-args', ' ')} 

次のステップはvisit_callメソッドの定義です：

 def visit_call(self, node: Call) … 

このメソッドを呼び出す必要はありません。 その中で最も重要なのはvisit_接頭辞であり、それから私たちの興味を引く頂点の名前に小さな文字が付きます。

• ASTパーサーはツリーをウォークスルーし、各頂点について、チェッカーにvisit_ <Name>インターフェイスが定義されているかどうかを確認します。
• もしそうなら、それを呼び出します。
• すべての子供を再帰的に通過します。
• ノードを離れるとき、leave_ <Name>メソッドを呼び出します。

この例では、visit_callメソッドは入力としてCallタイプノードを受け取り、3つ以上の引数があるかどうか、および警告をスローしてコードをノード自体に渡すための位置引数があるかどうかを確認します。

 def visit_call(self, n): if node.args and len(node.args + node.keywords) > 2: self.add_message( 'keyword-only-args', node=node ) 

前の例のようにチェッカーを登録します。Pylintインスタンスを転送し、register_checkerを呼び出し、チェッカー自体を渡して起動します。

 def register(linter: Pylinter) -> None: linter.register_checker( TodoIssueChecker(linter) ) 

これは、3つの引数があり、そのうちの1つだけに名前が付けられているテスト関数呼び出しの例です。

 $ cat work. get_offers(1, True, deal_type="sale") $ Pylint work.py --load-plugins non_kwargs_checker … 

これは、私たちの観点から誤って呼び出される可能性のある関数です。 Pylintを起動します。

前の例のように、プラグインの初期化フェーズ1は完全に繰り返されます。

フェーズ2. ASTでのモジュールの分析

コードは解析されてASTツリーになります。 分析はAstroidライブラリによって実行されます 。

ASTではなくAstroidを使用する理由（stdlib）

Astroidは内部的には標準のPython ASTモジュールを使用しませんが、 typed_ast型付きASTパーサーは、PEP 484 型ヒントをサポートするという点で異なります。 興味深いことに、ASTには同じバグがあり、並行して修復されます。

 from module import Entity def foo(bar): # type: (Entity) -> None return 

以前は、Astroidは標準のASTモジュールを使用していました。このモジュールでは、2番目のPythonで使用されているコメントで定義されているタイフィントを使用する問題に遭遇する可能性があります。 Pylintを使用してこのようなコードをチェックすると、インポートされたEntityクラスはコメント内にのみ存在するため、特定の時点までは未使用のインポートを誓います。

ある時点で、Guido Van RossumはGitHubでAstroidに来て次のように言いました。 友達になろう！」

仕事が始まった！ 2年が経ち、この春のPylintは既に型付きASTパーサーに切り替え、そのようなことを誓うことをやめました。 taiphintsのインポートは、未使用としてマークされなくなりました。

AstroidはASTパーサーを使用してコードをツリーに解析し、構築時に興味深いことを行います。 たとえば、 import *を使用する場合、すべてをアスタリスクでインポートし、ローカルに追加して、未使用のインポートでのエラーを防ぎます。

変換プラグインは、すべての属性が動的に生成されるメタクラスに基づいたいくつかの複雑なモデルがある場合に使用されます。 この場合、Astroidの意味を理解するのは非常に困難です。 チェックすると、Pylintは、モデルにアクセスしたときにそのような属性がないことを誓い、Transformプラグインを使用して問題を解決できます。

• Astroidが抽象ツリーを変更し、Pythonの動的な性質を理解するのに役立ちます。
• ASTに役立つ情報を追加します。

典型的な例は、 pylint-djangoです。 複雑なdjangoモデルで作業するとき、リンターはしばしば未知の属性を誓います。 Pylint-djangoはこの問題を解決するだけです。

フェーズ3.チェッカーのプールを解析する

チェッカーに戻ります。 再度チェッカーのリストがあり、そこからASTチェッカーインターフェイスを実装するチェッカーが見つかります。

フェーズ4.ノードのタイプ別にチェッカーを解析する

次に、各チェッカーのメソッドを見つけます。2つのタイプがあります。

• visit_ <ノード名>
• lev_<ノード名>。

ツリー内を歩いているときにノードを呼び出す必要があるノードを知っていると便利です。 したがって、キーはノードの名前であり、値はこのノードへのアクセスの事実に関心があるチェッカーのリストである辞書を理解します。

 _visit_methods = dict( < > : [checker1, checker2 ... checkerN] ) 

leave-methodsでも同じです。ノード名の形式のキー、このノードからの退出の事実に関心のあるチェッカーのリスト。

 _leave_methods = dict( < >: [checker1, checker2 ... checkerN] ) 

Pylintを起動します。 3つ以上の引数があり、その中に位置引数がある関数があるという警告を示しています。

 $ cat work. get_offers(1, True, deal_type="sale") $ Pylint work.py --load-plugins non_kwargs_checker C: 0, 0:  c >2      (keyword-only-args) 

問題は解決しました。 これで、コードレビュープログラマーは関数の引数を読み取る必要がなくなり、リンターがこれを行います。 本番環境での時間、コードのレビュー、タスクの時間を節約しました。

そして、テストを書くために？

Pylintを使用すると、チェッカーの単体テストを実行でき、非常に簡単です。 リンターの観点から見ると、テストチェッカーは抽象CheckerTestCaseを継承するクラスのように見えます。 チェックインされているチェッカーを示す必要があります。

 class TestNonKwArgsChecker(CheckerTestCase): CHECKER_CLASS = NonKeywordArgsChecker 

ステップ1.チェックするコードの一部からテストASTノードを作成します。

 node = astroid.extract_node( "get_offers(3, 'magic', 'args')" ) 

手順2.ノードに入るチェッカーが、対応するメッセージをスローするかしないかを確認します。

 with self.assertAddsMessages(message): self.checker.visit_call(node) 

トークンチェッカー

TokenCheckerと呼ばれる別のタイプのチェッカーがあります。 字句解析の原理で動作します。 Pythonには、字句スキャナーの機能を実行し、コードをトークンのリストに分割するtokenizeモジュールがあります。 次のようになります。


変数名、関数名、およびキーワードはタイプNAMEのトークンになり、区切り文字、括弧、コロンはタイプOPのトークンになります。 さらに、インデント、改行、逆変換用の個別のトークンがあります。

PylintがTokenCheckerと連携する方法：

• テスト中のモジュールはトークン化されます。
• トークンの膨大なリストがITokenCheckerを実装するすべてのチェッカーに渡され、 process_tokens （トークン）メソッドが呼び出されます。

TokenCheckerの使用は見つかりませんでしたが、Pylintが使用するそのような例があります。

• スペルチェック 。 たとえば、テキストタイプのすべてのトークンを取得し、字句リテラシーを確認したり、ストップワードリストの単語を確認したりできます。
• インデント 、スペースを確認してください 。
• 文字列を操作します 。 たとえば、Python 3がUnicodeリテラルを使用していないことを確認したり、バイト文字列にASCI文字のみが存在することを確認したりできます。

結論

コードレビューに問題がありました。 開発者はリンターの仕事をし、無意味なコードスキャンに時間を費やし、作者にエラーを通知しました。 Pylintの場合：

• 定期点検をリンターに移し、内部契約を実施しました。
• コードレビューの速度と品質の向上。
• 拒否されたプルリクエストの数を減らし、本番環境でタスクを渡す時間を短縮しました。

簡単なチェッカーは30分で書かれ、複雑なチェッカーは数時間で書かれます。 チェッカーは、書き込みにかかる時間よりもはるかに多くの時間を節約し、拒否されていないいくつかのプルリクエストに対処します。

Pylintの詳細とチェッカーの作成方法については公式ドキュメントで学ぶことができますが、チェッカーの作成という点ではかなり貧弱です。 たとえば、TokenCheckerについては言及されているだけですが、チェッカー自体の記述方法については言及されていません。 詳細については、GitHubのPylintソースを参照してください 。 標準パッケージに含まれているチェッカーを確認し、独自のチェッカーを作成するためのインスピレーションを得ることができます。

Pylintの内部設計に関する知識により、工数が削減され、簡素化されます
パフォーマンスとコードの改善。 時間を節約し、良いコードを書き、
リンターを使用します。

次のモスクワPython Conf ++カンファレンスは2019年4月5日に開催され 、今では早期birfチケットを予約できます。 意見を集めてレポートに申し込むと 、訪問が無料になり、レポートの準備に関するコーチングを含む素敵なパンがボーナスとして送られます。

私たちの会議は、志を同じくする人々、産業エンジンとの出会いのためのプラットフォームであり、Python開発者が愛するもの：バックエンドとウェブ、データ収集と処理、AI / ML、テスト、IoTなどについて話し合い、議論するためのプラットフォームです。 秋の様子は、 Pythonチャンネルの ビデオレポートをご覧になり、チャンネルに登録してください。近日中にカンファレンスからの最高のレポートを無料でアクセスできるように投稿します。