Imagine que su lugar de trabajo actual es una tienda Java. Existe un gran conocimiento acumulado sobre el lenguaje Java y existe un proceso integral de construcción e implementación para manejar todo de una manera ágil y fluida.
Un día, surge un proyecto que simplemente grita que se escriba, por ejemplo, Ruby. Solo los desarrolladores principales tienen alguna idea sobre Ruby, pero existe la noción general de que, dado que JRuby existe para JVM, la infraestructura existente podría continuar siendo utilizada y soportada. Además, JRuby podría mostrar el camino hacia una mejor manera de implementar las aplicaciones actuales con menos código, por lo que esto podría representar una migración continua.
Recuerde que JRuby es solo un ejemplo, igualmente podría ser Clojure o Groovy o cualquier otra cosa que se ejecute en la JVM.
La pregunta es ¿cómo haría para introducir este tipo de cambio, si es que lo hace?
fuente
Respuestas:
Descargo de responsabilidad: soy parcial ya que estoy escribiendo un libro sobre programación Polyglot en el JVM (Shameless Plug !! - The Well-Grounded Java Developer) :)
En primer lugar, ¡solo debes introducir el cambio donde esté realmente garantizado!
Un buen lugar para comenzar es considerar la pirámide del lenguaje de programación de Ola Bini. Ola habla de lenguajes específicos de dominio, estables y dinámicos.
Java es un lenguaje estable (estáticamente tipado y administrado) y por varias razones (puedo entrar en esto más adelante si la gente está interesada) no es una opción ideal para proyectos de capa dinámica (por ejemplo, Desarrollo web rápido) o proyectos de capa específicos de dominio (por ejemplo, modelado el dominio del Patrón de integración empresarial). Si tiene un proyecto que encaja en una de esas capas, entonces ese puede ser un buen lugar para comenzar.
También puede considerar la introducción de un nuevo lenguaje en la capa estable para reemplazar Java si hay una característica fundamental que ofrece el lenguaje alternativo. Por ejemplo, Scala simplemente maneja la concurrencia de una manera más segura y natural que Java.
Según lo solicitado, un poco más sobre esto. WRT Java:
En este punto, puede que se pregunte: “¿Qué tipo de desafíos de programación encajan dentro de estas capas? ¿Qué idioma (s) debo elegir? ”, Recuerde que no hay una bala de plata, pero tengo algunos criterios que podría considerar al evaluar sus elecciones.
Dominio específico
Dinámica
Estable
Comience con un pequeño módulo de bajo riesgo (recuerde, estos lenguajes JVM a menudo interactúan maravillosamente con el código Java existente) o proyecto. Deje en claro que este será un prototipo descartable.
Asegúrese de haber investigado el ciclo de vida de la programación y los aspectos de herramientas para ese lenguaje. Deberá asegurarse de que puede TDD, ejecutar herramientas de compilación e integración continua, tener un poderoso soporte IDE y todos esos otros factores. Para algunos idiomas, solo tendrá que aceptar que ciertas herramientas no están allí o son muy básicas. La fuerza del desarrollador y el soporte de herramientas pueden superar la fuerza de un lenguaje.
Asegúrese de que haya una comunidad vibrante que pueda ayudar a su equipo cuando se estanquen. Los grupos de usuarios locales son aún mejores para esto.
Asegúrese de que los desarrolladores obtengan la capacitación inicial en idiomas, especialmente si el idioma no es un estilo de OO (el cambio a Clojure no es trivial).
Eso es todo, creo. Personalmente, he utilizado con éxito Groovy, Scala y Clojure en mi desarrollo junto con Java para tareas como el procesamiento de XML, la creación de sitios web rápidos y el procesamiento de algunos datos.
fuente
Me gustaría agregar algunas ideas sobre el tema planteado con el comentario "si es que lo hay". De hecho, ¿por qué debería uno introducir idiomas adicionales al equipo? Es cierto que si solo está mirando un proyecto individual, el nuevo lenguaje podría sobresalir como la herramienta ideal para la tarea. Pero si va a tener muchos proyectos, puede terminar con bastantes idiomas adicionales con el tiempo. No sé acerca de sus ciclos de mantenimiento y números de proyectos, pero es probable que el equipo tenga que proporcionar mucha experiencia en más idiomas que antes.
Desde el punto de vista comercial, agregar idiomas significa agregar requisitos de complejidad y conocimiento al equipo. Esto extiende los períodos de ajustes vocacionales, hace que los reemplazos de especialistas en su equipo basados en vacaciones (o permanentes) sean más difíciles y requiere capacitación adicional para los miembros del equipo, lo que significa desaceleración a corto plazo.
En mi opinión, una estrategia para hacer que la presentación sea bienvenida debería abordar estos problemas además de los aspectos puramente funcionales, también. ¿Vale la pena la ganancia esperada por los problemas adicionales y las desventajas como las que mencioné anteriormente? Si esto se puede probar, las tasas de aceptación podrían ser mucho más altas. Señalar esas buenas inversiones en la calificación de los miembros del equipo también podría ayudar.
fuente
Yo diría, comienza por los bordes. Muestra el lenguaje en algunos códigos que no son de producción, como scripts de compilación, complementos de Maven, ejecución de informes, etc. Una vez que ven la utilidad y la simplicidad, pueden estar más inclinados a permitir proyectos de pequeña escala, etc.
fuente