3

既存のJSPプロジェクトを前提として、プロジェクトの「ビュー」部分の複雑さ/サイズを感じてみたいと思います。これが私がこれまでにしたことです：

  • 過去xか月以内に本番サーバーからコンパイルされたJSPのリストを取得しました（これにより、「デッド」jspsが排除されます）。
  • クイックスキャナーを作成して、コンパイルされたページにインポートされたJSPフラグメントファイルを見つけます。
  • ファイルのサイズとタイムスタンプをファイルシステムから削除しました。

これで、ページとそれらのページにインポートされたフラグメントのリスト、サイズ、およびそれらが最後にコンパイルおよび変更された時刻がわかりました。

しかし、私が本当に知る必要があるのは、ページがどれほど複雑かということです。これらのページのいくつかには、大量のJavaコードが含まれています。これは大きなプロジェクトなので、各ページとサイズを確認するのは面倒で、おそらくそれほど正確ではありません。

<％と％>の間のコードを測定する別のスキャナーを作成するつもりでしたが、すでにそれを実行できる何らかのメトリックジェネレーターがあるのではないかと思いました。ページの「大きさ」とページのコードの「大きさ」を出力したいと思います。重要なのは、小、中、大、大のページを分離することです。したがって、絶対的な測定は相対的な測定よりも重要ではありません。

編集： JavaScript行、Java（Scriptlet）行、HTML行、およびtaglib使用のインスタンスの数をカウントするために別のスキャナーを作成しました。したがって、スキャナーの結果を使用することにより、「複雑さ」を示すいくつかのパラメーターがあります。本当にきれいではありませんが、今のところは大丈夫です。

4

1 に答える 1

1

したがって、問題は、HTML に散在する Java コードが散在しているため、標準のメトリック ツールが機能しないことです。

すぐに使えるものではありませんが、ソースコード検索エンジンはかなり近いものになるかもしれません。これは、言語に正確な字句抽出を使用してソース コードをインデックス化することにより、大規模なコード ベースを検索するためのツールです。ここでの関連性は、インデックスを作成するファイルの SLOC、コメント数、Halstead および Cyclomatic 測定値を計算することです。そのため、検索機能を単純に無視すると、メトリックが取得されます。メトリクスは XML ファイル (ソース ファイルごとに 1 つの「レコード」) に生成されるため、メトリクスに対してさらに必要な処理を行うことができます。リンクされた Web ページのメトリックの説明を参照してください。

JSP lexer はありますが、まだ検索エンジンでテストされていません。数十のレクサーを作成したので、これは非常に簡単に実行できるはずです (喜んで実行します)。それはあなたが望む答えを直接生み出すでしょう。

その道をたどりたくない場合は、<% と %> の間のコードを抽出し、元の JSP ファイルと並行してファイルにダンプし、そのコードを検索エンジンに渡すという単純なアイデアに従うことができます。検索エンジン用の（本番）Java語彙素抽出器を介して、その方法でメトリックを取得します。lexer は、不正な形式のファイルに対して非常に堅牢であるため、抽出された Java フラグメントが集合的に完全に合法的ではない可能性があるという事実は、少し気にすることはありません。

于 2011-10-12T03:38:57.570 に答える