Données pour la mesure de refactoring réussie [fermé]

Question

Y at-il des mesures objectives pour mesurer refactoring de code?

Ne serait-findbugs en cours d'exécution, ou CRAP checkstyle avant et après un refactoring être un moyen utile de vérifier si le code a été effectivement amélioré plutôt que changé?

Je suis à la recherche des tendances que nous pouvons saisir qui peuvent nous aider à améliorer le processus de révision du code sans perdre de temps sur du code qui est changé pour de simples préférences personnelles.

Answer 1

  

Ne serait en cours d'exécution findbugs, MERDE ou checkstyle avant et après un refactoring être un moyen utile de vérifier si le code a été effectivement amélioré plutôt que changé?

En fait, comme je l'ai indiqué dans la question "Qu'est-ce que est la fascination pour les métriques de code? ", tendance de toutes les mesures (findbugs, CRAP, quelle que soit) est la vraie valeur ajoutée de mesures.
Il (l'évolution des paramètres) vous permet de Prioriser l'action principale de fixation vous avez vraiment besoin de faire à votre code (par opposition à essayer aveuglément à respecter toutes les métriques là-bas)

Un outil tel que Sonar peut, dans ce domaine (la surveillance de paramètres ) peut être très utile.

---

Sal ajoute dans les commentaires:

  

La vraie question est de vérifier les changements de code ajoutent de la valeur plutôt que d'ajouter le changement

Pour cela, la couverture de test est très important, car seuls les tests (tests unitaires, mais aussi plus grands « tests fonctionnels ») vous donnera une réponse valable.
Mais refactoring ne doit pas se faire sans un objectif clair de toute façon. Pour le faire seulement parce qu'il serait « plus élégant » ou encore « plus facile à entretenir » peut être pas en soi une bonne raison assez pour changer le code.
Il devrait y avoir d'autres mesures comme quelques bugs qui seront résolus dans le processus, ou de nouvelles fonctions qui seront mises en œuvre beaucoup plus rapidement en raison du code « refondus ».
En bref, la valeur ajoutée d'un refactoring est non seulement mesurée à l'aide des mesures, mais devrait également être évaluée par rapport aux objectifs et / ou étapes.

Answer 2

Nombre de unittests échoué doit être inférieure ou égale à zéro:)

Answer 3

En fonction de vos objectifs spécifiques, des mesures comme complexité cyclomatique peut fournir un indicateur de succès. En fin de chaque métrique peut être subverti, car ils ne peuvent pas capturer l'intelligence et / ou le bon sens.

Un processus d'examen de code sain peut faire des merveilles bien.

Answer 4

La taille du code. Tout ce qui il réduit sans casser la fonctionnalité est une amélioration dans mon livre (la suppression des commentaires et des identificateurs shortening ne comptent pas, bien sûr)

Answer 5

Peu importe ce que vous ne faites que vous cette chose métrique est pas utilisé pour évaluer la performance de programmeur, de décider la promotion ou quelque chose comme ça.

Answer 6

