IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Build Java Discussion :

Le temps moyen d'un build Java est de 1,9 minutes d'après une étude de RedMonk


Sujet :

Build Java

  1. #1
    Expert éminent sénior

    Inscrit en
    juillet 2009
    Messages
    3 407
    Détails du profil
    Informations forums :
    Inscription : juillet 2009
    Messages : 3 407
    Points : 148 705
    Points
    148 705
    Par défaut Le temps moyen d'un build Java est de 1,9 minutes d'après une étude de RedMonk
    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?

  2. #2
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 63
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 391
    Points
    17 391
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Gordon Fowler Voir le message
    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).
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  3. #3
    Rédacteur

    Homme Profil pro
    Geek entrepreneur
    Inscrit en
    novembre 2004
    Messages
    1 224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Geek entrepreneur

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 224
    Points : 2 309
    Points
    2 309
    Par défaut
    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.

  4. #4
    Membre régulier
    Inscrit en
    novembre 2004
    Messages
    76
    Détails du profil
    Informations forums :
    Inscription : novembre 2004
    Messages : 76
    Points : 88
    Points
    88
    Par défaut
    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.
    Waddle

  5. #5
    Membre expérimenté
    Profil pro
    Inscrit en
    septembre 2006
    Messages
    477
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : septembre 2006
    Messages : 477
    Points : 1 481
    Points
    1 481
    Par défaut
    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

  6. #6
    Inactif  
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    357
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2008
    Messages : 357
    Points : 514
    Points
    514
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    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...

  7. #7
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 248
    Points
    2 248
    Par défaut
    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 ?

  8. #8
    Membre confirmé
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    548
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2006
    Messages : 548
    Points : 620
    Points
    620
    Par défaut
    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é

Discussions similaires

  1. Java est-il adapté pour le développement d'une application DAO et CAO ?
    Par Pascaltech dans le forum Débuter avec Java
    Réponses: 2
    Dernier message: 05/02/2015, 18h54
  2. Réponses: 65
    Dernier message: 19/11/2010, 13h40
  3. Réponses: 5
    Dernier message: 30/10/2009, 16h10
  4. Réponses: 0
    Dernier message: 28/07/2009, 14h39
  5. le Java est la continuité du C++ ???
    Par Vincent PETIT dans le forum Débats sur le développement - Le Best Of
    Réponses: 33
    Dernier message: 25/08/2005, 20h17

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo