Vérifier la qualité du code produit

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.
Mots clés:

Réponses

  • CéroceCéroce Membre, Modérateur
    janvier 2013 modifié #2
    L'article d'Octo est intéressant; il parle uniquement de la manière d'obtenir des métriques sur le code. Parmi celles évoquées, seules deux témoignent de la qualité du code:

    - 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é.




    'Karoxys' a écrit:


    Mais comment faite vous pour vérifier l'exactitude du code produit ?


    ç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é.
  • AliGatorAliGator Membre, Modérateur
    J'ai pas eu le temps de lire l'article, je me le garde en lecture pour plus tard.

    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
  • DrakenDraken Membre
    janvier 2013 modifié #4
    J'ai une petite soe“ur brise-fer. Il suffit de lui donner une application pour avoir un plantage. Elle est très utile comme assistante de développement. Mon neveu a aussi des dispositions dans ce domaine !
  • CéroceCéroce Membre, Modérateur
    Il te faut un petit singe.
  • FKDEVFKDEV Membre
    janvier 2013 modifié #6
    L'article est assez difficile à  lire car il mélange des lignes de scripts et du contenu, c'est dommage car le contenu est interessant.



    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.
  • CéroceCéroce Membre, Modérateur
    'FKDEV' a écrit:


    Franchement une courbe qui montre le nombre de lignes de codes générées au cours du temps, ça sert à  quoi ?


    À 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.
  • J'ai eu la chance de travailler avec les pionniers de ce genre de métriques en France. Ils avaient fait l'outil Logiscope assez connu à  l'époque (années 80-90).

    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.




    'Céroce' a écrit:


    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.


    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.
  • [font=helvetica, arial, sans-serif]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
    [/font]

    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.
  • CéroceCéroce Membre, Modérateur
    En fait, il n'y a pas de contradictions dans nos propos; je crois que nous sommes tous d'accord: le bon chef de projet est celui assez humble pour s'appuyer sur les connaissances de ceux qui savent.



    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).
Connectez-vous ou Inscrivez-vous pour répondre.