¿Los lenguajes dinámicos están en desventaja para el desarrollo ágil?

Por lo que he leído, el desarrollo ágil a menudo implica la refactorización o el código de ingeniería inversa en diagramas. Por supuesto, hay mucho más que eso, pero si consideramos las prácticas que se basan en estos dos métodos, ¿los lenguajes de tipo dinámico están en desventaja?

Parece que los lenguajes de tipo estático facilitarían mucho la refactorización y la ingeniería inversa.

¿La refactorización o la ingeniería inversa (automatizada) son difíciles, si no imposibles, en lenguajes de tipo dinámico? ¿Qué dicen los proyectos del mundo real sobre el uso de lenguajes de tipo dinámico para una metodología ágil?

Los lenguajes dinámicos están teóricamente en desventaja, todo lo demás es igual, porque especifican menos sobre cómo funciona el código (cuáles son las restricciones) y, por lo tanto, menos de la refactorización se puede hacer automáticamente, y los problemas que surgen no se pueden detectar 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. Entonces, aunque podría perder parte de la ventaja relativa de trabajar en un lenguaje dinámico, aún podría salir adelante, especialmente si de todos modos planeaba hacer su refactorización a mano.

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

Entonces, como conclusión, creo que lo hará 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 automática se inventó en Smalltalk, un lenguaje de tipo dinámico. Entonces, 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 escritura. C ++ y Java son de tipo estático, pero las herramientas de refactorización solo existen realmente 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 de tipo dinámico suele ser más pequeña. Además, las refactorizaciones tienden a afectar menos código. En conjunto, el esfuerzo involucrado en 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 se inventó en lenguajes dinámicos. Las herramientas de refactorización automatizadas se inventaron en lenguajes dinámicos. Los IDE se inventaron en lenguajes dinámicos. Se inventaron 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 Extreme Programming (XP) se creó en un proyecto Smalltalk (y Smalltalk ciertamente cuenta como un lenguaje "dinámico").

Aquí hay un caso práctico de uso industrial de una herramienta de refactorización provista con un lenguaje de tipo dinámico:

Se desarrolló una aplicación Smalltalk muy grande en Cargill para apoyar la operación de los elevadores de granos y las actividades de comercio de productos básicos asociadas. La aplicación cliente Smalltalk tiene 385 ventanas y más de 5,000 clases. Alrededor de 2.000 clases en esta aplicación interactuaron con un marco de acceso a datos temprano (circa 1993). El marco realizó dinámicamente 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 consumía el 40% del tiempo de ejecución del cliente, era innecesario.

Se desarrolló una nueva interfaz de capa de datos que requería que la clase de negocios proporcionara el atributo del objeto a la asignación de columnas en un método codificado explícitamente. Las pruebas mostraron que esta interfaz era mucho más rápida. El problema era cómo cambiar los 2,100 usuarios de clase empresarial de la capa de datos.

Una aplicación grande en desarrollo no puede congelar el código mientras se construye y prueba una transformación de una interfaz. Tuvimos que construir y probar las transformaciones en una rama paralela del repositorio de código desde la secuencia de desarrollo principal. Cuando la transformación se probó por completo, se aplicó a la secuencia de código principal en una sola operación.

Se encontraron menos de 35 errores en los 17.100 cambios. Todos los errores se resolvieron rápidamente en un período de tres semanas.

Si los cambios se hicieran manualmente, estimamos que habría llevado 8.500 horas, en comparación con las 235 horas, para desarrollar las reglas de transformación.

La tarea se completó en el 3% del tiempo esperado mediante el uso de Reglas de reescritura. Esta es una mejora por un factor de 36.

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

Además, "Herramientas para realizar cambios imposibles: experiencias con una herramienta para transformar grandes programas Smalltalk"

Sus principios pensados ​​me parecen correctos .

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

¿Qué dicen los proyectos del mundo real sobre el uso de lenguajes de tipo dinámico para una 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 refactorización bajo 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 los lenguajes tipados estáticamente o dinámicos una vez. Lo que proporciona es un enfoque iterativo para construir una aplicación sólida.