¿Debería cada miembro de un equipo usar el mismo IDE? [cerrado]

¿Crees que tiene sentido hacer cumplir que todos los miembros de un equipo deben usar el mismo IDE?

Por ejemplo, todos los ingenieros que ya están en el equipo usan IDE X. Dos nuevos ingenieros vienen y quieren usar IDE Y porque eso es lo que han estado usando durante varios años.

¿Tienes alguna experiencia con equipos de "IDE mixto"? Si es así, ¿qué es?

Siempre que el sistema de compilación 'oficial' (como lo usan los servidores de compilación continua) sea el mismo para todos, no veo ninguna razón por la cual cada miembro del equipo no pueda elegir las herramientas que desea ...

Si su equipo confía en ciertos complementos disponibles solo para ciertos IDE, entonces tiene sentido unificar a todos bajo la misma plataforma de desarrollo. También me resulta más fácil ayudar a alguien con un problema de desarrollo si tienen el mismo IDE que yo, mientras que si voy a leer la pantalla de alguien con una interfaz desconocida, tardaré un poco más.

Una desventaja es que cuando se empareja no se puede cambiar el teclado entre ustedes con tanta fluidez. Entre los IDE convencionales, esto probablemente no sea un gran problema, pero si una persona está acostumbrada a Eclipse mientras que la otra está acostumbrada a vim, habrá una falta de coincidencia. El usuario de Eclipse puede ser completamente incapaz de usar vim, mientras que el usuario de vim (ese soy yo) pasa mucho tiempo maldiciendo por lo bajo ante la horrible lentitud de usar Eclipse de vainilla.

Dicho esto, todavía preferiría usar vim yo mismo. Siempre que su pareja esté contenta con que solo uno de ustedes "conduzca" durante períodos prolongados, funciona bien.

Y sé que hay complementos para hacer que Eclipse funcione como vi, pero estoy hablando de emparejar donde voy y sentarme con alguien que tiene Eclipse trabajando como les gusta, por lo que no instalarán ese complemento.

No tendría ningún sentido obligar a todos los desarrolladores del kernel de Linux a usar el mismo IDE (o usar cualquier IDE).

No tengo experiencia con IDE mixtos, a menos que cuente un IDE comercial con el complemento ocasional de un editor de texto "IDE múltiples", pero puedo pensar en un par de pros y contras.

Pros

• Cada desarrollador puede ser más productivo con lo que mejor sabe
• Algunos IDE pueden proporcionar una ventaja sobre otros (uno podría ser mejor refactorizando, otro podría ser mejor proporcionando ayudas de codificación, otros podrían ser mejores con la integración de datos, lo que sea). El uso de una combinación podría permitirle a su equipo sacar provecho de eso.
• Tendrás un poco de cobertura contra la posibilidad de que uno de los IDE desaparezca.

Contras

• Problemas de licencia. Si hay varios IDE comerciales involucrados, tal vez sea más costoso. Por lo menos, podría ser más fácil de seguir.
• Problemas de licencia 2. Si hay marcos o complementos con licencia IDE o langauge, ¿será esto un problema?
• Como mencionó Dszordan, ciertos complementos pueden no ser compatibles con los diferentes IDE.
• Si los IDE tienen componentes de generación de código o motores de formato de estilo que hacen las cosas de manera diferente, esto podría causar cierta confusión.

Hay una razón por la cual esto puede ser forzado. Simplemente considere Visual Studio y emacs / vim. Al igual que en Windows, Visual Studio agregará un \ r adicional al final de la línea. Esto se equivoca con la pantalla en emacs / vim. También las pestañas crean problemas. El problema con nosotros es que los desarrolladores trabajamos en Linux, pero nuestra arquitectura de software es cómoda en Visual Studio. Una vez nos maldice diciendo que no formateamos el archivo correctamente. Pero luego, cuando descubrió que esto se debía al problema de configuración predeterminada, todos acordamos el mismo formato.
Si alguien me obliga a usar un IDE particular, no me sentiré mal. Lo que sea bueno para el equipo lo respetaré y comprometeré en consecuencia.

El desarrollador de hoy quiere elegir sus propias herramientas.

Sin embargo, esto ha cambiado con el tiempo. Hace 10 o 15 años no había tantas opciones en los lugares donde trabajé. (Sí, había muchos editores, pero no eran una "elección"). La tienda en la que trabajaba hace 15 años era muy 'vieja escuela' (¡incluso entonces!) Y vi era el editor. Sin elección. En realidad, esto fue bastante útil, porque después del primer mes de maldecir y maldecir, realmente me gustó.

Hoy en día, hay muchas opciones y cada una tiene muchas ventajas.

En mi experiencia personal, utilicé un IDE, rubyMine, durante un par de años antes de cambiar 'volver' a vi (m). Hice esto porque Ruby es un lenguaje muy difícil para escribir un IDE (tipo de pato y otras características dinámicas) y, como resultado, los IDE tienden a ser lentos y / o requieren la última y más rápida máquina.

Bueno, sí, tengo algo de experiencia en lo que respecta a ser parte del equipo mixto windows / unix & c ++ / java. Creo que esto no es un problema siempre y cuando todos se sientan cómodos trabajando con el otro IDE o nunca habrá una situación en la que alguien que no esté familiarizado con IDE Y necesite trabajar en el otro tipo (ese es el tipo con IDE Y ) sistema.

Si todos quieren, está bien, pero diferentes personas pueden querer usar diferentes editores / IDE. Realmente no quisiera que la gente me obligue a usar un editor que no sea mi preferido si estuviera trabajando en algo grande con un equipo, y dudo que esté solo. Las personas pueden estar más contentas con la situación si no las obligas a usar un editor en particular.

Por cierto, Emacs!

No creo que todos necesiten tener el "mismo" IDE, pero sería bueno que todos tuvieran un IDE "compatible".

Por ejemplo, si su IDE está integrado en el proceso de revisión del código en lo que respecta a comentar y actualizar el código, entonces tendría sentido que todos estén en una plataforma compatible.

Si su empresa está utilizando un entorno de colaboración como Rational Team Concert y uno o dos tipos quieren usar un IDE no compatible (o una versión diferente) mientras que todos los demás usan compatibles, entonces la vida puede ser difícil para las personas que han elegido ser fuera del bucle de soporte.

En nuestro lugar construimos nuestros proyectos usando Visual Studio. Cuando se trata de editar texto, cambio a Emacs. Su empresa no debería preocuparse mientras el trabajo esté hecho.

Suena un poco como "usamos esto en mi antiguo trabajo". Bueno, no están en su antiguo trabajo.

Si no afecta su cadena de herramientas o plug.ins de control de fuente, entonces tal vez sí. Por otra parte, ¿pueden las dos nuevas personas demostrar un beneficio claro? ¿Han usado tu IDE?

De lo contrario, no tengo paciencia con estas tonterías a menos que haya un buen caso para ello. No están en su antiguo trabajo: no podría haber sido tan bueno para ellos querer irse. Estaba usando el otro IDE el único punto culminante en su antiguo trabajo: si es así, deberían STFU y estar agradecidos.

¡SÍ! Hacer cumplir el IDE singleton.

Crea problemas cuando cambia la dependencia del proyecto. si uno introduce una nueva dependencia al proyecto, todos perderán tiempo para introducir esa nueva dependencia, y algunos podrían fallar y perder tiempo en ese proceso. Enorme pérdida de tiempo.

debería haber una REALMENTE buena justificación para agregar un IDE diferente al equipo, lo que significa que el tiempo ahorrado debería superar el tiempo dedicado a migrar el sistema a diferentes IDE