Argumentos en apoyo de la transición organizacional al desarrollo de Scala

7

Trabajo en una organización que hace un desarrollo extenso de Java. Nuestro grupo es pequeño con un proyecto de corta duración, carta de desarrollo ágil. Aprovecharemos los recursos de control de calidad existentes de otros grupos y, posiblemente, contribuiremos con el código a los clientes y socios.

Los argumentos principales contra el desarrollo de Scala han sido:

  • QA necesitará experiencia Scala
  • Los clientes necesitarán la experiencia Scala

Mi experiencia ha sido que Scala es generalmente más fácil de leer que Java con una exposición mínima al lenguaje, y que la capacidad de usar herramientas Java existentes como Junit minimizaría el impacto negativo en las estrategias de prueba existentes.

He estimado que el desarrollo en Scala podría ser un 25% más rápido que el desarrollo equivalente en Java, dependiendo del problema. Esto es solo un dedo en el viento basado en mi experiencia personal. Si alguien tiene evidencia de un aumento de eficiencia, por favor, comparta.

También me gustaría compilar una lista de los principales beneficios del uso de Scala sobre Java. Por favor comparte tus favoritos.

Gracias, John

    
pregunta jxstanford 01.04.2011 - 19:06

3 respuestas

6

Muestra no digas - construye algo en Scala. Sugiero probar tus aplicaciones Java. Aquí hay una publicación que hice sobre la configuración de Scala Specs como marco de prueba para proyectos Java Maven: enlace

La gente normalmente se siente cómoda con tus exámenes de escritura como quieras.

El único argumento que tendrá el agua para la administración según mi experiencia es que puede hacer más trabajo en menos tiempo y que será un trabajo de mayor calidad que cueste menos en el mantenimiento continuo. Sugiero dejar los argumentos sobre la elegancia del lenguaje, su expresividad, etc. a las discusiones con los desarrolladores, no a la administración.

Enfatice que puede usar sus bibliotecas de Java existentes (piense en "aprovechar la inversión existente"). Además, si usa Spring o similar, piense en las implementaciones de Scala de las interfaces de Java como una forma de permitir que los desarrolladores que quieren probar Scala lo hagan sin interrumpir a los demás.

Lo más importante es construir algo y demostrar que puedes. Tomé la idea de crear servicios web en unas pocas horas, cuando el equivalente hubiera demorado mucho más en Java: en días de reflexión. Un ejemplo de cómo he hecho esto está aquí: enlace

No creo que las estadísticas externas sean muy convincentes, ya que la capacidad de un desarrollador para trabajar más efectivamente en Scala que en Java realmente depende del desarrollador. Pero si puedes probarlo, entonces definitivamente ganarás terreno. Buena suerte!

    
respondido por el Janx 01.04.2011 - 19:30
4

En realidad, es más fácil hacer un proyecto que obtener permiso para hacerlo.

Además, todas las pruebas externas a la organización están en desuso triviales por personas que no quieren cambiar. Simplemente dicen "eso no funcionará aquí". (O lo que es peor, "eso no funcionará en el mundo real").

No puedes acumular suficiente evidencia externa e indirecta.

Sin embargo, si realmente haces un proyecto real en Scala, la conversación es muy diferente. Usted tiene un historial de éxito a un costo menor. Nadie puede discutir con eso.

"Desafortunadamente, ya tomamos la ruta de obtención de permisos y ahora estamos en una posición de negociación menos que ideal"

En realidad no.

Si crees que estás obligado de alguna manera a continuar pidiendo permiso, estás esencialmente condenado.

El punto es este: "Es más fácil pedir perdón que pedir permiso".

El inicio de un proyecto se puede hacer en cualquier momento, independientemente de las políticas anteriores (o no) en su lugar.

Usted acaba de comenzar el proyecto. Incluso si ya ha preguntado y ha sido rechazado una vez (o una docena) veces.

Cuando tienes éxito, pides perdón por ser también exitoso.

    
respondido por el S.Lott 01.04.2011 - 19:09
2

La mayoría de los tipos de administración no se preocupan por los beneficios de Scala. Serán adversos al riesgo y estarán preocupados por la disponibilidad de nuevos programadores, el costo de capacitar a los programadores existentes, las perspectivas de soporte a largo plazo para el idioma, etc.

Peor aún, estas son las mismas personas que han supervisado a los desarrolladores de Java y creerán que lo han hecho muy bien. Sugerir que un cambio puede interpretarse como un truco para su capacidad.

El truco, entonces, es (en primer lugar) establecer que Scala es totalmente interoperable con Java, usted está construyendo sobre el éxito pasado y la inversión existente aquí. Luego continúe para ver cómo Scala mejora eso al mitigar los riesgos actuales: costos de mantenimiento del código, defectos en el software de producción, tiempo de comercialización / costos de oportunidad, etc.

Si su gerente está muy orientado hacia las personas (y muchos lo están), entonces nunca está de más señalar que Scala es considerado un lenguaje atractivo para trabajar. Es poco probable que el código bonito impresione a su administrador, pero trabajar con algo que ayude a atraer y retener a desarrolladores talentosos seguramente atraerá más interés.

Scala no es solo una alternativa a Java, es una progresión natural: el lugar al que vas cuando llegas a la cima de tu juego y quieres ir más lejos. Ser capaz de realizar esa migración solo muestra exactamente lo bueno que ya eres, así que no te avergüences de dar masajes a algunos egos si es necesario.

Finalmente, como ya se sugirió, ¡sea proactivo! Haga algo a través de un proyecto de demostración y haga que otros desarrolladores se interesen en él. Un movimiento popular de varias personas será mucho más persuasivo ...

    
respondido por el Kevin Wright 02.04.2011 - 01:25

Lea otras preguntas en las etiquetas