Discussion :

[Arsene Newman]

Pourquoi les builds échouent si souvent ?
Une étude de Google tente de répondre à la question

Pourquoi les builds des logiciels échouent ? Voilà une question qui revient souvent chez les développeurs logiciels, quant aux réponses elles sont diverses même si une nouvelle étude révèle l’existence de certains points communs

Menée conjointement par Google, l’Université des sciences et des technologies de Hong Kong et l’Université du Nebraska, cette étude tente de répondre à trois questions : A quelle fréquence les builds échouent ? Pourquoi échouent-elles ? Et enfin combien de temps faut-il pour les fixer ?

Pour répondre à ces questions, un échantillon de 26 millions de builds effectuées par 18.000 ingénieurs de Google a été utilisé. Quant aux langages utilisés pour ces builds, il a été question du C++ et de Java.

L’étude s’est intéressée en particulier aux erreurs générées lors de la compilation des builds par le compilateur javac (pour Java) et le compilateur LLVM Clang (pour le C++), elle les a classés en 5 catégorie : dépendance, incompatibilité de type, syntaxique, sémantique et autre.
Les résultats de l’étude débouchent alors sur trois constats :

L’échec des builds n’est pas relatif à leur fréquence ou à l’expérience du développeur : alors que l’on pourrait penser que le développeur expérimenté est moins en proie aux échecs, l’étude démontre qu’il n’y a pas de corrélation entre l’expérience du développeur et le taux d’échec.

La majorité des erreurs sont des erreurs de dépendances : Dans le cas de Java pas moins de 65% des erreurs sont relatives à des dépendances, alors que pour le C++ ce taux avoisine les 53%. En tête de liste des erreurs récurrentes en C++: l’identifiant non déclaré et les variables de classe manquantes.

Le C++ génère plus d’erreurs que le Java, mais elles sont plus faciles à corriger en contrepartie : 38.4% et 28.5% voilà donc les taux d’échec respectifs dans le cas d’un projet C++ et Java. L’étude révèle aussi la récurrence des erreurs syntaxiques sous C++ comparé à Java, ce qui s’explique par l’utilisation plus fréquente des IDE sous Java, expliquant par la même occasion la différence entre les deux taux et la facilité de correction des erreurs sous C++ comparé à Java.

Au final, cette étude apporte certains éléments de réponse par rapport à l’échec des builds, mais il est difficile de généraliser ces résultats sur le développement logiciel d’une manière globale, d’autres études sont nécessaires pour appuyer ces résultats.

Source : Etude de Google

Et vous ?
Qu’en pensez-vous ?
Etes-vous d’accord avec les résultats de cette étude ? Pourquoi ?

[atha2]

C'est quoi un build en Java ?? Les compilations en temps réel fait pas l'IDE sont-elles prises en compte ?

Dans le cas de Java pas moins de 65% des erreurs sont relatives à des dépendances, alors que pour le C++ ce taux avoisine les 53%. En tête de liste des erreurs récurrentes en C++: l’identifiant non déclaré et les variables de classe manquantes.

C'est moi qui ai un problème avec les statistiques ou il y a une incohérence ? Comment 53% des builds échoués en C++ liés à une dépendance manquante, peuvent ne pas être en tête ? Mauvaise traduction ?
Sinon il serait intéressant que savoir comment travail les développeurs C++ chez Google, avec un IDE comme Visual Studio (Complétion...) ? Dans le cas contraire, ça explique facilement la différence avec Java.

Le C++ génère plus d’erreurs que le Java, mais elles sont plus faciles à corriger en contrepartie : 38.4% et 28.5% voilà donc les taux d’échec respectifs dans le cas d’un projet C++ et Java. L’étude révèle aussi la récurrence des erreurs syntaxiques sous C++ comparé à Java, ce qui s’explique par l’utilisation plus fréquente des IDE sous Java, expliquant par la même occasion la différence entre les deux taux et la facilité de correction des erreurs sous C++ comparé à Java.

Je vois mal comment on peut builder (génération jar, war...) avec des erreurs de syntaxe en Java...
Sinon dire que les erreurs sont plus faciles à résoudre en C++ qu'en Java, en se basant sur les statistiques, oui on peut dire ça. Mais une fois enlevées, les erreurs triviales (variables non déclarées, erreurs de syntaxe...), je pense que c'est juste n'importe quoi

