Vérifier la qualité du code produit
Karoxys
Membre
Bonjour,
Je voulais savoir comment vous effectuez la vérification de votre code.
On sait tous qu'il y a plusieurs manières de faire, on peut vérifier les parties métiers un peu complexe avec les tests unitaires (un post a été créé récemment sur le sujet).
Mais comment faite vous pour vérifier l'exactitude du code produit ?
Je viens de trouver une étude faite avec Jenkins, je voulais avoir votre avis.
Site : http://blog.octo.com/en/jenkins-quality-dashboard-ios-development/
Bonne fin de soirée à tous !!
K.
Je voulais savoir comment vous effectuez la vérification de votre code.
On sait tous qu'il y a plusieurs manières de faire, on peut vérifier les parties métiers un peu complexe avec les tests unitaires (un post a été créé récemment sur le sujet).
Mais comment faite vous pour vérifier l'exactitude du code produit ?
Je viens de trouver une étude faite avec Jenkins, je voulais avoir votre avis.
Site : http://blog.octo.com/en/jenkins-quality-dashboard-ios-development/
Bonne fin de soirée à tous !!
K.
Mots clés:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
- la couverture de code par les tests
- la duplication du code
Les autres métriques (par ex. nombre de classes) sont des mesures de la complexité, pas de la qualité.
ça, c'est une autre question, mais la réponse est simple: en effectuant des tests, qu'ils soient automatisés ou manuels.
Note que du code peut être exact, dans le sens où il répond à la spec, mais de mauvaise qualité.
Par contre nous ce qu'on fait c'est :
- Intégration Continue avec Jenkins
- Métriques avec Solar
- Idéalement, du TDD (même si en pratique c'est pas toujours respecté à fond, mais bon) pour une couverture de tests max
Les métriques Solar permettent entre autres d'avoir des idées quant à la qualité de code
Sur le fond, j'ai des doutes sur l'utilité des metrics sur un projet de 6 semaines.
C'est pas parce qu'on peut le faire qu'il faut le faire.
C'est pas parce que le Jenkins sera tout vert que le client ne sera pas tout rouge.
2H pour configurer un outil pour s'apercevoir que le nouveau n'a pas intégré les régles de nommages de l'objective-C, c'est 1H50 de perdue, parce que dix minutes à parcourir un fichier au hasard et on voit tout de suite 80% des problèmes de ce type. Et au passage on voit la pertinence des commentaires, la qualité de l'orthographe, de l'expression écrite ou de l'anglais.
Après, c'est vrai que l'analyse statique pour anticiper des bugs causés par des erreurs de codage type = au lieu de == dans un if ou test sur une variable non affectée, ça peut faire gagner du temps à condition qu'il n'y ait pas trop de faux négatifs (ou faux positifs ?).
Je suis mefiant quoi. Celui qui sort des courbes superbes, c'est qu'il a été trop loin, qu'il s'est fait plaisir.
Franchement une courbe qui montre le nombre de lignes de codes générées au cours du temps, ça sert à quoi ?
Je prefere des metrics un peu subjective comme la courbe du reste à faire estimé ou totalement subjective comme la confiance dans la qualité du code.
Meme la couverture de code par les tests, c'est rarement super pertinent.
C'est pas ininteressant, mais il ya toujours plus profitable à faire, comme s'assurer que tout le monde a bien compris ce qu'il avait faire et pour quand, que le client sera pret a tester dans les temps, qu'il travaille sur les specs qu'il doit fournir, que l'autre equipe sera prete a integrer, que tel fournisseur n'est pas dans les choux.
À rien. Une petite anecdote de ma vie professionnelle antérieure: nous travaillions sur un projet depuis plusieurs mois, quand le client de notre client a retiré 20% des exigences de sa spec. Nous avons donc retiré le code correspondant à ces exigences, soit environ 20% du code. Panique chez notre client: "c'est impossible, votre projet a régressé de 20% !".
Voilà ce qui arrive quand la gestion de projet est laissé à des gens qui ne maà®trisent pas les projets informatiques: ils adoptent des métriques non significatives, ou du moins les interprètent mal. Le nombre de ligne est une mesure de la complexité, pas de l'avancement.
Je reprends leurs recommandations à mon compte : ces métriques n'ont aucune valeur par elles-mêmes et dans l'absolu.
Ce qui prend du sens c'est la conjonction de ces métriques entre elles et avec d'autres informations. Ce qui peut avoir du sens aussi c'est leur évolution dans le temps.
Par exemple, si on constate qu'une partie de l'application de fonctionne pas très bien (nombre de défauts anormalement élevé du point de vu de l'utilisateur) on pourra utiliser les métriques comme source d'informations (parmi d'autres) pour comprendre ce qui caractérise cette partie et identifier des pistes d'amélioration.
Je vais réagir de façon virulente à cette affirmation. D'abord ce n'est pas spécifique aux projets informatiques ; chaque métier a ses spécificités et la question de la pertinence des indicateurs se pose toujours. J'ai conduit de nombreux projets de tailles variées et dans des domaines très différents (informatique, construction navale, électronique, organisation, ...). Pour chaque domaine et même pour chaque projet il faut identifier les bons indicateurs.
Deuxième point, le management de projet est un métier à part entière. Pour le chef de projet, le fait de connaà®tre ou pas le domaine n'a qu'une importance secondaire (mon projet le plus gros et le plus abouti était dans un domaine que je ne connais absolument pas). J'aurais même tendance à dire que c'est mieux lorsque le chef de projet ne connaà®t pas le domaine ; il est obligé de s'appuyer sur ceux qui savent, ce qui favorise la communication au sein de l'équipe ce qui est reconnu comme un élément clé de réussite des projets.
Un dernier point concernant les métriques. La communication de métriques doit toujours être accompagnée d'une analyse" ; c'est une des bonnes pratiques du modèle CMMI, largement reconnu comme référentiel de bonnes pratiques. Juste pour appuyer le fait que la valeur d'une métrique n'a pas de sens en elle-même. Ce qui donne du sens c'est l'analyse que l'on en fait.
Une personne qui est capable d'organiser, de comprendre et de communiquer peut sans doute gérer n'importe quel type de projet, c'est vrai.
Cependant il y a une taille critique en dessous de laquelle cela risque de ne pas marcher.
Pour un projet iOS de 6 semaines, par exemple, si on appelle "chef de projet", la personne qui est en contact avec le client et qui s'assure que l'équipe va réussir à livrer un soft dans les temps avec une qualité raisonnable, alors je pense quand même qu'il vaut mieux que le CdP touche un peu sa bille en projets de développement et sache en plus communiquer un minimum. Après s'il n'a pas d'indicateur sur la qualité de code, je ne lui en voudrai pas.
Parce que si tu mets 3 semaines pour te rendre compte que les devs vont pas y arriver ou que le client est incapable de spécifier, t'as beau avoir tous les indicateurs que tu veux, tu es mal...
Je suis d'accord que les indicateurs s'apprécient avec l'évolution dans le temps. Peut-être qu'ils sont plus faciles à mettre en place dans les environnements où tu as des développements répétitif et où tu peux objectivement comparer les indicateurs d'un projet à un autre ou d'une phase de projet à un autre.
Je suis également d'accord avec Céroce sur le fait que tu trouves plein de clients ou de managers qui choisissent des indicateurs sans savoir de quoi il retourne. Et je pense que c'est un mal particulier au dév informatique où les technos changent souvent. Et, où ces 20 dernières années, l'informatique est rentré dans des tas de métiers où elle n'existait pas auparavant. Tu te retrouves face à des manages qui ne comprennent pas vraiment ce qui se passe mais qui veulent contrôler quand même.
J'ai sans doute généralisé, mais ça tient au fait que c'était un énorme projet, où il n'y avait pas un seul chef de projet, mais un grand chef et des plus petits, et surtout, que les discussions furent longues pour leur faire admettre qu'ils avaient commis une erreur dans le choix des métriques, alors qu'il aurait suffit qu'ils discutent 5 mn avec un programmeur pour qu'ils comprennent qu'il est tout à fait habituel de remanier le code.
(L'aéronautique est encore un secteur où l'on croit aveuglément que le développement avec le cycle en V fonctionne).