¿Es una orden de la compañía cambiar a cierto IDE una bandera roja? [cerrado]

80

Recientemente me uní a una startup de rápido crecimiento. En los últimos 3 meses, el equipo de desarrollo ha crecido de 4 a 12. Hasta ahora, eran muy laissez-faire sobre lo que los desarrolladores solían hacer su trabajo. De hecho, una de las cosas que inicialmente encontré atractivas sobre la compañía es que la mayoría de los programadores usaban Linux, o cualquier sistema operativo que consideraran más adecuado para sus esfuerzos.

Ahora las órdenes, sin discusión, han bajado de que todos deben cambiar a Eclipse. Un buen editor. Prefiero SublimeText2, pero es solo mi gusto personal.

Para que quede claro: somos un equipo de JS que usa Backbone y Eclipse simplemente no es bueno para comprender el código de Backbone. Esto significa que aquellos en el equipo que usan un / good / IDE (PHP Storm), tienen que volver a hacer muchas cosas de buscar-encontrar-oh-esperar-donde-estaba-yo-tres-hace-hace-tres-pasos en lugar de simplemente presionar Ctrl + hacer clic y usar atrás / adelante, probablemente disminuya la productividad en un 15% y disfrute en un 50% ...

¿Es esta una bandera roja? Parece caprichoso e irrazonablemente controlado decirle a los desarrolladores (no MS) qué IDE o conjuntos de herramientas usar si ya están instalados y son productivos.

Justin Alexander
fuente
77
¿Cuál es tu proceso de construcción? Lo que debe existir para que los caracteres que escriba se conviertan en código binario para los clientes.
22
Esta es una puesta en marcha. Si la gerencia toma unilateralmente una decisión como afectar el desarrollo, sin discusión, podría ser una gran señal de alerta independientemente de lo que se trate.
joshin4colours
29
No, hay una infinidad de razones para ir a un solo IDE: licencia, proceso, continuidad, coherencia ...
Wonko the Sane
55
¡Una compañía en crecimiento que trata de establecer un estándar desde el principio es inteligente en mi libro (no importa lo que sea)! Ponga a todos en la misma página y acumule experiencia con un IDE común. Luego, el equipo se vuelve más eficiente porque todos pueden ayudarse entre sí y pueden compartir código más fácilmente sin tener que preocuparse por el ancho del espacio de tabulación, la codificación y cosas por el estilo.
Yanick Girouard
23
Eclipse es un entorno completo, no solo un editor. Tal vez TI descubrió que tratar con cada copo de nieve especial en una empresa en crecimiento se estaba convirtiendo en una tarea enorme y onerosa y quería estandarizar. Tal vez haya una herramienta en la gestión del ecosistema Eclipse que quiera usar pronto. Tal vez 12 editores de formateo automático diferentes estaban cabreando su repositorio y causando compilaciones adicionales. Posiblemente las herramientas sin licencia "desde casa" preocupan a los administradores que no quieren ser demandados. Tal vez eres el chico nuevo, ¿realmente esperas ser consultado sobre decisiones amplias de TI y desarrollo? Podría ser un millón de razones, todo cuerdo.
Patrick Hughes

Respuestas:

92

"Ahora las órdenes, sin discusión , han bajado de que todos deben cambiar a Eclipse".

Creo que esta es la verdadera bandera roja. ¿Su equipo es el experto en desarrollo de software y el que se verá afectado por la decisión, y aún así no pudo decir una palabra en la discusión que dio lugar a este orden?

Suena como un exceso de gestión por parte de jefes de pelo puntiagudo. ¿La persona / equipo que toma decisiones tiene información relevante para esa decisión?