Je resterais loin de mesures pour mesurer le succès refactorisation (en dehors des échecs de test #unit == 0). Au lieu de cela, je partirais avec des revues de code.

Il ne prend pas beaucoup de travail pour trouver des cibles évidentes pour refactoring: «N'ai-je vu ce même code exact avant? » Pour le reste, vous devez créer certaines lignes directrices sur quoi ne pas faire, et assurez-vous que vos développeurs connaissent. Ensuite, ils seront en mesure de trouver des endroits où l'autre développeur n'a pas respecté les normes.

Pour refactoring plus haut niveau, les développeurs plus expérimentés et les architectes devront regarder le code en termes de l'endroit où ils voient le déplacement de la base de code. Par exemple, il peut être tout à fait raisonnable pour le code d'avoir une structure statique aujourd'hui; mais s'ils savent ou soupçonnent qu'une structure plus dynamique sera nécessaire, ils peuvent suggérer d'utiliser une méthode de fabrication au lieu d'utiliser nouveau , ou extraire une interface d'une classe parce qu'ils savent qu'il y aura une autre mise en œuvre la prochaine version.

Aucune de ces choses bénéficierait de mesures.

Answer 7

Oui, plusieurs mesures de la qualité du code peut vous dire si un refactoring améliore la qualité de votre code.

• Duplication. En général, moins la duplication est mieux. Cependant, trouveurs de duplication que j'ai utilisé parfois d'identifier des blocs dupliqués qui sont simplement structurellement similaires mais rien à voir avec l'autre sémantiquement et ne devraient donc pas être dédupliqués. Préparez-vous à supprimer ou ignorer ces faux positifs.

• couverture de code. Ceci est de loin ma préférée métrique en général, mais il est seulement liée indirectement à refactoring. Vous pouvez et devez augmenter la faible couverture en écrivant plus de tests, mais ce n'est pas refactoring. Cependant, vous devez surveiller la couverture du code tout en refactorisation (comme avec tout autre modification du code) pour être sûr qu'il ne va pas vers le bas. Refactoring peut améliorer la couverture de code en supprimant les copies non vérifiées de code dupliqués.

• paramètres Taille comme les lignes de code, total et par classe, méthode, fonction, etc. un poste Jeff Atwood énumère quelques autres. Si un refactoring réduit les lignes de code, tout en maintenant la clarté, la qualité a augmenté. cours anormalement longs, des méthodes, etc. sont susceptibles d'être de bonnes cibles pour refactoring. Soyez prêt à faire preuve de jugement pour décider quand une classe, méthode, etc. n'a pas vraiment besoin d'être plus que d'habitude pour se faire son travail.

• La complexité des paramètres tels que la complexité cyclomatique. Refactoring devrait essayer de réduire la complexité et ne pas augmenter sans une raison bien pensé. Méthodes / fonctions avec une grande complexité sont bonnes cibles de refactoring.

• Robert C. Martin son article sur la stabilité dans le rapport C ++ et son livre Agile Software Development, principes, modèles et pratiques . JDepend est un outil qui mesure les. Refactoring qui améliore la conception de l'emballage devrait réduire au minimum D.

Je l'ai utilisé et continuer à utiliser tous ces éléments pour contrôler la qualité de mes projets logiciels.

Answer 8

Il y a deux résultats que vous voulez de refactoring. Vous voulez faire équipe pour maintenir le rythme durable et que vous voulez le zéro défaut dans la production.

Refonte a lieu sur le code et la construction de test unitaire au cours du développement piloté par les tests (TDD). Refactoring peut être petit et complété sur un morceau de code nécessaire pour terminer une carte d'histoire. Ou, refactoring peut être grande et nécessaire une carte histoire technique pour traiter la dette technique. La carte de l'histoire peut être placé sur le carnet de produit et hiérarchisé avec le partenaire commercial.

En outre, comme vous écrivez des tests unitaires comme vous le faites TDD, vous continuerez à factoriser le test que le code est développé.

Rappelez-vous, agile, les pratiques de gestion telles que définies dans SCRUM vous fournira la collaboration et assurez-vous de comprendre les besoins du partenaire commercial et le code que vous avez développé répond aux besoins des entreprises. Cependant, sans pratiques d'ingénierie appropriées (telles que définies par l'Extreme Programming) votre projet sera perte rythme durable. Beaucoup de projets agiles qui n'utilisent des pratiques d'ingénierie avaient besoin de secours. D'autre part, une équipe qui était disciplinée et employés la pratique agile à la fois la gestion et de l'ingénierie ont été en mesure de soutenir la livraison indéfiniment.

Donc, si votre code est libéré avec de nombreux défauts ou votre équipe desserre vitesse, refactoring, et d'autres pratiques d'ingénierie (TDD, éplucher, les tests automatisés, simple conception évolutive, etc.), ne sont pas correctement utilisés.

Answer 9

Je vois la question du point de vue de l'odorat. Smells pourrait être traité comme indicateurs de problèmes de qualité et, par conséquent, le volume des cas d'odeur identifiés pourrait révéler la qualité du code logiciel.

Smells peuvent être classés en fonction de leur granularité et leur impact potentiel. Par exemple, il pourrait y avoir des odeurs de mise en œuvre, les odeurs, la conception et les odeurs architecturales. Vous devez identifier les odeurs à tous les niveaux de granularité avant et après pour montrer le gain d'un exercice de refactoring. En fait, refactoring pourrait se laisser guider par les odeurs identifiées.

Exemples:

• sent la mise en œuvre:. Méthode longue, complexe conditionnel, manquant cas par défaut, méthode complexe, longue déclaration, et nombres magiques
• sent design: abstraction à plusieurs facettes, abstraction manquant, encapsulation Déficient, encapsulation inexploitée, modularisation Hub-like, modularisation dépendant cycliquement, large hiérarchie et brisé la hiérarchie. Pour plus d'informations sur la conception des odeurs se trouve dans cette livre .
• Architecture sent: Incomplète, la dépendance Cyclique en paquets, couche Violé, Interfaces ambigües et Dispersés Parasite fonctionnalité. Plus d'informations sur l'architecture odeurs .