Statistiques sur le code

Bonjour,

Puisque les différents bots ne donnent plus de nouvelles, que j'ai envie de créer des tests d'intégration (donc avec selenium, pas simplement avec unittest) et que je voulais en savoir plus sur notre code et sa qualité, j'ai passé le code de zds à la moulinette sonar.

Le serveur sera bientôt disponible en plus ou moins privé, voici les différents résultats :

Et encore, là, je n'ai pas parlé de ce qu'il se passe quand on supprime les vieux modules de tuto et articles

Lorsqu'on enlève les artéfacts de l'ancien module c'est encore plus beau :

Element de Stat	valeur	évaluation
Lines of code	33 778	12K ligne de code en moins, logique
Files	236	N.A
Directories	50	N.A
Lines	44 064	N.A
Functions	1 901	25% de suppression de ligne mais seulement 15% de fonctions : nous avons donc affiner notre granulosité
Classes	545	N.A
Statements	20 893	N.A
Debt	11d	Donc le module de tuto/article contenait 3j de dette technique
Issues	796	et 156 problèmes de code dont 130 majeures
Duplications	5,1% lines 2 269/blocks 129/files 20	Forcément plus bas mais c'est toujours une très bonne nouvelle Par contre le module de tuto ne contenait "que" 60 blocs dupliqués
Complexity	5 122/function 2,7/class 9,3/file 21,7	On voit ici l'effet zep-12 qui a vraiment limité la casse côté fichiers

Cela prouve, si besoin était que :

• la zep-12 a vraiment simplifié le code
• qu'elle a vraiment réduit la dette technique

Ce qui devrait aussi faire plaisir à spacefox et Eskimon, c'est que même si nous sommes un gros projet, nous avons un code plutôt sain et que plus ça avance, plus les choses s'améliorent. Avoir 14 ou 11 jours de dette technique dans un projet aussi actif et massif que le nôtre c'est franchement impressionnant. Cela prouve aussi que les zestemeeting qui ont décidé les marches à suivre pour tester, documenter et améliorer le code sont couronnés de succès.

Je pense que c'est nécessaire de se rendre compte qu'on a vraiment un bon projet.

Bravo à tous !

Love

Sinon tu pourrais définir le terme "Dette technique" ?

Il y a toujours cet article. Dans ma boîte on me l'a présenté comme "le temps qu'il faut pour corriger les erreurs". C'est un "rapide" comme définition mais la majorité du temps ça s'en rapproche.

On parle parfois "d'inertie" aussi. Grosso modo, la difficulté à :

• rentrer dans le projet/code car l'existant est trop imposant/ mal conçu/mal organisé/trop spécifique. Si certaines sources peuvent être purement architecturale/techniques (mauvais choix accumulés) d'autres sont parfois fonctionnelles (tel besoin très spécifique a engendré tel bout de code "quasi-mort" mais dont il est difficile de se séparer et qui casse les pieds / prend du temps)

• monter en charge/perf car l'existant traîne la patte

• évoluer techniquement (changer de techno) : typiquement un couplage très fort entre plusieurs modules. Le fameux effet "on peut pas changer ça sans tout re-coder".

J'ai pas trop saisi le rapport entre l'audit du code et les tests d'intégration par contre Mais ça semble plutôt bien.

Note : gaffe avec Selenium, essaie de trouver des trucs un peu plus mûrs / haut niveau si tu peux (en gros : ça vaut le coup de prendre le temps de regarder). La notion de PageObjectde selenium est cool, mais un peu mieux implémentée (comprendre : moins casse-pied) dans d'autres frameworks (geb, pour ceux que je connais).

J'ai pas trop saisi le rapport entre l'audit du code et les tests d'intégration par contre Mais ça semble plutôt bien.

c'est pour justifier "jenkins + sonar" en fait : je vais mettre la tâche de TI dans le jenkins. C'est de là que vient le besoin au départ. Avoir un runner qui régulièrement, sans mon intervention verrifie qu'on est bon.

Note : gaffe avec Selenium, essaie de trouver des trucs un peu plus mûrs / haut niveau si tu peux (en gros : ça vaut le coup de prendre le temps de regarder). La notion de PageObjectde selenium est cool, mais un peu mieux implémentée (comprendre : moins casse-pied) dans d'autres frameworks (geb, pour ceux que je connais).

Le gros mieux ça serait robotframework mais je suis incapable de le faire fonctionner.

geb, je sais pas, je connais pas.