Dado que los tomadores de decisiones están lo suficientemente calificados para tal decisión, no pedir la opinión del equipo de desarrollo tiene al menos dos deficiencias:

  • El equipo no se siente involucrado. Involucrar al equipo debería ser una prioridad para la gerencia. No me gustaría trabajar como desarrollador en algún lugar donde mi opinión sobre temas tan centrales como IDE no sea lo suficientemente valorada como para ser solicitada. Es cierto que pedir la opinión de alguien y luego decidir en contra puede ser peor, pero en ese caso esperaría una razón sólida para esa decisión.

  • La administración, sin embargo con experiencia, no funciona al 100% con el desarrollo de este código específico. Suponiendo que las personas que no tienen una idea interesante serían ingenuas. Por supuesto, puede ser que los gerentes hayan pensado en todo lo que se les ocurre a los desarrolladores, pero la única forma de saberlo es preguntar.

Gauthier
fuente
99
Disparates. El hecho de que el equipo no haya sido consultado no significa que los superiores no tengan ni idea. Es interesante como desarrollador que no es Java, sé que Eclipse es el IDE que se usa más o menos, pero nunca escuché sobre el OP favorito hasta que lo publicó. Sería un error permitir que el equipo se estandarice en un IDE que es poco común, creando problemas con el reclutamiento de otros nuevos desarrolladores.
Andy
55
¿Has considerado que la "alta gerencia" puede ser desarrolladores senior? Algunas organizaciones tienen muchas capas?
2
Estás leyendo demasiado en esto. La administración puede tener otras inquietudes, como opciones de soporte, y puede haberse reducido a algo que era bastante popular con un costo de soporte razonable (estoy hablando de incidentes de soporte pagado). Si ese es el caso, puede que no haya habido otra opción, entonces, ¿qué sentido tendría preguntar a los desarrolladores? Además, ¿ha intentado que incluso un pequeño número (10-15) de desarrolladores estén de acuerdo en algo? Hay una razón por la que dicen que lograr que los desarrolladores estén de acuerdo es como acumular gatos.
Andy
3
@Andy Hoarding cats es fácil (habla con cualquier solterona), escucharlos es algo completamente diferente. ; o)
JW01
3
@ JW01 Ahh, me equivoqué de palabra. ¿Pero no sería pastoreo? :-)
Andy
63

Es razonable que cuando trabajen juntos en un proyecto común, que en cada estación de trabajo tenga todas las herramientas disponibles para editar / construir / depurar su software, y que las herramientas centrales para hacer aproximadamente el 90% del desarrollo sean conocidas por todos en el equipo. Esa meta es más difícil de alcanzar si su equipo está creciendo y todos usan su conjunto de herramientas favorito personal: cuantas más personas, más opiniones. Y el trabajo administrativo también se hace más fácil si no permite que la cantidad de herramientas crezca más de lo necesario.

Por supuesto, si un desarrollador insiste en usar su editor favorito personal, puede estar bien siempre y cuando pueda asegurarse de que la fuente no se vea o se comporte de manera diferente en el editor principal del equipo (en su caso Eclipse), entonces si dev B tiene que editar la fuente del desarrollador A, el desarrollador B no debería verse obligado a aprender el editor favorito personal de A para poder cambiar la fuente de manera efectiva. Pero cuidado, si los dos tienen que trabajar juntos de vez en cuando frente a la misma pantalla (o hacer un par de programación), las cosas a menudo son más fáciles si el editor elegido es conocido por ambos.

