10

コードリファクタリングを測定するための客観的な指標はありますか？

リファクタリングの前後にfindbugs、CRAP、またはcheckstyleを実行することは、コードが単に変更されただけでなく、実際に改善されたかどうかを確認するための便利な方法でしょうか？

コードレビュープロセスの改善に役立つ、決定およびテストできるメトリックを探しています。

4

9 に答える 9

5

失敗した単体テストの数はゼロ以下でなければなりません:)

于 2009-04-28T14:27:18.633 に答える
5

特定の目標に応じて、循環的複雑度などの指標が成功の指標となります。知性や常識を捉えることができないため、最終的にはすべての指標が覆される可能性があります。

ただし、健全なコード レビュー プロセスは驚くべき結果をもたらす可能性があります。

于 2009-04-28T14:31:46.860 に答える
4

リファクタリングの前後にfindbugs、CRAP、またはcheckstyleを実行することは、コードが単に変更されただけでなく、実際に改善されたかどうかを確認するための便利な方法でしょうか？

実際、「コードメトリックの魅力は何ですか？」という質問で詳しく説明しました。、メトリック（findbugs、CRAPなど）のトレンドは、メトリックの真の付加価値です。
これ（メトリックの進化）により、コードに対して実際に行う必要のある主要な修正アクションに優先順位を付けることができます（すべてのメトリックを盲目的に尊重しようとするのではなく）

Sonarのようなツールは、このドメイン（メトリックの監視）で非常に便利です。

Salはコメントに追加します：

本当の問題は、単に変更を追加するのではなく、どのコードの変更が付加価値をもたらすかを確認することです。

そのためには、テスト（単体テストだけでなく、より大きな「機能テスト」）のみが有効な答えを提供するため、テストカバレッジは非常に重要です。
しかし、とにかく明確な目的なしにリファクタリングを行うべきではありません。「よりエレガント」または「保守が容易」であるという理由だけでそれを行うこと自体は、コードを変更するのに十分な理由ではない可能性があります。
プロセスで修正されるいくつかのバグや、「リファクタリングされた」コードの結果としてはるかに高速に実装されるいくつかの新しい機能など、他の対策が必要です。
つまり、リファクタリングの付加価値は、メトリックだけで測定されるのではなく、目標やマイルストーンに対して評価される必要があります。

于 2009-04-28T14:50:36.317 に答える
2

コードサイズ。機能を壊さずにそれを減らすことは、私の本の改善です（もちろん、コメントを削除して識別子を短くすることはカウントされません）

于 2009-04-28T14:43:50.763 に答える
1

リファクタリングの成功を測定するためのメトリックには近づきません（#unitテストの失敗== 0を除く）。代わりに、コードレビューを使用します。

リファクタリングの明確なターゲットを見つけるのにそれほど手間はかかりません。「まったく同じコードを見たことがありませんか？」残りの部分については、すべきでないことに関する特定のガイドラインを作成し、開発者がそれらについて知っていることを確認する必要があります。そうすれば、他の開発者が基準に従わなかった場所を見つけることができます。

より高いレベルのリファクタリングの場合、より上級の開発者やアーキテクトは、コードベースがどこに移動するかという観点からコードを調べる必要があります。たとえば、今日のコードが静的構造を持つことは完全に合理的かもしれません。しかし、より動的な構造が必要になることを知っているか疑っている場合は、newを使用する代わりにファクトリメソッドを使用するか、次のリリースで別の実装があることを知っているため、クラスからインターフェイスを抽出することを提案する場合があります。

これらのことのどれもメトリックから利益を得ることができません。

于 2009-04-28T14:52:30.243 に答える
1

何をするにしても、この指標がプログラマーのパフォーマンスの評価、昇進の決定などに使用されないようにしてください。

于 2009-04-28T14:45:58.213 に答える
1

