21

かなり大規模な Python プロジェクトの品質の向上を目指しています。PyLint が提供する警告の種類に満足しています。ただし、それらは数が多すぎて、大規模な組織全体に適用するのは困難です。また、次のバグが発生する可能性に関して、一部のコードは他のコードよりも重要/機密性が高いと考えています。たとえば、2 年前に最後に触れられ、本番環境では使用されない可能性があるスクリプトではなく、100 個のモジュールで使用されるライブラリ メソッドの検証により多くの時間を費やしたいと考えています。また、頻繁に更新されるモジュールを知ることも興味深いでしょう。

この種の分析に役立つ Python などのツールに精通している人はいますか?

4

6 に答える 6

15

あなたの問題は、私が SQA https://sqa.stackexchange.com/a/3082で回答したものと似ています。この問題は、ツーリングを少し簡単にする Java に関連していましたが、以下にいくつかの提案があります。

他の多くの回答は、Python 用の優れたランタイム ツールがないことを示唆しています。私はいくつかの点でこれに同意しません:

  1. カバレッジツールは非常にうまく機能します
  2. Java のツールに関する私の経験に基づくと、Python の静的および動的分析ツールは、強く型付けされた動的でない言語よりも弱いですが、ここで優れたヒューリスティックを提供するには十分に機能します。非常に多くの異常な数の動的機能 (メソッドの追加と削除、メソッドとプロパティの呼び出しのインターセプト、インポートの操作、名前空間の手動変更など) を使用しない限り、問題はこのダイナミズムに関連している可能性があります.. .
  3. Pylint はより単純な問題を取り上げ、動的なクラス/インスタンスの変更とデコレーターの問題を検出しません。したがって、メトリック ツールがこれらを測定しなくても問題ありません。
  4. いずれにせよ、どこに焦点を当てることができるかは、依存関係グラフ以上のものによって決定できます。

コードを選択するためのヒューリスティック

改善するコードを選択する際には、個別に、または組み合わせて機能するさまざまな考慮事項があることがわかりました。最初に必要なのは、生産的な作業の継ぎ目を見つけることだけであることを忘れないでください。作業を開始する前に、絶対に最悪のコードを見つける必要はありません。

あなたの判断を使用してください。

コードベースを数サイクル使用すると、膨大な量の情報が得られ、作業を継続できる状態になります (さらに多くの作業が必要な場合)。

そうは言っても、ここに私の提案があります:

ビジネスにとって高い価値: たとえば、会社に多額の費用がかかる可能性のあるコード。これらの多くは (重要であるため) 明らかであるか広く知られているか、またはランタイム プロファイラーが有効になっているシステムで重要なユース ケースを実行することによって検出される場合があります。カバレッジを使用します。

静的コード メトリクス: メトリクスはたくさんありますが、気になるものは次のとおりです。

これらのツールはファイルベースであることに注意してください。プロジェクト自体に何百ものモジュール(ファイル)があると述べているので、これはおそらく十分な解決策です。

頻繁に変更される: 頻繁に変更されるコードは非常に疑わしいものです。コードは次の場合があります。

  • 歴史的に多くの欠陥があり、経験的には今後もそうなる可能性がある
  • 機能開発からの変更を受けている (VCS に多数のリビジョンがある)

この回答で後述するような VCS 視覚化ツールを使用して、変化の領域を見つけます。

カバーされていないコード: テストでカバーされていないコード。

単体テスト、他の自動テスト、およびカバレッジのある一般的なユーザー テストを実行する (または実行できる) 場合は、ほとんどカバレッジのないパッケージとファイルを調べてください。カバレッジがない理由は 2 つあります。

  • コードは必要 (そして重要) ですが、まったくテストされていません (少なくとも自動的に)。これらの領域は非常にリスクが高い
  • コードは使用されていない可能性があり、削除の候補です。

他の開発者に尋ねる

勤続年数の長い開発者とコーヒーを飲みながら収集できる「におい」の指標に驚くかもしれません。最も勇敢な魂だけが挑戦するコードベースの汚れた領域を誰かがクリーンアップしてくれれば、彼らはとても喜ぶに違いありません。

可視性 - 時間の経過に伴う変化の検出

あなたの環境には DVCS (Git や Mercurial など) または少なくとも VCS (SVN など) があると想定しています。何らかのイシュー トラッカーやバグ トラッカーも使用されていることを願っています。もしそうなら、利用可能な膨大な量の情報があります。開発者がコメントと問題番号で確実にチェックインしている場合はさらに良いでしょう. しかし、それをどのように視覚化して使用するのでしょうか。

単一のデスクトップで問題に取り組むこともできますが、 Jenkinsなどのツールを使用して、継続的インテグレーション (CI) 環境をセットアップすることをお勧めします。答えを短くするために、今後はジェンキンスを想定します。Jenkins には、コード分析に役立つ多数のプラグインが付属しています。私が使う:

これにより、時間の経過に伴う変化が可視化され、そこから掘り下げることができます。たとえば、PyLint 違反がモジュールで増加し始めたとします。私は増加の証拠を持っており、これが発生しているパッケージまたはファイルを知っているので、誰が関与しているかを突き止めて話をすることができます。

