Webアプリケーションの複雑さ

私は現在、Webアプリケーションの保守性に関する修士論文を書いています。Colemanらによる「Maintainability Index」のようないくつかの方法を見つけました。またはMuthannaらによる「ソフトウェア保守性インデックス」。どちらの場合も、循環的複雑度を計算する必要があります。だから私の質問は：

Webアプリケーションの循環的複雑度を測定することは可能ですか？

私の意見では、Webアプリケーションには3つの部分があります。

1. サーバーコード（PHP、C＃、Python、Perlなど）
2. クライアントコード（JavaScript）
3. HTML（演算子としてのリンクとフォーム、オペランドとしてのGETパラメータとフォームフィールド！？）

どう思いますか？Webアプリケーションの複雑さについて別の見方がありますか？私は何か見落としてますか？

循環的複雑度は、コード複雑度の複数の測定値の1つです。たとえば、Visual Studioでは、保守性インデックスは以下に依存します。

• 循環的複雑度、
• 継承の深さ、
• クラス結合、
• ILコードの行（ILコードは中間言語にコンパイルされ、JITコンパイルされるソースコードです）。

これらの測定値はすべて、他の複雑さの測定値と同様に何らかの方法で機能しますが、ソースコードに複雑さの問題があることを示す絶対的な指標にはなりません。LOCとしての一部の測定は、完全に無意味で誤解を招くことが知られています。循環的複雑度のような他のものは少し良いですが、それでも問題があります。

これは、次の事実によるものです。

• コンピュータプログラムにとって、ソースコードが開発者によってどの程度複雑に認識されるかを知るのは複雑すぎます。

  たとえば、LINQを介してコードを手続き型スタイルから関数型スタイルにリファクタリングすると、非常に明示的な単一のチェーン式に非常に読みにくいソースコードのブロックが変換され、保守性インデックスが大幅に低下することがよくありました。

  別の例は、メトリックのプログラミングパターンの反映です。多くの場合、コードにプログラミングパターンを導入することで、開発者の複雑さを軽減します（この開発者がそれらのパターンに精通している場合）、保守性インデックスは低下します。

• ソースコードにはさまざまな形式があります。

  ご存じのように、HTML / CSS、JavaScriptなどの存在と、コメントに記載されているように、データベースアクセスの存在が原因で、循環的複雑度、継承の深さ、クラス結合の測定は非常に制限されています。

  この制限はWebアプリだけに存在するわけではありません。たとえば、デスクトップアプリケーションでは、UIレイアウト（WindowsアプリケーションのXAMLコード）の複雑さはどうですか？生成されたコードはどうですか？またはデータベースアクセス？