Doc Brown
fuente
2
En primer lugar, es raro que un desarrollador tenga que hacer cambios en la máquina de otra persona. Estoy de acuerdo con "cuantas más personas, más opiniones", pero eso no es un problema a menos que las personas traten de imponer opiniones a los demás. En cuanto a la fuente, todos los proyectos deben tener un proceso de compilación automático de un comando. Mientras eso funcione, y el código siga las convenciones, no importa qué personas IDE estén usando. La mayoría de los IDE son intuitivos para cosas simples (cada uno tiene sus propios beneficios para tareas más complejas), por lo que la programación de pares no es un problema. Si hay preguntas, el desarrollador que usa el IDE puede responder.
Matthew Flaschen
Si ambos conocen el idioma, mirar un editor diferente realmente no es un problema. Parte de la sintaxis se resalta de manera diferente y el nombre del archivo puede estar en un lugar diferente, pero no hay problema a menos que esté utilizando la configuración de otro desarrollador.
Izkata
30
Trabajo en google y en mi equipo en particular una persona usa Eclipse en persona usa intellij Yo uso Emacs con modo malvado para emular a Vim y una persona usa Vim en sí. Trabajamos bien entre nosotros y las diferencias de herramientas no son un problema. Ayuda que todos usemos el mismo sistema de compilación y tengamos una guía de estilo establecida para leer el código, pero eso tiene poco que ver con la elección del editor para cada individuo.
Jeremy Wall
@JeremyWall: como dije, puede estar bien, si tu código fuente se muestra por igual en todos los editores que estás usando y no haces mucha programación de pares.
Doc Brown
55
@JeremyWall: El hecho de que su equipo de desarrolladores pueda trabajar así, no significa que todos los equipos puedan trabajar de esa manera, y de hecho, consideraría que un equipo de desarrolladores de Google está fuera de la norma.
James P. Wright
25

Por el bien de la programación de pares, es bueno que ambas partes enfrente de la pantalla tengan las mismas habilidades cuando usan el teclado. También es bueno saber que, si su proyecto tiene necesidades especiales de configuración en el IDE, entonces está configurado de la misma manera para todos. Iniciar un nuevo desarrollador es más fácil cuando las herramientas son las mismas para todos.

Pero si lo comparas con solo tratar de ser más efectivo, entonces realmente no vale la pena

Espen Schulstad
fuente
77
+1 por notar el beneficio de entornos de desarrollo similares cuando se programa la pareja
jcmeloni
1
+1. No podría estar mas de acuerdo. ¡Trabajar con múltiples desarrolladores, cada uno con sus propias herramientas preferidas y formas de codificación, puede ser un infierno! Por ejemplo, es posible que desee aplicar espacio sobre pestañas, un tamaño de sangría específico y codificación UTF-8 para todas sus fuentes. Tuve que pasar por esto en mi equipo antes y tuvimos que hacer que todos usaran el mismo IDE al final exactamente por las razones mencionadas anteriormente. Cualquier desarrollador serio no tendría que pasar mucho tiempo para adaptarse a un nuevo IDE de todos modos, por lo que no veo el daño en él. También hace que sea más fácil para los nuevos miembros ponerse al día si todos usan la misma herramienta.
Yanick Girouard
@Yanick: Espacio sobre pestañas, tamaño de sangría, codificación ... Todos estos tipos de parámetros deben vivir en el estándar de codificación, que todos los desarrolladores deben cumplir. No importa cómo quieren cumplir con ellos, ¿verdad? Los requisitos de formato deben centrarse en que el resultado sea correcto, no en cómo llegar allí. Si los desarrolladores necesitan cambiar IDE para obtener el formato correcto, entonces no los llamaría "desarrolladores serios", perdón por ser audaces.
Gauthier
18

Sí, es una señal de alerta que la gerencia se considera un mejor juez de las herramientas con las que sería más eficiente de lo que es.

