Discussion :

[Gordon Fowler]

Le temps moyen d'un build Java est de 1,9 minutes,
Il semble raccourcir avec les années, d'après une étude de RedMonk

La société RedMonk vient de constater, après avoir réalisé une étude sur le sujet, que concevoir des applications en Java posait encore beaucoup de problèmes... mais que les développeurs avaient mis au point nombre d'astuces pour raccourcir le temps de build des applications.

Le responsable de l'étude, Michael Cote, note que la plupart des projets Java sont de taille importante et impliquent de nombreuses étapes pour construire un livrable fini, en plus de la compilation habituelle que nécessite tout projet Java. Les développeurs auraient donc en premier lieu appris à s'occuper de plusieurs petites portions du projets en même temps, puis à compiler des sous-parties du code pour les injecter dans les applications. Cette modularisation des projets (mais également des tâches), permet de gagner beaucoup de temps et les outils de build actuels le font très bien.

L'étude constate également que les builds automatisés n'augmentent pas simplement la vitesse de production du code (ce qu'ils font bien évidemment par ailleurs). Mais ils l'aident également à rester "propre" et améliore grandement le produit fini. Lancer un test unitaire toutes les heures permettrait par exemple, d'après RedMonk, de diminuer les probabilités d'obtenir un logiciel de mauvaise qualité. En obligeant les tests unitaires à passer et à réussir avant le packaging d'une application, on gagne en sécurité quant à la qualité du livrable.

L'étude confirme également que les outils pour la gestion et l'automatisation de production des projets logiciels Java sont largement dominés par le monde l'open-source (notamment Maven et Ant).

Le résultat cumulé de ces "astuces" et de ces outils serait un gain de temps d'environ 10 minutes par heure.

Plus précisément, sur plus de 500 développeurs, 44% affirment que leurs builds incrémentaux prennent moins de 30 secondes et 40 % entre une minute et trois minutes. Mais, il reste toujours 5% des développeurs pour qui les builds durent plus de 10 minutes.

Le temps moyen d'un build étant pour sa part d'environ 2 minutes (1.9 minutes pour être précis). On peut également noter qu'un développeur passe en moyenne 6 minutes par heure à builder son projet.

Cela correspond-il à votre expérience ?

Source

Lire aussi :

La rubrique Java
Quel(s) outil(s) de build Java utilisez-vous et pourquoi ?

Et vous ? :

Les résultats de cette étude vous étonnent-ils?

[souviron34]

Les résultats de cette étude vous étonnent-ils?

absolument pas...

Se cacher derrière "une simplicité apparente pour les programmeurs" et le découpage systématique en classes des Langages Objets implique forcément que le système (et en particulier le compliateur) passe à travers plus de fichiers, demande l'ouverture simultanée de plus de fichiers, etc etc... (et je signale que les IO et en particulier les ouvertures de fichiers sont consommatrices)

C'est mathématiquement et logiquement parfaitement normal..



Si on prenait le même programme fait en langage non-objet, avec la mémoire et le CPU qui était dispo il y a 10 ans, la différence serait encore plus flagrante : je n'hésiterais pas à parier sur un facteur minimum de 10 (et plutôt de l'ordre de 100 voire plus).

[hugo123]

J'ajouterais un gros bémol sur la signification du mot "build".
La compilation a proprement parler est très courte, ce n'est pas ca qui prend du temps sur un "build". Si l'auteur a la même conception que moi d'un build, alors un build c'est compil, tests, packaging au minimum.
J'utilise pas mal maven et l'intégration continue est clairement adopté chez nous. On a des builds d'une heure avec 500 tests, des packagings en archive web, du déploiement sur tomcat etc.. tout ca de facon automatisé. On a des builds plus courts de 1 ou 2 min sur des projets qui ne nécessitent qu'une 50aine de tests.

En jetant un oeil sur leur article, ca ne ressort pas bien. C'est d'ailleurs assez bizaremment expliqué puisqu'on voit des comparaisons de temps de build entre des IDE, ant ou maven issu d'un sondage. Autrement dit les sondés n'ont jamais indiqué ce qu'ils faisaient dans leurs builds !!
Du coup comparer un build d'eclipse qui ne fait que de la compil a un build maven ou ant c'est pas très pertinent...

Bref, c'est une étude un peu étrange sur sa façon de procéder et ses conclusions.

[waddle]

Effectivement, ce n'est pas très clair comme termes. Par contre, la société qui a commandé l'étude propose JRebel, qui est précisément un outil pour recharger à chaud les fichiers de conf Java sans avoir à redéployer. Maintenant, ceux qui utilisent Jetty avec Maven par exemple, n'ont pas de problème puisque la modif d'un fichier de conf provoque le reload de l'application. Ce reload n'est jamais très long avec Jetty, à peine une poignées de secondes. De même avec m2eclipse et WTP.

[LeSmurf]

Au sens large du terme "build", certains me prenaient 15 ou 20 minutes.
Il s'agissait d'une entreprise qui sous-équipait les développeurs.

En gros, ma machine possédait 1Go de Ram, mais Eclipse + le serveur d'application (pas Tomcat, je parle bien de serveur d'application) + une base Oracle en local + des outils divers et variés, la machine démarrait avec 1.5Go de Ram utilisée, le disque dur tournait presque en permanence. Lors du Build, ça dépassait les 2Go, tout devenait très lent, la machine devenait inutilisable pendant le build, ça prenait un temps fou.

Nous avions envoyé des copies d'écran montrant la Ram engorgée, nous avons supplié un 2e Go de RAm car nous passions notre temps à attendre la machine. Réponse : "non, car pas de budget". Quand je vois la perte de temps (donc délais, argent...) comparé au prix de la RAM, je n'en revenais pas

[Furikawari]

absolument pas...

Se cacher derrière "une simplicité apparente pour les programmeurs" et le découpage systématique en classes des Langages Objets implique forcément que le système (et en particulier le compliateur) passe à travers plus de fichiers, demande l'ouverture simultanée de plus de fichiers, etc etc... (et je signale que les IO et en particulier les ouvertures de fichiers sont consommatrices)

C'est mathématiquement et logiquement parfaitement normal..



Si on prenait le même programme fait en langage non-objet, avec la mémoire et le CPU qui était dispo il y a 10 ans, la différence serait encore plus flagrante : je n'hésiterais pas à parier sur un facteur minimum de 10 (et plutôt de l'ordre de 100 voire plus).

A mon avis tu inverses le résultat de l'étude, ce qui est mis en avant ce sont des temps de build vraiment courts comparativement à la complexité des applications développées...

[Traroth2]

C'est un peu bizarre, comme statistique. Ça dépend fortement de la taille du projet, à l'évidence, et là on cherche à en faire une sorte de critique implicite de Java. Mon projet, toute la partie serveur d'un site de partage photo, ça met moins de 20 secondes. Pour obtenir un build de 2 minutes, ça doit déjà être un projet phénoménal. J'ai vu des choses comme ça dans une boite de logistique, avec une application gigantesque. Le problème de l'article, c'est que je ne vois pas où cette étude veut en venir. Les gros projets mettent plus de temps que les petits à builder ? Ça surprend quelqu'un ?

[the-gtm]

L'étude vient d'une boite qui vend un logiciel permettant de remplacer à chaud les classes (et donc de raccourcir le cycle code/build/test). De là à douter de leur objectivité