En fait, je ne vois pas l’intérêt de comparer Java et C++; les outils de développement ne sont pas les mêmes (pas d'IDE). Par contre savoir qu'en général, les builds échoue plus à cause d'un dépendance manquante en Java et à cause d'un problème de syntaxe en C++ (pris séparément), peut donner une indication sur les outils à mettre en place dans ces 2 langages pour gagner du temps.
Pour résumer : en java, la syntaxe est vérifiée par l'IDE et les problèmes de dépendances manquantes sont généralement liés à une différence entre l'environnement de développement (JRE/JVM/etc fourni par l'IDE, différent de celui ciblé) et celui de production. En C++, la syntaxe n'est pas vérifiée automatiquement avant la compilation

[spidetra]

C'est quoi un build en Java ?? Les compilations en temps réel fait pas l'IDE sont-elles prises en compte ?

L'étude porte sur le système de build centralisé de google. Système de build propriétaire.
Par exemple, Un build peut inclure 2858 targets dans 6 langages différents.

C'est moi qui ai un problème avec les statistiques ou il y a une incohérence ? Comment 53% des builds échoués en C++ liés à une dépendance manquante, peuvent ne pas être en tête ? Mauvaise traduction ?

Il faut distinguer les 5 catégories : dépendance, incompatibilité de type, syntaxique, sémantique et autre
Des types d'erreurs : l’identifiant non déclaré et les variables de classe manquantes.

Identifiant non déclaré appartient à la catégorie : Dépendance.

Sinon il serait intéressant que savoir comment travail les développeurs C++ chez Google, avec un IDE comme Visual Studio (Complétion...) ? Dans le cas contraire, ça explique facilement la différence avec Java.

Java : Eclipse & IDEA (90% ddes developpeurs java)
C++ : Emacs ou Vi (80% des developpeurs C++)

Je vois mal comment on peut builder (génération jar, war...) avec des erreurs de syntaxe en Java...

Il faut distinguer le build local dans son IDE, du build avec le système centralisé de Google.
Avant chaque commit, un dvp doit s'assurer que son code build avec le système centralisé, et pas seulement en local.

[mmw01]

Le C++ génère plus d’erreurs que le Java, mais elles sont plus faciles à corriger en contrepartie : 38.4% et 28.5% voilà donc les taux d’échec respectifs dans le cas d’un projet C++ et Java. L’étude révèle aussi la récurrence des erreurs syntaxiques sous C++ comparé à Java, ce qui s’explique par l’utilisation plus fréquente des IDE sous Java, expliquant par la même occasion la différence entre les deux taux et la facilité de correction des erreurs sous C++ comparé à Java.

Au final, cette étude apporte certains éléments de réponse par rapport à l’échec des builds, mais il est difficile de généraliser ces résultats sur le développement logiciel d’une manière globale, d’autres études sont nécessaires pour appuyer ces résultats.

Qu'est ce qu'ils veulent nous montrer avec cette étude ?
si les builds échouent c'es pas justement pour ca qu'ils sont fait en premier pour déceler les erreurs !!
car on aura beau verifié le code et les dépendances c'est à la compilation qu'on verra s'il y a erreur ou pas !!

[Paul TOTH]

Qu'est ce qu'ils veulent nous montrer avec cette étude ?
si les builds échouent c'es pas justement pour ca qu'ils sont fait en premier pour déceler les erreurs !!
car on aura beau verifié le code et les dépendances c'est à la compilation qu'on verra s'il y a erreur ou pas !!

je suppose que l'étude porte sur le build d'un produit distribué sous forme de source. je prend les sources, je build, et hop ça ne marche pas.

[spidetra]

je suppose que l'étude porte sur le build d'un produit distribué sous forme de source. je prend les sources, je build, et hop ça ne marche pas.

Non, l'étude porte sur le système de build centralisé de Google.

[pmithrandir]

Est-ce que l'on parle bien d'intégration continue ?

Parce que si c'est le cas, je pense que vu la flanquée de test à exécuter avant chaque livraison sur un repository (svn ou git) alors que ca sera de nouveau testé automatiquement par le serveur... c'est normal que les gens oublient, voir fasse confiance à la machine derrière.
Sur une petite équipe, ou avec des système comme git, le système fonctionne très bien avec des build qui échouent. Au pire, on redeploie la version de la veille ou la dernière version qui passe le build. rien de grave.

[Marco46]

Est-ce que l'on parle bien d'intégration continue ?

Parce que si c'est le cas, je pense que vu la flanquée de test à exécuter avant chaque livraison sur un repository (svn ou git) alors que ca sera de nouveau testé automatiquement par le serveur... c'est normal que les gens oublient, voir fasse confiance à la machine derrière.
Sur une petite équipe, ou avec des système comme git, le système fonctionne très bien avec des build qui échouent. Au pire, on redeploie la version de la veille ou la dernière version qui passe le build. rien de grave.

Non c'est pas normal, ça veut dire que le dev ne sait pas utiliser ses tests.

Pour moi c'est une erreur qui doit entrainer une sanction sans appel : l'achat de chocolatines pour l'ensemble de l'équipe le lendemain.

Plus sérieusement, pousser du code niqué sur un repo ça veut dire pousser des bugs aux autres, ce qui peut facilement faire perdre des heures avant que ça ne soit détecté. Donc c'est pas anodin.

[spidetra]

Qu'est ce qu'ils veulent nous montrer avec cette étude ?

Ils ne veulent rien nous prouver. Ils essaient de comprendre pourquoi et comment des builds échouent.
26.6 M de builds en 6 mois pour 18.000 dvp.

Pour Google, analyser et comprendre les raisons des échecs doit leur permettre de mettre en place des plans d'actions pour améliorer leurs process, mettre en place des outils, sensibiliser les dvps, etc...

[23JFK]

Ceci est-il censé expliquer le total fuck-up que fiche l'update r23 dans eclipse-adt (pour android) ?

[atha2]

Ceci est-il censé expliquer le total fuck-up que fiche l'update r23 dans eclipse-adt (pour android) ?

J'aaaaaaiiiiime
Pour info, c'est au moins la 3ème fois que ça arrive. Perso j'ai carrément tout perdu (sauf le projet). J'ai désinstallé les plugins de la version précédente pour résoudre le conflit, mauvaise idée. Je me suis retrouvé sans exécutable . C'est un peu du foutage de gueule de la part de Google. Ils n'ont pas testé la MAJ avant de la publier ? J'aurais bien poussé un coup de gueule sur leur page Google + mais j'ai pas trouvé comment créer un nouveau poste
Du coup je suis passé à Android Studio.