Heureux ceux qui peuvent se passer de cette usine à gaz écrite en Java qui porte bien son nom !
Heureux ceux qui peuvent se passer de cette usine à gaz écrite en Java qui porte bien son nom !
Oui, enfin il faut bien choisir ce qui est commun à un niveau ou un autre. Le mettre au niveau des sources et du build me semble raisonnable : on convient de technos (par ex. java, java ee, maven...). Le mettre au niveau de l'IDE n'apporte aucune plus-value. Au contraire, ça rigidifie le projet.
J'ai bossé dans des petits projets rigides, dans des gros rigides et de gros projets plus souples (je dirais même "agiles", c'est finalement un état d'esprit général). Ce n'est pas la taille du projet qui fait la différence. Et vraiment, la qualité finale est bien meilleure dans les projets souples sur les outils mais stricts sur les règles de base. C'est un compromis entre règles et libertés. Les règles de base étant appliquées strictement, mais ouvertes à l'évolution.
Honnêtement, je n'ai jamais vu qu'imposer un IDE améliorait le projet, même pas la vélocité. Par contre, imposer que le projet fonctionne sur plusieurs IDE et ne soit pas bridé pour l'un ou l'autre améliore à terme sa qualité.
Par contre, ça impose aussi de faire le tri entre les règles importantes et celles qui ne le sont pas vraiment. Des règles trop rigides sur les espaces et un outil de diff ou de code review qui les affiche tous en rouge, par exemple, ne permettent pas d'avancer. Mais c'est en général facile à régler définitivement, en laissant tomber quelques coupages de cheveux en 4 qui n'apportent rien au projet.
Un IDE n'est pas qu'un editeur de code ! Un développeur n'est pas seul dans son coin ! Un IDE doit permettre le travail en équipe... es-tu sûr que l'on retrouve toutes les mêmes fonctionnalités du travail en groupe sur tous les IDE ?
Ce n'est pas une question de vélocité mais de travail en groupe... encore une fois il n'y a pas que le code que l'on partage !
OK pour les espaces... passsons aux indentations, aux formatages des blocs, la longueurs de lignes, caractère de fin de ligne, les convensions de nomage, etc (jette un oeuil sur checkstyle) ! toutes ces règles qui n'ont pas d'importance quand on travail seul...
a+
Philippe
Tu as raisons toutes ces règles doivent être communes à l'équipe. Toutes ces règles, l'outil de build (Maven, Graddle, Ant ou autre), etc, etc.
Mais Ymajoros a raison, toutes ces règles, tout ces outils sont indépendants de l'IDE.
Faire cohabiter une équipe hétérogène IDEA / Eclipse ne pose aucun problème de compatibilité.
Chez nous les dvps qui font de l'Android Studio, sont bien content d'utiliser iDEA pour les devs Java.
Et les dvps ont plus un background RCP, sont bien content de pouvoir continuer à utiliser Eclipse s'ils le désirent.
Est-ce que la meilleure solution c'est d'imposer le même IDE à toute l'équipe ou de laisser un degré de liberté ?
Je ne sais pas. Cela dépend du contexte de l'entreprise, de la volonté du chef de projet ou du directeur technique.
Dans notre équipe java c'est Eclipse / IDEA et ça se passe très bien.
Dans l'équipe d'à côté (C/C++): c'est Emacs, Vi, notepad++, Eclipse, Windows, Linux... et ça se passe bien aussi. L'équipe est bc plus hétérogène, et il ne doit pas y avoir 2 postes dvps identiques... mais une seule plate-forme d'intégration pour les gouverner tous.
a+,
--
Philippe
Et bien figure toi que la derniere version founi un theme Dark justementSans compter que je ne suis pas trop fan d'un IDE blanc. Il aura fallu la dernière version pour l'avoir en noir.
Tu peux preciser?
Quels types de projets? Quels langages? Comme dit plus haut, ceci est configurable.L'IntelliSense (j'ai oublié le nom sous eclipse) est plus que lent
Je suis pas sur de comprendre ce point. Tu peux preciser?Crée des dépendances à lui même
Quels types de projets? Quels langages? Tu peux preciser?Le debugger est juste horrible
C'est la premiere fois que je lis une critique concernant le debuggeur, je suis curieux!
Mieux vaut en rester aux discussions fonctionnels. On ne va pas troller sur les choix d'architecture qui sont un peu hors-sujet.Malheureusement il est codé en java (java et les appli graphique ...)
Checkstyle c'est configurable. Tout ça se gère très bien en équipe, il suffit de ne pas mettre de règles trop rigides. Ce que je dis pour les espaces vaut pour les autres points (indentation etc.). 98 % peut être configuré de manière commune sur tous les IDE, les autres 2 % n'en valent souvent pas la peine. Pour les différences d'espaces et d'indentation, il suffit après de configurer son diff pour que ce ne soit même pas considéré comme une différence. Ça ne suffit vraiment pas pour imposer un IDE à toute une équipe.
Je n'ai pas dit qu'un IDE n'était qu'un éditeur de code. Cela dit, il ne peut devenir le seul outil qui permet de l'éditer.
Concernant le travail en équipe, j'ai toujours utilisé des outils qui fonctionnaient indépendamment d'un IDE spécifique. Si ce n'est pas le cas, l'outil doit être remis en cause. Qu'on parle de bug tracker, de gestion de projet, de contrôle de version, je ne vois pas pourquoi ça doit justifier un IDE spécifique. Si c'est intégré (et c'est souvent le cas), tant mieux, mais ça ne fige pas l'IDE.
Je trouve le travail en équipe plus productif et plus intéressant quand il n'y a pas de règle rigide sur l'IDE.
Il ne suffit pas de le dire pour que ce soit vrai, d'autant plus qu'on a vite fait d'occulter les problématiques qu'on a pu rencontrer vis-à-vis d'une trop grande hétérogénéité. Tu dis ça comme si tu avais toujours le choix des outils et comme si des équivalents existaient systématiquement. Ta vision des choses est quelque peu utopique et ne convient pas dans pas mal de cas.
Sur un environnement hétérogène, tu dois multiplier les procédures de configuration et d'installation, de manière à pouvoir intégrer de nouveaux arrivants dans une équipe dans les meilleurs délais, ou pouvoir reprendre rapidement en cas de crash disque par exemple. Sans compter que tout ne tourne pas autour de Maven, censé nous libérer des contraintes de chaque IDE, donc croire que le choix de celui-ci n'a pas d'importance s'avère hasardeux. De plus, tu sous-entends quelque part que tout développeur connaît parfaitement son IDE, cela met donc de côté les novices ou ceux dont le premier problème est déjà de maîtriser les langages et les frameworks employés... De fait, lorsque quelqu'un à un problème de configuration ou disponibilité d'un outil sur l'IDE qu'il a choisi (en connaissance de cause ou par défaut), il aura mécaniquement moins de personnes susceptibles de lui venir en aide et il perdra donc davantage de temps à chercher lui-même des solutions. Ca reste de fait, un facteur de perte de temps inutile.
Ca ne veut pas dire qu'il faut s'interdire quoi que ce soit, ça veut simplement dire qu'il ne faut pas être naïf en pensant que l'imposition d'un IDE n'est pas nécessaire.
Il ne suffit pas non plus de dire l'inverse pour que ce soit vrai. C'est mon expérience, et ce en quoi je crois : des organisations agiles de projets plutôt que des outils choisis arbitrairement.
J'ai la chance d'avoir un bon pouvoir des décisions dans mes projets. Je suis freelance et c'est un de mes critères de sélection. Ça aide, mais je participait à l'évolution aussi quand j'étais employé : c'est une question de volonté. Si je pense qu'on peut améliorer quelque chose, je le fais, dans la mesure du possible. Ça fonctionne en général très bien, ça n'a rien d'utopique. C'est adapter les outils, ça fait évoluer.
C'est en général bien plus simple qu'on ne le pense. Faire tomber la contrainte d'IDE est en général la première chose qui améliore les choses : le build du projet se retrouve très vite apuré, donc souvent plus rapide, etc.
Cela dit, le choix de l'IDE n'a rien de compliqué ou d'hasardeux. Un projet sain doit avoir au moins la règle suivante : il doit être facile à ouvrir, même la première fois. Checkout/clone + ouverture dans l'IDE. S'il y a plein de choses à définir, il y a un problème. Le setup de tous mes projets depuis des années, c'est installer la version de base de l'IDE, du serveur d'apps, puis ouvrir le projet.
C'est sûr que certains ont parfois plus de mal à prendre leur IDE en main. Mais avec un projet qui build en une étape, ça ne peut pas être un problème qui dure. Qu'on utilise Maven, Gradle, Ant ou n'importe quoi, cette étape doit chaque fois être facilement réalisable. S'il y a une différence entre le build de base et le comportement de l'IDE, on sait où chercher. Si ça arrive régulièrement, l'IDE est probablement inadapté. Il faut parfois le courage de faire ce constat.
Dans un projet, il faut une certaine maîtrise. Idéalement, toute l'équipe doit connaître ses outils. Sinon, c'est du bricolage. Que certains soient plus spécialisés que d'autre, c'est évidemment naturel. Aux "suiveurs" de décider de leur IDE en conséquence.
Note qu'en pratique, 3/4 des développeurs suivent le mouvement et prennent ce qu'il y avait sur le poste le premier jour. Ceux qui font d'autres choix savent généralement pourquoi et sont capables de gérer. C'est souvent à ce moment que les règles doivent être adaptées, pour permettre à tout le monde de bien faire son boulot sans être bloqué par les choix des autres. En pratique, je n'ai jamais vu ce genre de réflexion impacter le projet négativement, au contraire.
Le cas où je te rejoins, c'est si l'équipe est composée en majorité de juniors. En ce sens, avoir un IDE commun peut aider à y voir clair. Mais le choix de l'IDE est alors d'autant plus important.
Pour mon métier de tous les jours (Modeling, plugins), Eclipse est un pur bonheur (et c'est aussi le seul permettant de le faire...).
Par contre, pour mes expériences nocturnes, je suis loin de le trouver optimal, même si je n'ai toujours pas trouvé mieux:
- M2E est un boue: il n'utilise pas le PATH de la machine, compile en utilisant JDT... Je désactive toutes ses fonctionalités par défaut et lance mvn:compile dansune fenêtre shell (intégrée dans eclipse).
- JSDT (Javascript) ne fais rien à part changer l'icône des fichiers js: à mon avis Eclipse est en train de perdre beaucoup en ne faisant rien pour intégrer correctement Javascript.
- Il demande une certaine expertise: après 5 ans dessus, je commence à bien le manipuler, mais ça a été long.
- Beaucoups de langages ne sont pas supportés: Ruby, ... Quand à Aptana studio: JAMAIS.
- Il prend quand même pas mal de ressources (comparé à IJ, NB): pour y remedier j'ai vendu un de mes reins pour m'acheter un MBP avec 8 coeurs, 16go de RAM...
- Il est impossible de faire un merge avec EGit: l'interface n'est vraiment pas optimale.
- WTP ne fonctionne pas très bien quand on sort des clous (Spring,où des configuration EE un peu poussées): ma solution a été d'arrêter J2E car c'est de là que vient le problème.
Je tourne maintenant avec Eclipse pour du Java, et RubyMine (IntelliJ) pour Ruby et Javascript.
Bref, c'est un IDE plein de défauts où nombre de choses sont à améliorer, mais ça reste le meilleurs de loin pour la programmation Java.
Charlie,
--
Full OSGI/EE stack avec Karaf: https://github.com/OsgiliathEnterpri...giliath.parent
@Tcharl: pour le js, jsdt seul n'est en effet pas fou. Quand tu dis "rien a part changer l'icone", ce n'est pas juste par contre: j'ai de la validation a la volee, de la completion... Ca ressemble plutot a un souci dans ta conf.
Pour les features, il y a des extensions interessantes a jsdt sur MarketPlace: tern, angular...
Pour le JEE, peux-tu donner des details? Et pour m2e aussi? Idealement en reportant les cas d'erreurs et les suggestions sur bugs.eclipse.org.
Pareil pour EGit.
Et t'as essaye JBoss Tools? Ca semble correspondre pour beaucoup a ce dont tu aurais besoin pour tes devs du soir: JEE, extensions a JSDT, connecteurs m2e/jee qui vont bien..
@Mickael C'est vrai, je suis exactement en train de faire ce dont je n'aime pas que les autres fassent... Désolé.
Pour Jsdt, la complétion est là quand es variables appartiennent au même fichier, ce qui est un peu limité (surtout quand on fait du Angular). J'attends la sortie des JBoss tools nouvelle version avec Tern et consorts pour réviser mon jugement mais pour l'instant force est de constater qu'Intellij est nettement au dessus.
Pour JEE, il est très difficile de faire cohabiter Maven et le build Eclipse, à l'époque, quand je faisais du Was6 et du Liferay j'étais sans cesse obligé de rebooter le serveur. Un cas qui fonctionne à tous les coups: obligé de rebooter le serveur quand on change une ligne de xml dans un contexte Spring, ce qui est assez gênant quand on fait du bean-wire par xml...
Pour M2E: la première fois que je clone mon framework perso dans un Eclipse, il met plus de 24h à compiler ! Il boucle sur des exécutions du maven-exec-plugin (qui pourtant a un lifecycle désactivé pour l'incrémental). Une fois l'IDE redémarré une trentaine de secondes suffisent. De même, il met parfois plus de 5 minutes après un CTRL+S à faire... Rien... . Finalement, il utilise un PATH par défaut et pas celui de l'utilisateur (/bin, /usr/bin). Etant donné que j'utilise le mvn-exec pour lancer npm (qui se trouve dans /usr/local/bin) ça coince (il y a des hack bien sûr, mais ce n'est pas très propre).
J'ai bien essayé de discuter avec les mec de chez M2E, mais il ne sont pas du tout réceptifs aux remarques, voir aggressifs même si on leur prouve par A+B qu'ils n'ont pas fait le plus judicieux des choix.
Pour Egit, as tu essayé le merge quand ta branche locale n'est pas fast-forward? il te fais un compare sur chacun de tes commits locaux ce qui rend le tout complétement illisible. De même pour les menus dispos, Pas de stash, le rebase n'a pas -i par défaut, le compare pourrait être aussi bien que celui de subversion (montrant les portions de codes en diff plutôt que >>>>>>>>>>>>>>> et <<<<<<<<).
Niveau architecture maintenant, Eclipse utilise un tas de concepts erronés (require-bundle au lieu d'import package, des bundle singletons partout, des point d'extenson 'proprio' plutôt que d'utiliser le mechanisme de services OSGI), ce qui casse toute la modularité du framework, et fait une très mauvaise pub à OSGI (combien de fois j'ai essayé de vendre OSGI et ai eu comme réponse "alors pourquoi je dois rebooter après avoir installé un plugin?"), P2 n'est respecte pas OBR, le provisioning avec un bundle.info...
Niveau communauté, la plupart des sources sont encore sous CVS et les projets sous git sont hébergé chez Eclipse, ce qui nuit vraiment à la visibilité (quand on arrive à trouver les sources on est content), force à accepter le CLA, nuit à l'évolution de l'ensemble (je n'ai pas trouvé de bouton 'fork on Eclipse' sur les repos).
Je n'ai fait que critiquer ici, mais cet IDE reste à mes yeux le meilleurs et le restera longtemps de part sont ouverture et sa communauté. Il a un tas de points positifs et s'améliore à chaque nouvelles version. bref, je ne le changerai pour aucun autre pour faire du dév (Java tout du moins).
Pour info, je bosse dans l'ecosystème Eclipse, je maintiens pas mal de plugins, en code d'autres qui y seront intégrés.
Bonsoir,
Tu peux déja installer via l'update site d'AngularJS Eclipse ou le marketplace d'AngularJS Eclipse. JBoss tools est en train d'intégrer AngularJS Eclipse. Je te conseille de commencer par le Getting Started.Pour Jsdt, la complétion est là quand es variables appartiennent au même fichier, ce qui est un peu limité (surtout quand on fait du Angular). J'attends la sortie des JBoss tools nouvelle version avec Tern et consorts pour réviser mon jugement mais pour l'instant force est de constater qu'Intellij est nettement au dessus.
Le plugin tern angular commence a bien fonctionner, mais il n'est pas parfait (n'hesites pas à créer des issues). Comme AngularJS Eclipse est basé sur tern tu peux bénéficier aussi du support jQuery par exemple ou d'autres frameworks (YUI, Dojo, ExtJS, CKEditor, Closure, etc, voir la liste des frameworks JS supportés)
J'espère que ca te plaira, mais je tiens à dire que ca n'est pas fini, il y a encore un tas de chose à mettre en place. Je fais ca sur mon temps libre donc ca avance doucement (merci à JBoss pour leur contributions!)
Angelo
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager