Commentaires sur : Mesurer la qualité d’un projet pour le désendetter

Par : Maîtriser en continu votre dette technique avec Sonar « Alpes JUG

Maîtriser en continu votre dette technique avec Sonar « Alpes JUG — Wed, 08 Dec 2010 09:25:56 +0000

[...] Mesurer la qualité d’un projet pour le désendetter [...]

Par : Liens du mois – Octobre 2009 | Forum Logiciel

Liens du mois – Octobre 2009 | Forum Logiciel — Fri, 23 Oct 2009 08:52:09 +0000

[...] Mesurer la qualité d’un projet pour le désendetter [...]

Par : Nicolas

Nicolas — Tue, 14 Apr 2009 13:20:35 +0000

IDEA IntelliJ a des outils avancés qui informent le développeur en temps réel sur ce qu’il vient de taper : code inutile, boucle où l’on ne passe jamais, code mort, complexité trop élevée.

Je trouve personnellement plus simple d’offrir cela au moment de l’écriture du code plutôt qu’à posteriori.
Je comprends par contre le besoin d’avoir un outil afin d’analyser des projets existants.

Par : Gilles S

Gilles S — Fri, 03 Apr 2009 10:11:37 +0000

Merci pour cet aperçu d’XDepend. Je suis bien d’accord avec Jean-Baptiste sur le fait de faire du refactoring en meme temps que l’implementation de nouvelles fonctionnalités (c’est souvent ce qui est recommandé).
Le probleme est toujours le meme, le « vrai » refactoring requiert des très bonnes compétences de développeur.
Ce qui facilite déja le refactoring c’est d’avoir déja un découpage en couche et l’utilisation des grands patterns classiques (MVC, Service, ORM) et l’utilisation de Spring bien sur (l’IDE de Spring crée d’ailleurs de très jolis diagrammes de dépendance)
Par contre il faut surtout mettre en place des outils dans les IDE qui permettent d’etre prévenu en temps réel si on ne suit pas les best practices de base (javadoc, méthode trop longue, …)
Sinon on a utilisé Sonar qui permet assez rapidement d’avoir un aperçu de la qualité d’un projet en pouvant par une interface web aller voir les sources.

Par : Jean-Baptiste DUSSEAUT

Jean-Baptiste DUSSEAUT — Thu, 02 Apr 2009 16:14:50 +0000

La dette technique n’est pas une fatalité, et à mon sens le refactoring n’est pas à utiliser dans des sessions dédiées juste à ça.
La définition du refactoring est de changer le code existant à l’aide d’un ensemble de refactorings sans changer son comportement extérieur, afin qu’il puisse accueillir les modifications qu’on veut lui apporter.

Donc quand doit-on faire du refactoring? Dès que que nous voulons ajouter de nouvelles fontionnalités. Et quand ajoutons-nous de nouvelles fonctionnalités? Tout le temps.

Ici du coup je trouve peut être un peu dangereux de parler de session de refactoring, car finalement c’est comme ça que cette pratique est stigmatisée parfois comme étant chère et n’apportont aucune valeur fonctionnelle. Dans le cas très précis ou l’on veut absorber une dette technique, quelque soit les raisons de sa présence, peut être ferions-nous mieux de trouver un autre mot que refactoring.

Par : Romain Verdier

Romain Verdier — Thu, 02 Apr 2009 09:07:11 +0000

Effectivement, l’outil est impressionnant. Il s’est imposé en .NET depuis pas mal de temps, et son auteur, Patrick Smacchia (un français !), poste régulièrement sur CodeBetter des articles à son sujet : bonnes pratiques, techniques d’analyse, de restructuration, de refactoring ; tips, nouvelles features, etc. Il prend parfois le temps de faire des « project reviews » intéressantes à l’aide de l’outil.

Comme une grande partie des données collectées par ce dernier provient du bytecode, il est possible d’analyser des projets qui ne sont pas forcément open source.

http://codebetter.com/blogs/patricksmacchia/default.aspx