mate b
fuente
38
Depende en gran medida de las razones por las cuales el IDE debería ser el mismo.
3
No estamos seguros de la pregunta de quién tomó la decisión o por qué. El término "sin discusión" podría significar que no incluyeron al nuevo tipo.
mhoran_psprep
3
No tengo el representante para votar en contra, pero no estoy de acuerdo con esta perspectiva. Incluso si la herramienta decretado por la administración eran , de hecho, no es la mejor, sería mejor que no tener ningún tipo de estandarización. Claramente, los desarrolladores no son capaces de tomar la decisión sobre cuál es el "mejor", ya que dejados en sus propios dispositivos, todos han elegido diferentes herramientas. Es fatigoso afirmar que diferentes herramientas funcionan mejor en diferentes contextos, ya que la mayoría de esos desarrolladores no dominarán muchos de todos modos.
FumbleFingers
44
"Claramente, los desarrolladores no son capaces de tomar la decisión sobre cuál es el" mejor ", ya que dejados a sus propios dispositivos, todos han elegido diferentes herramientas" Están eligiendo la mejor herramienta (más productiva) para ellos . Todos tienen diferentes experiencias y patrones de trabajo. Todos pueden estar en lo cierto.
Matthew Flaschen
2
@Andy Eso no es realmente cierto, como lo demuestran los desacuerdos de Vim vs Emacs. Y esos son principalmente editores de texto, no IDEs completos. Puede llevar años ponerse al día en un nuevo entorno.
Izkata
14

No es una bandera roja en sí misma.

A veces la gerencia necesita tomar decisiones . Cualquier problema que requiera estandarización en algo tiende a caer en esa categoría. Una vez trabajé en un cliente que había permitido que los estándares cambiaran durante algunos años y tenían más de 20 herramientas SCM diferentes. Lo que comenzó como una elección independiente de diferentes equipos de desarrollo se convirtió en una pesadilla logística que obstaculizó severamente el intercambio de habilidades y la colaboración en el código en toda la organización. La construcción integrada era ..... er ..... no muy integrada .....

Además, no es práctico ni necesario consultar a todos para cada decisión . La medida en que esto debe hacerse depende de la cultura de la organización y la importancia / complejidad de la decisión. Por lo general, tomaría una de estas opciones menos consultadas:

  1. Tome la decisión usted mismo, si tiene suficiente conocimiento de los pros / contras y no es una decisión lo suficientemente importante como para requerir una consulta amplia.
  2. Consulte con algunas personas clave (quienes probablemente serían los desarrolladores senior más calificados para tomar la decisión).
  3. Explique el hecho de que está tomando una decisión con todos los que puedan verse afectados (correo electrónico, reunión del ayuntamiento, reuniones de equipo). Di cuál crees que es la decisión correcta, pero estás dispuesto a cambiar esto si surgen nuevas pruebas de lo contrario. Invite a las personas a presentarse individualmente si tienen puntos de vista importantes
  4. Invite a las personas a formar un sub-equipo para revisar las opciones y recomendar una decisión. Buena opción si realmente es una llamada cercana, no sabe la respuesta y desea que los involucrados se involucren en la decisión.

Para algo como herramientas para desarrolladores (que es un problema potencialmente polémico), probablemente haría 2 seguido de 3 o 4. es decir, definitivamente habría algunas personas con las que no hablaría personalmente sobre el tema, pero por otro lado, la mayoría de las personas clave tendrían la oportunidad de contribuir a la toma de decisiones.

Para mí, la verdadera bandera roja estaría presente si usted cree firmemente que se ha tomado la decisión incorrecta (incorrecto == perjudica a la empresa en lugar de que simplemente no se elija su herramienta favorita). ¿Cómo reacciona la gerencia cuando plantea este problema?

  • La buena administración escuchará su argumento, le agradeceremos sinceramente sus comentarios y reconsiderará su posición en caso de que haya planteado nuevas ideas . Es posible que aún no estén de acuerdo con usted y que se apeguen a su decisión, pero apreciarán que lo haya mencionado con ellos y le harán la cortesía de decir por qué se apegan a su decisión. Incluso podrían cambiar la forma en que toman tales decisiones en el futuro, y si hizo buenos comentarios, puede incluirlo en su lista de "personas inteligentes para preguntar".
  • La mala gestión se pondrá a la defensiva, diga que "se toma la decisión" y otras tácticas para evitar enfrentar el hecho de que pueden haber tomado una decisión equivocada. Pueden verte como un "alborotador". La empresa sufre, al igual que su fe en la administración. Esta es una verdadera bandera roja! ¡Sal mientras puedas!