履歴データが必要で、Jenkins をインストールしたばかりの場合は、プロジェクトの開始時に開始して現在まで一連のジャンプを行う手動ビルドをいくつか実行できるかどうかを確認してください。VCS からマイルストーン リリース タグ (または日付) を選択できます。

前述のように、もう 1 つの重要な領域は、コード ベースの変更箇所を検出することです。これについては、 Atlassian Fisheyeがとても気に入っています。コミット メッセージ (バグ ID など) やファイル コンテンツの検索が得意なだけでなく、メトリクスを簡単に確認できます。

  • ディレクトリおよびサブディレクトリ別の行数
  • 任意の時点または特定のディレクトリおよび/またはファイルのコミッター
  • ソースコード内の時間と場所の両方によるコミットのパターン
于 2012-10-22T09:39:33.767 に答える
10

残念ながら、あなたはほとんど一人でいます。

適切なテスト セットがある場合は、コード カバレッジとデッド コードを調べます。

まともなプロファイリング設定がある場合は、それを使用して、より多く使用されているものを垣間見ることができます。

結局のところ、あなたはファンイン/ファンアウト分析の方に興味があるようですが、主に静的分析は動的言語に対して恐ろしく信頼性が低いため、私は Python 用の優れたツールを知りません。 t 統計分析ツールが表示されません。

この情報は、JIT コンパイラで利用できるようなものだと思います。(関数、引数の型が) キャッシュ (コンパイル) にあるものは何でも、最もよく使用されます。このデータを PyPy などから取得できるかどうかは、まったくわかりません。

于 2012-09-30T16:45:34.777 に答える
5

私は、これを行うPython用の優れたランタイム分析ツールをまだ見つけていないという点で、他の人たちに同意します。それに対処する方法はいくつかありますが、どれも簡単ではありません。

最も確実なのは、Python のソースを取得し、組み込みのランタイム ログ機能を使用してバイナリを再コンパイルすることだと思います。そうすれば、プロジェクトのコードを変更することなく、既存の環境にスライドさせることができます。もちろん、それを行うのは簡単ではありませんが、いつの日か将来の世代のためにトランクにマージして戻せるかもしれないというボーナスがあります。

再コンパイルしないアプローチの場合、最初に確認するのは、プロファイル ライブラリの決定論的プロファイリング セクションです。

実装方法は、環境の設定方法に大きく依存します。多数の個別のスクリプトやプロジェクトが互いに独立して実行されていますか、それともメインのスクリプト、モジュール、またはパッケージが 1 つだけ他のユーザーに使用されており、メンテナンスを容易にするためにそれらのどの部分を削除できるかを知りたいだけですか? ロードは 1 回だけで、永久に実行するような設定ですか、それとも、ある種のスケジュールでスクリプトをアトミックに実行するだけの状況ですか?

プロジェクト全体のログを実装することもできますが (@Hardbyte の回答で述べたように)、それにはプロジェクト全体を調べて、すべてのコードにログ行を追加する必要があります。それを行う場合は、組み込みの を使用して行うだけでよいとprofiler思います。

于 2012-10-17T18:36:51.707 に答える
5

ソース管理ツールは、頻繁に更新されるモジュール (多くの場合、問題箇所を示す) を適切に示すことができます。

ソース管理がなく、プロジェクトが共有の場所から実行されている場合は、すべてのpycacheフォルダーまたは .pyc ファイルを削除します。時間の経過/使用不足を監視して、使用を示すためにどのファイルが再作成されるかを確認します。

を使用して特定のエントリ ポイントから実行したときに出力される Python インポートを分析する

python -v entry_point

どのモジュールが使用されているかについての洞察が得られる場合があります。ただし、既知のアクセス ポイントがある場合は、カバレッジモジュールを試す必要があります。

より侵入的なソリューションについては、プロジェクト全体のログを設定することを検討してください。分散プログラム上であっても、メトリクスを簡単にログに記録できます。

于 2012-10-17T08:33:02.353 に答える
1

Pylint は、(慎重に検討した後) 正当化されない警告を出すことがあります。その場合、警告をトリガーしないようにコードをリファクタリングできない場合は、特別な#pylint: disable=X0123コメント (X0123 は実際のエラー/警告メッセージ番号) を使用すると便利です。

ソース管理ログを使用して、どのファイルが最も頻繁に変更されているかを確認するという Hardbyte の言及を支持したいと思います。

がインストールされているシステムfindで作業している場合、次の方法で、どのファイルが何をインポートするかを確認できます。grepsort

find . -name '*.py' -exec grep -EH '^import|^from .* import' {} \+| sort |less

すべてのファイルで最も人気のあるインポートを見つけるには;

find . -name '*.py' -exec grep -Eh '^import|^from .* import' {} \+ | sort | less

これら 2 つのコマンドは、プロジェクトから最もよく使用されるモジュールを見つけるのに役立ちます。

于 2012-10-21T12:49:20.147 に答える