はい、リファクタリングによってコードの品質が向上するかどうかは、コード品質のいくつかの測定値からわかります。

  • 複製。一般に、重複が少ないほど良いです。ただし、私が使用した重複ファインダーは、単に構造的に類似しているが、意味的には互いに何の関係もない重複ブロックを特定することがあるため、重複排除すべきではありません。これらの誤検知を抑制または無視する準備をしてください。

  • コード カバレッジ。これは一般的に私のお気に入りの指標ですが、リファクタリングに間接的に関連しているだけです。より多くのテストを作成することで、低いカバレッジを上げることができますし、そうすべきですが、それはリファクタリングではありません。ただし、リファクタリング中は (コードに対する他の変更と同様に) コード カバレッジを監視して、ダウンしないことを確認する必要があります。リファクタリングは、重複したコードのテストされていないコピーを削除することで、コード カバレッジを改善できます。

  • コードの行数、クラスごと、メソッドごと、関数ごとなどのサイズメトリクス。リファクタリングにより、明確さを維持しながらコードの行数が減れば、品質が向上します。異常に長いクラス、メソッドなどは、リファクタリングの対象になる可能性があります。クラスやメソッドなどの作業を完了するために通常よりも長くする必要がある場合を判断する際に、判断を下す準備をしてください。

  • 循環的複雑度などの複雑度メトリック。リファクタリングは複雑さを減らすように努めるべきであり、よく考えられた理由なしに複雑さを増やさないようにするべきです。複雑性の高いメソッド/関数は、リファクタリングの対象として適しています。

  • Robert C. Martin のメトリクス: 抽象性、不安定性、および抽象性 - 不安定性のメイン シーケンスからの距離。彼はC++ レポートの安定性に関する記事と彼の著書Agile Software Development, Principles, Patterns, and Practices でそれらについて説明しました。JDependは、それらを測定するツールの 1 つです。パッケージ設計を改善するリファクタリングでは、D を最小限に抑える必要があります。

私はこれらすべてを使用しており、ソフトウェア プロジェクトの品質を監視するために使用し続けています。

于 2016-03-20T00:16:09.227 に答える
0

リファクタリングから望む2つの結果があります。チームを組んで持続可能なペースを維持し、生産の欠陥をゼロにしたい。

リファクタリングは、テスト駆動開発（TDD）中にコードと単体テストビルドで行われます。リファクタリングは小さく、ストーリーカードを完成させるために必要なコードで完了することができます。または、リファクタリングが大きく、技術的負債に対処するために技術的ストーリーカードが必要になる場合があります。ストーリーカードは、製品バックログに配置して、ビジネスパートナに優先順位を付けることができます。

さらに、TDDと同じように単体テストを作成すると、コードが開発されるときにテストのリファクタリングが継続されます。

アジャイルでは、SCRUMで定義されている管理手法によってコラボレーションが提供され、ビジネスパートナーのニーズを確実に理解し、開発したコードがビジネスニーズを満たしていることを忘れないでください。ただし、適切なエンジニアリング手法（エクストリームプログラミングで定義されている）がないと、プロジェクトは持続可能なペースを失うことになります。エンジニアリング手法を採用しなかった多くのアジャイルプロジェクトは、救助を必要としていました。一方、規律があり、管理とエンジニアリングのアジャイルプラクティスの両方を採用したチームは、無期限に配信を維持することができました。

そのため、コードが多くの欠陥を伴ってリリースされたり、チームが速度を失ったり、リファクタリングを行ったり、その他のエンジニアリング手法（TDD、ペアリング、自動テスト、単純な進化的設計など）が適切に採用されていない場合。

于 2009-05-02T00:26:31.630 に答える
0

私は匂いの観点から質問を見ます。匂いは品質問題の指標として扱われる可能性があるため、特定された匂いインスタンスの量からソフトウェア コードの品質が明らかになる可能性があります。

においは、その粒度と潜在的な影響に基づいて分類できます。たとえば、実装の匂い、設計の匂い、建築の匂いなどがあります。リファクタリングの演習からの利益を示すには、前後のすべての粒度レベルで匂いを特定する必要があります。実際、リファクタリングは特定された匂いによって導かれる可能性があります。

例:

  • 実装の臭い:長いメソッド、複雑な条件、デフォルト ケースの欠落、複雑なメソッド、長いステートメント、マジック ナンバー。
  • デザインの匂い:多面的な抽象化、抽象化の欠落、不十分なカプセル化、悪用されていないカプセル化、ハブのようなモジュール化、循環依存のモジュール化、広い階層、壊れた階層。デザインのにおいについて詳しくは、この本をご覧ください。
  • アーキテクチャの匂い:レイヤーの欠落、パッケージの循環依存、違反したレイヤー、あいまいなインターフェイス、散在する寄生機能。建築のにおいについて詳しくは、こちらをご覧ください。
于 2016-03-20T20:30:51.280 に答える