revs mikera
fuente
66
Hay una gran diferencia entre un ide / editor y un scm o sistema de compilación. e ide / editor es para uso personal y generalmente se adapta al individuo. El sistema scm o build es utilizado globalmente por todos. Una de estas cosas necesita una gestión centralizada y la otra definitivamente no.
Jeremy Wall
2
Mi respuesta se centró en los problemas de gestión en lugar de la decisión específica sobre IDE per se. Sin embargo, también hay muchas buenas razones para estandarizar un IDE (por ejemplo, habilidades, capacitación, costos de licencia, eficiencia de programación de pares, integración con otras herramientas, calidad general del IDE, costos de soporte, facilidad de implementación). En algunos contextos, la decisión correcta será estandarizar: usted es incorrecto si cree que esto siempre se puede dejar a elección individual (incluso si esta es la decisión correcta en muchas situaciones)
mikera
2
@Jeremy: Creo que tu perspectiva está perfectamente bien para una banda de un solo hombre o un pequeño grupo de hackers. Simpatizo fuertemente: soy exactamente igual para mis proyectos personales. Pero ese enfoque simplemente no se adapta a contextos empresariales más grandes. Tener preferencia por las herramientas está bien, pero espero que un buen desarrollador profesional esté dispuesto y sea capaz de aprender y adoptar cualquier herramienta que haga que la organización sea más efectiva en su conjunto.
mikera
3
Mi empleador, Google, comparte mi perspectiva y ciertamente califica como un contexto empresarial más amplio. Estoy de acuerdo en que un buen desarrollador profesional debería estar dispuesto a aprender y adoptar herramientas para hacer que la organización sea más efectiva en su conjunto. No estoy de acuerdo con que un ide o editor pueda entrar en esa categoría.
Jeremy Wall
2
Genial, excelente compañía y tienes la suerte de trabajar en un lugar que puede operar como muchos "pequeños grupos de hackers" en proyectos relativamente independientes. Lamentablemente, la mayoría de las grandes empresas no tienen ese lujo. Piense en un gran banco que necesita contratar y capacitar a 100 codificadores Java de nivel de entrada en la India para trabajar en el mantenimiento de aplicaciones de centro de llamadas. Animarlos a todos a ser creativos y elegir su propio flujo de trabajo IDE / build simplemente no va a funcionar.
mikera
12

Si está utilizando Maven o algo similar, no debería importar qué IDE esté utilizando. Puede haber casos en los que uno está vinculado a un IDE específico como eclipse, si hay complementos en los que confía.

Creo que debería poder elegir su propio IDE, el IDE en el que es más productivo. Sin embargo, como ya dije, hay casos en los que tiene sentido usar un IDE estándar.

Jarle Hansen
fuente
p.ej. si quieres hacer ADF, entonces JDeveloper es la opción natural, los complementos para otras ides pueden no tener toda la funcionalidad.
Rohit Banga
11

Instalaría el IDE "obligatorio por mandato", pero seguiría haciendo la mayor parte de mi trabajo en el IDE que quisiera; no es como si alguien pudiera decir qué IDE se utilizó para editar un archivo fuente.

En el IDE vs frontal editor ... para casi todos los idiomas, me fuertemente prefiero un IDE (IntelliJ) porque sólo hay mucho más que puede hacer por usted que una lata editor. Hay algunas cosas por las que vuelvo a ST2 o Emacs, pero para la codificación diaria, a pesar de lo mucho que me gustan tanto ST2 / Emacs, el IDE casi siempre gana.