Selenium a pour principal défaut son moteur chrome qui est merdique à souhait (même le clic n'est pas 100% fonctionnel). Par contre comme je l'utilise au boulot et que notre wrapper unittest/selenium sera un jour opensource ça peut être un gain de temps non négligeable.

Jenkins est mort, Travis (et tous les moteurs d'intégration continue du genre) l'a tué.

Ça correspond à quoi la complexité ("complexity") et les différents chiffres donnés ?

La complexité correspond à la profondeur des fonctions et de l'héritage des classes.

@spacefox : pourtant pas mal de monde semble encore utiliser jenkins en entreprise.

Je suis pas vraiment d'accord avec SpaceFox non plus. Déjà parce qu'il reste effectivement (pas qu'en entreprise, pas mal de projets open source aussi, Hibernate par ex.) énormément utilisé.

D'autre part parce que "les moteurs d'intégration continue" je vois pas trop la différence dans les faits. Typiquement avec le couple Jenkins + Gradle, t'as absolument tout ce qu'il faut pour faire du CI très propre. Et cerise sur le gâteau, les rôles sont parfaitement isolés et la config de Jenkins réduite au minimum.

Jenkins ne te sert plus que d'interface de lancement, de gestion des rôles, etc. et est plutôt pratique pour ça grâce à ses pipelines.

Est-ce-que tu pourrais en dire un peu plus sur ce que tu as en tête stp ?

Je ne dis pas qu'il n'est plus utilisé mais que parier dessus pour le futur est pour moi une erreur.

C'est une simple histoire de configuration : sauf modifications dont je n'aurais pas connaissance, avec Jenkins, c'est ce dernier qui porte la configuration d'intégration continue. Avec les outils comme Travis, c'est le projet lui-même que porte ces configurations, le moteur de CI ne gérant plus que la partie technique qui ne peut pas être déportée (configuration des serveurs d'exécution des tests, notamment).

Ce qui a énormément d'avantage, que je ne vais pas paraphraser puisque GitLab a fait un post à ce sujet quand ils sont passés d'un modèle centralisé à la Jenkins à un modèle inspiré de Travis.

Et pour avoir fait cette transition, je peux te garantir que c'est beaucoup plus confortable avec le nouveau modèle. Et pourtant l'ancien modèle de GitLab (qui permettait de lancer des scripts arbitraires) était déjà plus agréable que Jenkins et son système de plugins.

C'est justement le point sur lequel j'appuie dans mon message.

Il n'est pas nécessaire que Jenkins porte la configuration. Tu peux utiliser un système de build comme Gradle ou autre qui lui dispose de l'ensemble de la configuration. La configuration est donc à 100% dans le projet (configuration de tâches, voire plugins maison si vraiment rien n'est standard).

Jenkins va se contenter d'afficher les différents projets, les numéros de version et leurs états, et lancer les bonnes tâches Gradle (et gérer qui a le droit de quoi faire). Et le fait plutôt très bien, avec un système de Pipeline qui va par exemple dire, pour le projet "ZdS", tu aurais deux tâches (définies dan Gradle) :

• déploiement en bêta
• déploiement en production

Regroupées dans une même pipeline "ZdS". Ce sont deux tâches Gradle (ou Maven ou Ant ou n'importe quel système de build un peu avancé).

La logique est dans le projet, dans le script ("je me connecte à tel adresse, en SSH, je fais une copie de fichiers, etc).

artragis possède les droits pour cliquer sur "deploiement bêta" mais pas sur le déploiement en production.

J'ai fait cette transition, depuis un système "tout Jenkins" vers un système dans lequel c'est Gradle qui fait quasiment tout. Jenkins n'étant qu'une web-UI de lancement. Et il me plaît énormément dans ce rôle, c'est clair et propre. Et le temps d'installation est très limité (encore une fois, le "gros" de la config est dans les projets, directement).

J'ai l'impression que pas mal de gens attribuent à Jenkins des défauts qui ne sont liés qu'à sa nature "je-peux-tout-faire". C'est un peu "don't shoot the messenger". Ce n'est pas parce qu'il est parfois mal utilisé qu'il faut le jeter aux orties. Il sait faire certains trucs bien. Il suffit de le limiter dans son rôle si on n'a pas besoin de plus.

On pourrait dire que Gradle a tué Jenkins, mais en fait non. Les deux sont tout à fait complémentaires.

Après je veux pas rentrer dans une guerre de clochers, Bamboo, Circle CI, Travis, etc. sont tous cools. Je préfère que ma config ne soit pas au format imposé par l'outil de CI, c'est simplement mon outil de build (gestion des dépendances + tâches + plugins) qui doit s'occuper de cela et je peux plugger là-dessus n'importe quel outil de CI (Jenkins, Bamboo, …) qui n'est plus qu'un chef d'orchestre "graphique" presque. Les deux sont pour moi complémentaires. Et Jenkins remplit le rôle de simple orchestrateur à la perfection. (en gros : tel bouton == telle tâche <=> telles personnes, et basta).

Après, ZdS a probablement fait les bons choix sur le coup donc y'a pas non plus à épiloguer, mais la discussion m'intéresse.