Aplicación Legacy C – ¿Refactorización o reingeniería? (III)

Word_Refactoring_Reingenierie3Tenemos 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

Madrid DevOps – Integración Continua

Madrid_DevOps2Madrid 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

Aplicación Legacy C – ¿Refactorización o reingeniería? (I)

WordCLegacy_UseCases1Continuamos 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

Auditoría de una aplicación Legacy en C – Microsoft Word 1.1a (II)

C_Analysis_Word2En 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

Auditoría de una aplicación Legacy en C – Microsoft Word 1.1a (I)

C_Analysis_Word0Microsoft 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

Resultados Qualilogy 2013

Qualilogy_Results2013Los resultados de la ‘SonarQube 2014 unofficial survey’ anual han sido publicados: http://onlysoftware.wordpress.com/2014/02/03/sonarqube-2014-unofficial-survey-results/

Su autor, Patroklos Papapetrou, es un SonarQubista distinguido y muy competente, co-autor del libro « SonarQube In Action ».

Como me di cuenta de diferencias significativas en esos resultadocs con los de mi blog, sobre todo en el origen geográfico de los participantes en esta encuesta, yo decidí hacer algunas estadísticas sobre la frecuentación en Qualilogy para el año 2013 .

Ya conozco estas tendencias porque voy a consultar bastante regularmente estas cifras, pero no había hecho un resumen de todo el año. Pues será el tema de este post. Sigue leyendo

Análisis PL/SQL con SonarQube – Evaluar la calidad (3/3)

PLSQL_TechnicalDebtÚltimo post de nuestra serie sobre el análisis de la calidad de código PL/SQL con SonarQube.

La evaluación de la calidad de una aplicación no es sólo el análisis de código: eso, cualquiera puede hacerlo. El trabajo del consultor se basa en las siguientes preguntas: qué, por qué, cómo, cuánto.

  • Qué: analizar los resultados. El tamaño, la complejidad y la duplicación de código, esto es lo que hemos visto en los articulos anteriores. Se examinan las cifras globales, el promedio, así como las tendencias en el tiempo, si hay varias versiones. Luego nos fijamos en las principales violaciónes de buenas prácticas, principalmente los Blockers y Criticals.
  • ¿Por qué estos resultados?: investigamos las causas de los datos en el cuadro de mando SonarQube, el origen de los resultados encontrados.
  • ¿Cómo remediar?: proponer un plan de acción. De hecho, varias propuestas de acción. Más adelante veremos que pensamos en diferentes planes en el corto, mediano y largo plazo.
  • ¿Cuánto cuesta?: evaluar el coste de cada plan. Sigue leyendo

Análisis PL/SQL con SonarQube – Evaluar la calidad (2/3)

PLSQLEva2Lo siento por el tiempo pasado desde el último post de esta serie sobre PL/SQL y SonarQube, pero estaba muy ocupado entre viajes, el trabajo y mi laptop que decidió abandonarme, por supuesto invocando la ley de Murphy para justificar fallar en el peor momento.

En los posts anteriores: después de configurar un análisis de código PL/SQL con SonarQube, hemos elaboraro nuestro propio Quality Profile con una orientación a la robustez, el rendimiento y la seguridad en las reglas Blockers y Criticals.

¿A que parece ahora nuestro dashboard SonarQube? Sigue leyendo

Análisis PL/SQL con SonarQube – Evaluar la calidad (1/3)

PLSQL_EvaluationQualité1Un post de síntesis, para esta serie sobre el análisis de código PL / SQL con SonarQube.

Después de configurar nuestro análisis con Jenkins, lo lanzamos y encontramos 17 defectos bloqueantes (Blockers), pero ninguna falta crítica (Criticals) con el perfil de calidad de SonarQube. De hecho, las 5 reglas Criticals eran desactivadas y también algunas otras normas de diferentes criticidades: 58 en un total de 132. Sigue leyendo