Dave Newton
fuente
1
Discuto su afirmación de que un IDE puede hacer mucho más que un editor. Hay editores claramente inferiores, por ejemplo, no haría un desarrollo serio con nano o gedit, pero puedo codificar más rápido en vim que yo, y supongo que la mayoría de los demás pueden hacerlo en un IDE. Y aunque odio defender emacs, estoy seguro de que un usuario experimentado de emacs también es más rápido en emacs que un IDE.
Kevin
1
@Kevin Dispute away - Soy un usuario de Emacs desde hace mucho tiempo, y estoy mejorando con ST2, y simplemente no hay comparación. Mejor terminación, más sensible al contexto, integración de depuración más estricta, no hay demasiadas cosas por las que le diría a un editor de texto. A algunos lenguajes les va mejor que a otros, por ejemplo, no codificaría Java en Emacs sin importar lo que pase, para Ruby y Python estoy casi a la mitad, pero IntelliJ me está ganando. Para la edición de texto real, ya sea código o no, utilizo un editor.
Dave Newton
1
Conozco la pregunta y la mayoría de las respuestas están orientadas al mundo Java, pero aquí, en el mundo .NET de Microsoft, la idea de que un editor podría ser mejor que el IDE convencional (Visual Studio) se retrasa por completo. No contrataría a un desarrollador de .NET que insistiera en usar Notepad ++ sobre Visual Studio.
Graham
11

Todos los equipos en los que he estado han tenido una multiplicidad de IDE y editores: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine; nunca ha sido un problema. Nunca.

Para mí, esto habla de un malentendido en los altos niveles de la organización, en cuanto a lo que realmente importa. Lo importante es dejar que los buenos programadores hagan lo que tienen que hacer y utilicen las herramientas que los hacen sentir más cómodos. La uniformidad IDE tiene muy poco que ver con la comunicación real que tiene lugar sobre las cuestiones esenciales de la arquitectura de objetos, pruebas unitarias, algoritmos, etc.

Tener el mismo IDE que el siguiente tipo solo significa que ambos sabemos cómo explorar el código con los mismos accesos directos y cómo está configurada nuestra compilación / configuración. Nada de eso importará cuando se hable de problemas de código real.

Mira, es habitable, dependiendo de otros factores en la empresa. Siempre puedes usar tu propio editor preferido para las cosas del día a día. Y tal vez su grupo está haciendo otras grandes cosas que crean una gran cultura. Pero los IDE obligatorios son un gran paso en falso de la OMI. Para mí, si me estaban entrevistando con una empresa y me informaron IDE que estaba permitido usar, me gustaría darles las gracias amablemente por su tiempo.

Dave Sims
fuente
8

En nuestra tienda Ruby hay una fuerte recomendación para usar el IDE que disfruta la mayoría del equipo (RubyMine), porque sabemos que hace el trabajo y podemos enseñarnos atajos, etc.

Los desarrolladores son libres de usar un IDE diferente, pero les exigimos que tengan habilidades sólidas en ese editor si así lo desean. Si vemos a alguien luchando por navegar por su proyecto o editar texto en su FooEdit personalizado, RubyMine para ellos lo es.

triskweline
fuente
4

Si un programador es un experto en un IDE determinado, debe usarlo. Si no son expertos en ningún IDE, probablemente haya uno o dos que sean muy comunes para su lenguaje de programación o dentro de su equipo, y probablemente tenga sentido que lo aprendan.

Ser forzado a estandarizar en un IDE parece una idea terrible.

Matt Rogish
fuente
2

Deben examinarse las razones por las cuales una empresa obliga a un editor o software en particular a sus desarrolladores. La parte paranoica (quizás no la palabra que estoy buscando) de mí piensa que podría haber algún tipo de seguimiento de productividad agregado al eclipse que están pidiendo a los desarrolladores que instalen. Una idea mucho menos paranoica (de nuevo) sería que han pasado tiempo agregando herramientas de compilación de productos a este IDE que facilitaría mucho las cosas si todos presionaran el mismo botón para probar y construir su rama de código.

De todos modos, lo que estoy tratando de decir es que probablemente sea más que una simple burocracia, o un método para meterse con los jefes de los desarrolladores.

Pykler
fuente
2

