En nuestro post anterior, hemos hablado de la définición de Michael Feathers (en su libro « Working Effectively with Legacy Code ») explicando que la ausencia de pruebas unitarias es el factor determinante de una aplicación Legacy. El propone el concepto de prueba de caracterización para entender el comportamiento de la aplicación, es decir, lo que realmente hace, sin tratar de descubrir a través del código que se supone que debe hacer.

Pero ¿qué pasa cuando nuestra aplicación Legacy no tiene nada de pruebas unitarias? La respuesta a uno de nuestros tres escenarios – el plan de transferencia de la aplicación a otro equipo – puede hacerse escribiendo estas pruebas? ¿Es posible facilitar la transferencia de conocimientos con pruebas unitarias? Sigue leyendo →

La vuelta de las vacaciones del verano nos permite reanudar esta serie de posts sobre el uso de SonarQube con aplicaciones de tipo Legacy, en este caso la primera versión de Word publicado por Microsoft en 1990.

Nos planteamos la siguiente hipótesis: Microsoft acaba de ser comprada y su nuevo propietario le pide, como consultor de calidad, recomendar una estrategia para esta versión de Word.

No creas que esto nunca sucede: empresas de software cambian de manos todos los días, y la I+D y el código del software están en el corazón de esas adquisiciones.

Sigue leyendo →

Tenemos esta aplicación Legacy C, la primera versión de Word publicada por Microsoft en el año 1990, para la cual se propone cuantificar el coste de diferentes estrategias: refactorización o reingeniería, por el mismo equipo de desarrolladores o por un nuevo equipo y por tanto, con una transferencia de conocimiento. Sigue leyendo →

Continuamos esta serie sobre los diferentes casos de uso que puedan surgir en relación con la transferencia de una aplicación Lecagy en C, desde el análisis del código fuente de Word 1.1a, la primera versión de este software de Microsoft publicado en 1990.
Sigue leyendo →

Madrid DevOps es un grupo de profesionales interesados en … DevOps, como se puede imaginar. Hay un ‘Meetup Group’ donde encontrar noticias, principalmente de nuevas reuniones cada mes.

El 10 de abril, la charla trataba de ‘Integración Continua’, con Manuel Recena Soto y Antonio Manuel Muñiz de ClinkerHQ. Les hice algunas preguntas acerca de su presentación, que se puede ver en https://speakerdeck.com/clinkerhq/integracion-continua. Sigue leyendo →

Continuamos esta serie sobre el análisis del código fuente de Word 1.1a, publicado por Microsoft en 1990.

En el primer post, hemos visto las métricas cuantitativas de tamaño, de complejidad, el nivel de comentario y de duplicación. El segundo post fue dedicado a los diferentes ‘Issues’ Blocker, Critical, Major et Minor. Sigue leyendo →

En el post anterior, hemos examinado los primeros resultados del análisis de código fuente de Word 1.1a (1990).

Contamos con 349 archivos, que no es enorme, pero con un tamaño alto: en promedio, más de 470 LOC (Lines Of Code), y muchos de ellos más allá de 1 000 LOC. Las métricas de complejidad también son altas, y el nivel de comentarios bastante bajo, pero probablemente era normal hace más de 40 años.

El muy bajo nivel de duplicación hace pensar que todos los componentes necesarios para implementar una funcionalidad se encuentran en un mismo archivo, por lo que explica el tamaño y la complejidad de muchos de ellos. Parece que la consigna era: prioridad a la eficiencia, luego la legibilidad y la comprensión del código en segundo plano. Sigue leyendo →

Microsoft ha publicado esta semana lel código fuente de Word 1.1a (1990) mediante el Computer History Museum: http://www.computerhistory.org/atchm/microsoft-word-for-windows-1-1a-source-code/.

Es una de las primeras versiones de Word para Windows, de enero 1991:
http://blogs.technet.com/b/microsoft_blog/archive/2014/03/25/microsoft-makes-source-code-for-ms-dos-and-word-for-windows-available-to-public.aspx.

Tuve la idea de analizar este código fuente. Tenía curiosidad por ver los resultados, tanto desde el punto de vista cuantitativo – número de líneas de código, la complejidad, etc – como cualitativo: violaciones de buenas prácticas de programación, defectos tipo Blockers, Criticals, etc. Sigue leyendo →