Chaque membre d'une équipe doit-il utiliser le même IDE? [fermé]

Pensez-vous qu'il est logique d'imposer que chaque membre d'une équipe doit utiliser le même IDE?

Par exemple, tous les ingénieurs qui font déjà partie de l'équipe utilisent IDE X. Deux nouveaux ingénieurs viennent et veulent utiliser IDE Y à la place parce que c'est ce qu'ils utilisent depuis plusieurs années maintenant.

Avez-vous une expérience avec des équipes "IDE mixtes"? Si oui, c'est quoi?

À condition que le système de construction `` officiel '' (tel qu'utilisé par les serveurs de construction continue) soit le même pour tous, je ne vois aucune raison pour laquelle chaque membre de l'équipe ne pourrait pas choisir les outils qu'il veut ...

Si votre équipe s'appuie sur certains plugins disponibles uniquement pour certains IDE, cela n'a de sens que d'unifier tout le monde sous la même plateforme de développement. Je trouve également plus facile d'aider quelqu'un avec un problème de développement s'il a le même IDE que moi, alors que si je lis l'écran de quelqu'un avec une interface inconnue, cela prendra un peu plus de temps.

Un inconvénient est que lors du couplage, vous ne pouvez pas échanger le clavier entre vous aussi couramment. Entre les IDE traditionnels, ce n'est probablement pas un problème énorme, mais si une personne est habituée à Eclipse tandis que l'autre est utilisée pour vim, il y aura un décalage. L'utilisateur Eclipse peut très bien ne pas être en mesure d'utiliser vim, tandis que l'utilisateur vim (c'est moi;) passe beaucoup de temps à maudire à la lenteur horrible de l'utilisation d'Eclipse vanille.

Cela dit, je préfère toujours utiliser vim moi-même. À condition que votre paire soit contente qu'un seul d'entre vous "conduise" pendant de longues périodes, cela fonctionne bien.

Et je sais qu'il existe des plugins pour faire fonctionner Eclipse comme vi, mais je parle d'appairage où je vais m'asseoir avec quelqu'un qui fait fonctionner Eclipse comme il l'aime, donc il n'installera pas ce plugin.

Cela n'aurait aucun sens de forcer tous les développeurs du noyau Linux à utiliser le même IDE (ou à utiliser n'importe quel IDE).

Je n'ai pas d'expérience avec des IDE mixtes, sauf si vous comptez un IDE commercial avec des compléments occasionnels par un éditeur de texte "plusieurs IDE", mais je peux penser à quelques avantages et inconvénients.

Avantages

• Chaque développeur peut être plus productif avec ce qu'il sait le mieux
• Certains IDE peuvent offrir un avantage sur les autres (l'un pourrait être meilleur pour la refactorisation, un autre pourrait être meilleur pour fournir des aides au codage, d'autres pourraient être meilleurs pour l'intégration des données, peu importe). L'utilisation d'un mélange pourrait permettre à votre équipe d'en tirer parti.
• Vous aurez un peu de couverture contre la possibilité que l'un des IDE disparaisse.

Les inconvénients

• Problèmes de licence. S'il y a plusieurs IDE commerciaux impliqués, c'est peut-être plus cher. À tout le moins, il pourrait être plus important de garder une trace de.
• Problèmes de licence 2. S'il existe des frameworks ou des plug-ins sous licence par IDE ou langauge, est-ce que ce sera un problème?
• Comme Dszordan l'a mentionné, certains plug-ins peuvent ne pas être compatibles avec les différents IDE.
• Si les IDE ont des composants de génération de code ou des moteurs de formatage de style qui font les choses différemment, cela peut provoquer une certaine confusion.

Il y a une raison pour laquelle cela peut être forcé. Considérez simplement Visual Studio et Emacs / Vim. Comme sous Windows, Visual Studio ajoutera un \ r supplémentaire à la fin de la ligne. Cela gâche l'affichage dans emacs / vim. Les onglets créent également un problème. Le problème avec nous, c'est que nous, les développeurs, travaillons sous Linux, mais notre architecture logicielle est confortable dans Visual Studio. Il nous maudit une fois en disant que nous ne formaterons pas le fichier correctement. Mais quand il a découvert que c'était à cause du problème de réglage par défaut, nous avons tous accepté le même format.
Si quelqu'un me force à utiliser un IDE particulier, je ne me sentirai pas mal. Tout ce qui est bon pour l'équipe, je respecterai cela et je compromettrai en conséquence.

Le développeur d'aujourd'hui souhaite choisir ses propres outils.

Mais cela a changé avec le temps. Il y a 10 ou 15 ans, il n'y avait pas autant de choix dans les endroits où je travaillais. (oui, il y avait beaucoup de rédacteurs mais ce n'était pas un «choix»). La boutique dans laquelle je travaillais il y a 15 ans était très "old school" (même alors!) Et vi était l'éditeur. Pas le choix. C'était en fait assez utile, car après le premier mois de bavardages et de jurons, j'ai vraiment aimé ça.

