¿Están los lenguajes dinámicos en desventaja para el desarrollo ágil?

Teóricamente, los lenguajes dinámicos están en desventaja, todos los demás son iguales, porque especifican menos sobre cómo funciona el código (cuáles son las restricciones) y, por lo tanto, se puede hacer una menor parte de la refactorización automáticamente, y no se pueden detectar los problemas que surjan. automáticamente también.

Pero todo lo demás no es igual. Los lenguajes dinámicos más populares permiten un código altamente compacto pero comprensible, que generalmente hace que el desarrollo en ellos sea más rápido y hace que la lógica (que puede cambiar en la refactorización) sea más fácil de detectar visualmente. Por lo tanto, aunque podría perder parte de la ventaja relativa de trabajar en un lenguaje dinámico, es posible que aún salga adelante, especialmente si planea hacer su refactorización a mano de todos modos.

Por otro lado, existen lenguajes tipificados estáticamente con esencialmente las mismas ventajas que los lenguajes dinámicos (es decir, compactos y comprensibles, con tipos mayormente inferidos, pero muy presentes): Haskell es quizás el ejemplo principal, pero OCaML / F # , Scala, y otros están en esta categoría también. Desafortunadamente, dado que son menos utilizados que los lenguajes de escritura estática más populares, no tienen un conjunto de herramientas tan amplio (por ejemplo, para refactorizar).

Entonces, como resultado final, creo que lo harás adecuadamente con metodologías ágiles en la mayoría de los idiomas; No diría que hay un claro ganador en este momento ya que la práctica aún no ha alcanzado la teoría.

La refactorización automatizada se inventó en Smalltalk, un lenguaje tipificado dinámicamente. Así que no, no es imposible tener una refactorización automática en un lenguaje de tipo dinámico. Lo difícil que sea depende mucho más de otros factores además de la disciplina de mecanografía. C ++ y Java están tipificados estáticamente, pero las herramientas de refactorización solo existen para Java. Smalltalk con su introspección y sintaxis simple fue un muy buen candidato para las herramientas de refactorización.

De alguna manera, la escritura dinámica en realidad facilita la refactorización. Si tiene un buen conjunto de pruebas, puede estar seguro de que sus refactorizaciones no han roto nada. Una base de código tipificada dinámicamente es típicamente más pequeña. Además, las refactorizaciones tienden a afectar menos al código. En conjunto, el esfuerzo que implica la refactorización manual de una base de código dinámico es menor que el de una base de código estático.

La refactorización fue inventada en lenguajes dinámicos. Las herramientas automatizadas de refactorización fueron inventadas en lenguajes dinámicos. Los IDE fueron inventados en lenguajes dinámicos. Se han inventado varias metodologías ágiles en lenguajes dinámicos.

Realmente no veo ningún problema.

Para que no olvidemos, la forma de trabajo "ágil" que se conoció como Programación extrema (XP) se creó en un proyecto Smalltalk (y Smalltalk ciertamente cuenta como un lenguaje "dinámico").

Este es un estudio de caso del uso industrial de una herramienta de refactorización provista con un lenguaje de tipo dinámico:

  

En Cargill se desarrolló una aplicación Smalltalk muy grande para respaldar   La operación de elevadores de granos y el comercio de productos básicos asociados.   ocupaciones. La aplicación cliente Smalltalk tiene 385 ventanas y más   5,000 clases. Cerca de 2,000 clases en esta aplicación interactuaron con   un marco de acceso a datos temprano (circa 1993). El marco dinámicamente   realizó una asignación de atributos de objeto a columnas de la tabla de datos.

     

El análisis mostró que, aunque la búsqueda dinámica consumió el 40% de la   el tiempo de ejecución del cliente, era innecesario.

     

Una nueva interfaz de capa de datos   Fue desarrollado que requería la clase de negocios para proporcionar el objeto.   asignación de atributos a columnas en un método codificado explícitamente. Pruebas   Mostró que esta interfaz era órdenes de magnitud más rápida. La cuestión   fue cómo cambiar los 2,100 usuarios de clase empresarial de la capa de datos.

     

A   gran aplicación en desarrollo no puede congelar el código mientras que una   La transformación de una interfaz se construye y se prueba. Tuvimos que   construir y probar las transformaciones en una rama paralela de la   Repositorio de código de la corriente principal de desarrollo. Cuando el   La transformación se probó completamente, luego se aplicó al código principal.   transmisión en una sola operación.

     

Se encontraron menos de 35 errores en el   17,100 cambios. Todos los errores se resolvieron rápidamente en tres semanas.   período.

     

Si los cambios se hicieran manualmente estimamos que sería   Han tomado 8,500 horas, en comparación con 235 horas para desarrollar el   reglas de transformación.

     

La tarea se completó en el 3% de lo esperado.   tiempo utilizando Reglas de Reescritura. Esta es una mejora por un factor de 36.

de "Transformación de una capa de datos de aplicación" Will Loew-Blosser OOPSLA 2002

También - " Herramientas para hacer cambios imposibles - experiencias con una herramienta para transformar grandes programas de Smalltalk "

Tu pensamiento de principios me suena correcto .

Los lenguajes fuertemente tipados como C # son buenos candidatos para una base de código que constantemente necesita una re-factorización. Básicamente, la mayoría de las herramientas de re-factoring (como Resharper, JustCode, etc.) en el mercado son muy efectivas en lenguajes de programación tipificados estáticamente.

  

¿Qué dicen los proyectos del mundo real sobre el uso de lenguajes de tipo dinámico para la metodología ágil?

Para el equipo de desarrollo que practica la metodología Agile / Scrum, es muy útil (incluso crítico) tener un buen conjunto de herramientas de re-factorización bajo la armadura. De lo contrario, todos los cambios repentinos en el próximo sprint pueden ser una pesadilla para modificar o rediseñar.

Por lo tanto, la metodología ágil no proporciona ventajas a lenguajes tipificados estáticamente o dinámicos una vez. Lo que proporciona es un enfoque iterativo para construir una aplicación sólida.