Rares sont ceux qui nient l’importance de l’écriture d’un code de qualité. Un code de grande qualité contient moins de bugs, est plus facile à comprendre et plus facile à maintenir. Toutefois, les définitions précises de la qualité d’un code peuvent être plus subjectives, variant entre organisations, équipes, et même entre individus d’une même équipe.
C’est ici que les normes de codage entrent en jeu. Les normes de codage sont des règles, parfois relativement arbitraires, qui définissent les styles et les conventions de codage qui sont considérées comme acceptables au sein d’une équipe ou d’une organisation. Dans beaucoup de cas, se mettre d’accord sur un ensemble de normes et les appliquer est plus important que les normes elles-mêmes. En effet, un des aspects les plus importants d'un code de qualité est qu’il soit facile à lire et à comprendre. Si tous les développeurs d’une équipe appliquent les mêmes normes et les mêmes pratiques, le code sera ainsi plus lisible, au moins pour les membres de cette équipe. Et, si les normes sont communément utilisées dans l’industrie, le code sera d’autant plus lisible pour les nouveaux développeurs arrivant dans l’équipe.
Les normes de codage incluent à la fois des aspects esthétiques comme la disposition et la mise en forme du code, les conventions de nommage et ainsi de suite, ainsi que les potentielles mauvaises pratiques comme les oublis d’accolades après une condition en Java. Un style de codage cohérent réduit les coûts de maintenance, rend le code plus propre et plus lisible et permet de travailler plus facilement avec du code écrit par d’autres membres de l’équipe.
Seul un développeur expérimenté peut réellement juger de la qualité d’un code dans tous ses aspects. C’est le rôle des revues de code et, entre autres, des pratiques comme la programmation en binôme. En particulier, seul un œil humain peut décider si un bout de code est réellement bien écrit et s’il fait réellement ce que les exigences lui demandent de faire. Néanmoins, les outils de mesure de qualité de code peuvent être d'une grande aide. En effet, il n’est pas réaliste d’essayer de forcer des normes de codage sans ce type d’outil.
Ces outils analysent le code source ou le byte code de votre application et vérifient si le code respecte certaines règles. Les mesures de qualité de code peuvent englober beaucoup d’aspects de la qualité d’un code, des normes de codage et des meilleurs pratiques jusqu’à la couverture du code, en passant par les avertissements du compilateur jusqu’aux commentaires TODO. Certaines mesures se concentrent sur les caractéristiques mesurables de votre base de code, comme le nombre de lignes de code (NLOC), la moyenne de complexité du code ou le nombre de lignes par classe. D’autres se focalisent sur des analyses statiques plus sophistiquées, ou sur la recherche de bugs potentiels ou de mauvaises pratiques dans votre code.
Il y a une large gamme de plugins établissant des rapports sur la qualité du code disponibles pour Jenkins. Beaucoup sont des outils d’analyse statique Java, comme Checkstyle, PMD, FindBugs, Cobertura et JDepends. D’autres, comme fxcop et NCover, se focalisent sur les applications .NET.
Pour tous ces outils, vous devez configurer votre tâche de build pour générer les données de mesure de qualité de code avant que Jenkins puisse produire le moindre rapport.
L’exception notable de cette règle est Sonar. Sonar peut extraire des mesures de qualité de code depuis n’importe quel projet Maven, sans aucune configuration supplémentaire dans votre projet. Ce qui est excellent lorsque vous avez un nombre important de projets Maven qui doivent être intégrés à Jenkins et que vous voulez configurer des rapports de qualité de code cohérents sur tous les projets.
Dans le reste de ce chapitre, vous verrez comment configurer des rapports de qualité de code dans vos builds Jenkins et également comment les utiliser comme un élément efficace dans votre processus de build.