Esta es una bandera roja masiva. Cada compañía tiene algunas ideas estúpidas, pero si siguen apareciendo otras banderas rojas, simplemente váyase.

taw
fuente
Discrepar. Muchas grandes empresas toman decisiones rápidamente, y si cometen un error, escuchen los comentarios y repitan. No pierden el tiempo empantanándose en consultas interminables para cada decisión.
mikera
2

Es fácil perder la motivación detrás de algunas decisiones, especialmente con un equipo en rápido crecimiento. La motivación para mudarse a Eclipse podría ser el hecho de que la mayoría de los desarrolladores parecen estar perdiendo mucho tiempo simplemente configurando el IDE y que solo hay una experiencia limitada dentro de su empresa.

Simplemente tomaría la orden de pasar a Eclipse para indicar que debe tener la configuración de Eclipse en caso de que sea necesario, pero continúe su trabajo en su editor favorito. (Es posible que deba mudarse a Eclipse gradualmente si su empresa comienza a implementar herramientas interesantes dentro de Eclipse).

Bandera Roja: Esperaría si hay algunas órdenes más irracionales antes de preocuparme.

revs Vineet
fuente
1

Una startup generalmente está tratando de mantenerse ágil el tiempo suficiente para descubrir un modelo de negocio sostenible. Una vez que se da cuenta de la parte del dinero, la gerencia se mueve para ampliar el negocio. Eso es generalmente cuando todos los primeros empleados tecnológicos comienzan a irse, a medida que los procesos de ingeniería se endurecen.

Como sabes, no sabes qué hará el código hasta que lo ejecutes. Turing lo demostró en los primeros días de la informática. Esto significa que no existe una medida significativa de productividad cuando se trata de escribir software. Sin embargo, para que la gerencia haga su trabajo, la productividad debe ser legible. Como no puede medir el código (y las personas lo han intentado, por ejemplo, líneas de código), medirán lo que pueden ver. Los programadores son más legibles que el software que desarrollan. El equipo de gestión típico intenta controlar a los programadores para que estas cosas sean legibles para ellos (en lugar de hacer su trabajo real: salir del camino). Y porque miden las cosas equivocadas, no funciona muy bien.

Habiendo dicho eso, aún puedes recorrer un largo camino con un equipo débilmente acoplado. El equipo de desarrollo de Github tiene alrededor de 50 personas y rompen todas las reglas en los libros de texto de gestión empresarial. Parecen estar bien. Los errores se arreglan (eventualmente). Las características se agregan. Los incendios se apagan.

Lo que es una gran bandera roja es si están tratando de ampliar las cosas sin haber descubierto cómo ganar dinero. En ese momento, debes preguntarte cuánto valen realmente tus opciones y subvenciones no invertidas.

Ho-Sheng Hsiao
fuente
Esto parece completamente ajeno a la pregunta. ¿Querías publicar en otro lugar?
Daenyth
@Daenyth, quiero publicar esto aquí. El título original "¿Un IDE para gobernarlos a todos?" no tuvo nada que ver con el párrafo explicativo. El OP parece estar preguntando si ser forzado a usar un IDE indica tiempo para rescatar a la compañía.
Ho-Sheng Hsiao
1

Seguramente esta es una mala idea. Es inevitable que el equipo sea menos productivo ya que tienen que aprender a usar nuevas herramientas. E incluso entonces no serán tan efectivos como con las herramientas que ya utilizan .

Como he probado varias herramientas, siempre tuve la sensación de "Dios mío, este editor me molesta con <insertar algún error / diferencia de la herramienta preferida>". Por lo tanto, también será un inconveniente moral.

Pero, por supuesto, también hay profesionales para que todo un equipo use las mismas herramientas. Compartir configuraciones, skripts, complementos y todo ese tipo de cosas. Lo que no sería posible con una diversidad de conjuntos de herramientas.

Por otro lado ... ese último bit no sería necesario si todos usaran su software preferido. ;)

