Au niveau du langage malheureusement non. Au niveau des outils de base malheureusement non.
Tu peux développer ? Notamment au niveau de ce que tu appelles "outils de base" ?
Pour un langage compilé qui a une longue histoire, je trouve que Java évolue plutôt vite et dans le bon sens.
Sonar c'est vraiment le dernier truc dont tu as besoin pour "gérer la qualité".
Ce n'est pas parce qu'on peut en faire mauvais usage que c'est un mauvais outil. Pour le pratiquer depuis très longtemps, ça permet de se poser une fois de temps en temps et de regarder ce qu'il se passe quand on n'est pas dans le code au quotidien.
C'est aussi très pratique quand on reprend des projets externes.
Rien que le fait de packager plusieurs outils et de normaliser leur utilisation est un vrai truc apporté par Sonar.
Si tu as des règles à faire respecter et qu'elles ne le sont pas ca doit bloquer ton build pas pondre des graphes.
C'est une bonne idée, ça. Tant qu'à faire, le mieux est de bloquer le build sur chaque problème, comme ça, chaque build devient une aventure.
Mettre toutes les vérifications à faire dans le chemin du build n'est pas forcément toujours jouable sur les gros projets : ça peut fortement allonger le temps de build (et même si c'est déporté sur intégration continue, ça peut vite devenir casse pied). Se prendre un moment une fois par semaine pour relire le rapport Sonar qui est toujours dispo (je parle principalement de la partie violations), c'est plutôt très pratique.
Et pour l'avoir pratiqué, ça suffit pour qu'une équipe responsable intègre automatiquement les règles dans sa manière de coder (enfin, celles qu'elles n'avaient pas déjà intégrées parce qu'il y a quand même beaucoup de bon sens) au fur et à mesure.
A quoi servent des rapports sur la complexité cyclomatique, le pourcentage de commentaire ou la duplication de code ?
Duplication de code, ça sert de temps en temps, même si je suis d'accord que quand on code intelligemment, c'est peu souvent utile.
Pour la complexité, je fais principalement au feeling. Les commentaires idem.
Après, pour avoir subi un audit CAST (produit proprio équivalent) obligatoire sur un projet qu'on a livré à un client, ça nous a bien aidé à ce que les indicateurs CAST ne soient pas dans le rouge.
[^] # Re: Usine
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 4.
Tu peux développer ? Notamment au niveau de ce que tu appelles "outils de base" ?
Pour un langage compilé qui a une longue histoire, je trouve que Java évolue plutôt vite et dans le bon sens.
Ce n'est pas parce qu'on peut en faire mauvais usage que c'est un mauvais outil. Pour le pratiquer depuis très longtemps, ça permet de se poser une fois de temps en temps et de regarder ce qu'il se passe quand on n'est pas dans le code au quotidien.
C'est aussi très pratique quand on reprend des projets externes.
Rien que le fait de packager plusieurs outils et de normaliser leur utilisation est un vrai truc apporté par Sonar.
C'est une bonne idée, ça. Tant qu'à faire, le mieux est de bloquer le build sur chaque problème, comme ça, chaque build devient une aventure.
Mettre toutes les vérifications à faire dans le chemin du build n'est pas forcément toujours jouable sur les gros projets : ça peut fortement allonger le temps de build (et même si c'est déporté sur intégration continue, ça peut vite devenir casse pied). Se prendre un moment une fois par semaine pour relire le rapport Sonar qui est toujours dispo (je parle principalement de la partie violations), c'est plutôt très pratique.
Et pour l'avoir pratiqué, ça suffit pour qu'une équipe responsable intègre automatiquement les règles dans sa manière de coder (enfin, celles qu'elles n'avaient pas déjà intégrées parce qu'il y a quand même beaucoup de bon sens) au fur et à mesure.
Duplication de code, ça sert de temps en temps, même si je suis d'accord que quand on code intelligemment, c'est peu souvent utile.
Pour la complexité, je fais principalement au feeling. Les commentaires idem.
Après, pour avoir subi un audit CAST (produit proprio équivalent) obligatoire sur un projet qu'on a livré à un client, ça nous a bien aidé à ce que les indicateurs CAST ne soient pas dans le rouge.