Pourquoi les builds échouent si souvent ?
Une étude de Google tente de répondre à la question
Le 2014-06-30 05:25:41, par Arsene Newman, Expert éminent sénior
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 ?
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 ?
-
Marco46Expert éminent séniorNon 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.le 02/07/2014 à 10:14 -
mmw01Membre du ClubQu'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 !!le 30/06/2014 à 21:17 -
Paul TOTHExpert éminent séniorje 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.le 30/06/2014 à 21:37
-
spidetraMembre confirmé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.
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.
Java : Eclipse & IDEA (90% ddes developpeurs java)
C++ : Emacs ou Vi (80% des developpeurs C++)
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.le 30/06/2014 à 23:39 -
23JFKMembre expertCeci est-il censé expliquer le total fuck-up que fiche l'update r23 dans eclipse-adt (pour android) ?le 01/07/2014 à 17:20
-
atha2Membre éprouvé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.le 01/07/2014 à 21:30 -
pmithrandirExpert éminentmarco, il faudrait donc, pour que le boulot soit plus agréable, automatiser ce prebuild avant commit.(voir de tester qu'il a été fait, pas trop dur avec un checksum par exemple)
Pour ma part, jee dirais que ca dépend de plusieurs facteurs :
- la taille de l'équipe, on ne travaille pas de la même façon a 5 ou a 15.
- Les exigences en terme de deploiement continu.
Parce que ca ne me choque pas qu'une petite équipe a plusieurs mois de la release ne perde pas son temps a exécuter tous les tests quand jenkins le fera 10 minutes plus tard sur une machine mieux configuré. La perte de temps n'étant dailleur pas si grande en général.le 02/07/2014 à 16:57 -
Marco46Expert éminent séniorOui il faut que chaque dev puisse builder l'application sur son poste. Et le temps de build + test doit être de l'ordre de 5/10 mins. Les TU ne coutent rien en temps d'exécution, si ton projet est vraiment énorme il faut le modulariser et faire gaffe aux tests d'intégrations et e2e c'est ça qui bouffe du temps.Parce que ca ne me choque pas qu'une petite équipe a plusieurs mois de la release ne perde pas son temps a exécuter tous les tests quand jenkins le fera 10 minutes plus tard sur une machine mieux configuré. La perte de temps n'étant dailleur pas si grande en général.
Et plus tu tardes à détecter les régressions plus elles sont longues à résoudre. Et puis ça contribue à une mauvaise ambiance de travail en +.le 03/07/2014 à 16:18 -
spidetraMembre confirmé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...le 30/06/2014 à 23:44 -
spidetraMembre confirméle 30/06/2014 à 23:44