noxoc
fuente
0

Puede "usar" Eclipse mientras sigue escribiendo SublimeText2.

Esto significa tener Eclipse instalado y configurado para sus proyectos y ponerse al día con él para que esté igualmente cómodo usándolo si, por ejemplo, empareja la programación. A nadie le importará (o al menos debería importarle) qué editor usó realmente para escribir un código que cometió, siempre que el mantenimiento de su configuración paralela no tome una cantidad indebida de tiempo y no se desconecte del entorno de desarrollo estándar

Tiberiu Ana
fuente
0

Si está usando Git y su ramificación está baja, no debería necesitar usar los editores de los demás de todos modos. Puede empujar una rama y hacer que otro desarrollador la tire para que funcione si realmente no puede entender su conjunto de herramientas. Forzar a todos a usar el mismo editor suena como una orden de un jefe de negocios que quiere parecer inteligente pero que realmente no entiende la forma en que operan.

tubbo
fuente
0

Si piensa en esto desde un punto de vista administrativo, la razón por la que pueden estar haciendo esto es para el cumplimiento legal. La empresa es responsable de garantizar que todas las herramientas utilizadas se utilicen legalmente y tampoco gravarán el producto que se está desarrollando. (Algunos editores son gratuitos para uso personal, pero no para otros fines, etc.) Auditar cada herramienta que cada desarrollador quiera usar puede ser costoso. He visto que en proyectos donde los plazos son ajustados, la administración será cautelosa acerca de qué herramientas / bibliotecas / etc. se utilizan para minimizar los cambios posteriores en el proyecto dirigidos por la gente legal.

En los proyectos de mayor seguridad también existe la preocupación de dónde almacenan los archivos IDE los archivos temporales y qué información se almacena entre sesiones.

SammyO
fuente
0

Todo depende de las razones por las que tienen que recomendar Eclipse. Si los desarrolladores tienen problemas para configurar sus entornos porque todos organizan las cosas de manera diferente, puede haber una razón para recomendar una camisa de fuerza. Sin embargo, si todos estuvieran felices y productivos usando lo que quisieran, hay pocas razones para imponer un cambio en algo tan profundamente involucrado en el proceso creativo.

Eclipse es mucho más que un editor: puede seguir usando su editor favorito para editar su código y confiar en Eclipse para el control de la fuente, la depuración y cualquier otra cosa que el flujo de trabajo obligatorio de la empresa quiera que se use.

Una última cosa: hacer cumplir el proceso en este nivel puede indicar que la empresa tiene la intención de expandir el equipo de desarrollo y quiere tener una cierta estructura para que los nuevos compañeros de equipo puedan ser productivos más rápido. Si crees que Rails (o Django) como un marco "obstinado", te darás cuenta de que tener una estructura ayuda a comprender nuevas aplicaciones más fácilmente.

rbanffy
fuente
0

La bandera roja no es tanto que un único IDE / editor se está imponiendo a cada desarrollador, sino que esta decisión, y especialmente la decisión sobre qué IDE / editor se iba a utilizar, no fue tomada por todos los desarrolladores, y quizás ninguno de los desarrolladores ¡¿¡ellos!?!

Ciertamente, sería mejor que los desarrolladores llegaran a un consenso, especialmente porque obviamente están mejor calificados para la decisión (al menos en qué editor / IDE). Puede haber buenas razones para conformarse y esa decisión debería influir en la preferencia de la administración, pero qué editor / IDE debería haber sido la decisión de todos los desarrolladores.

Hacer que 12 desarrolladores emitan algunos votos sería fácil. ¡Ciertamente había tiempo suficiente para hacer eso! La conclusión habría sido dolorosa para algunos de todos modos e incluso podría haber terminado siendo Eclipse al final, pero etiquetar el requisito como una "bandera roja" en ese caso sería mucho más discutible.

ghbarratt
fuente