Aujourd'hui, les choix sont nombreux et chacun présente de nombreux avantages.

Dans mon expérience personnelle, j'ai utilisé un IDE - rubyMine - pendant quelques années avant de revenir en vi (m). J'ai fait cela parce que Ruby est un langage très difficile à écrire pour un IDE (typage de canard et autres fonctionnalités dynamiques) et, par conséquent, les IDE ont tendance à être lents et / ou nécessitent la dernière machine la plus rapide.

Eh bien oui, j'ai une certaine expérience en ce qui concerne le fait de faire partie de l'équipe mixte windows / unix & c ++ / java. Je pense que ce n'est pas un problème à condition que tout le monde soit à l'aise de travailler avec l'autre IDE ou qu'il n'y ait jamais de situation où quelqu'un qui ne connaît pas IDE Y doit travailler sur l'autre gars (c'est le gars avec IDE Y ) système.

Si tout le monde le veut, c'est bien, mais différentes personnes peuvent vouloir utiliser différents éditeurs / IDE. Je ne voudrais pas vraiment que les gens me forcent à utiliser un éditeur autre que mon préféré si je travaillais sur quelque chose de grand avec une équipe, et je doute que je sois seul. Les gens peuvent être plus satisfaits de la situation si vous ne les forcez pas à utiliser un éditeur particulier.

BTW, Emacs!

Je ne pense pas que tout le monde doive avoir le "même" IDE, mais ce serait bien que tout le monde ait un IDE "supporté".

Par exemple, si votre IDE est intégré dans le processus de révision du code en ce qui concerne les commentaires et la mise à jour du code, il serait logique que tout le monde soit sur une plate-forme prise en charge.

Si votre entreprise utilise un environnement collaboratif tel que Rational Team Concert et qu'un ou deux gars veulent utiliser un IDE non pris en charge (ou une version différente) tandis que tout le monde en utilise des compatibles, la vie peut être difficile pour les personnes qui ont choisi d'être en dehors de la boucle de support.

Chez nous, nous construisons nos projets à l'aide de Visual Studio. En ce qui concerne l'édition de texte, je passe à Emacs. Votre entreprise ne devrait pas s'en soucier tant que le travail est terminé.

Cela ressemble un peu à "nous l'avons utilisé dans mon ancien travail". Eh bien, ils ne sont pas à leur ancien travail.

Si cela n'affecte pas votre chaîne d'outils ou vos plugins de contrôle de source, alors peut-être que oui. Là encore, les deux nouvelles personnes peuvent-elles démontrer un avantage clair? Ont-ils utilisé votre IDE?

Sinon, je n'ai aucune patience avec ce non-sens, sauf s'il y a de bonnes raisons pour cela. Ils ne sont pas à leur ancien emploi: ça ne pouvait pas être si bon pour eux de vouloir partir. L'utilisation de l'autre IDE était le seul point fort de leur ancien travail: dans l'affirmative, ils devraient STFU et être reconnaissants ..

OUI! Appliquez l'IDE singleton.

Cela pose des problèmes lorsque la dépendance du projet change. si l'on introduit une nouvelle dépendance au projet, chacun perdra du temps pour introduire cette nouvelle dépendance, et certains pourraient échouer et perdre du temps sur ce processus. ÉNORME PERTE DE TEMPS.

il devrait y avoir une VRAIMENT bonne justification pour ajouter un IDE différent à l'équipe, ce qui signifie que le temps économisé devrait dépasser le temps consacré à la migration du système vers différents IDE