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

Análisis PL/SQL con SonarQube – Majors

PLSQL_MajorsContinuamos esta serie en el análisis de código PL/SQL con hoy las normas de tipo Majors.

Vimos antes cómo organizar nuestro entorno y configurar nuestro análisis de código con Jenkins y SonarQube.

Hemos creado nuestro propio Quallity Profile y revisado las reglas de tipo Blockers y Criticals, todas orientadas a Robustez (fiabilidad) y Seguridad.

Sigue leyendo

Análisis PL/SQL con SonarQube – Criticals

PLSQL_CriticalEn el post anterior de esta serie sobre el análisis de código PL/SQL con SonarQube, hemos visto las reglas Blockers de nuestro nuevo Quality Profile.

En esta ocasión, hemos encontrado tres violaciones de las mejores prácticas de programación PL/SQL cuyas consecuencias son tan graves que no se puede imaginar cualquier tolerancia. Lo qué justifica por tanto su condición de ‘bloqueadores’.

Tambien, se encuentra un total de 18 fallos para estas 3 reglas, y entonces este número limitado nos deja suponer que estas reglas son conocidas por el equipo del proyecto.

Por último, estos defectos pueden generar un error de lógica en la aplicación – una operación que nunca se puede realizar debido a que la condición correspondiente nunca se cumplirá – e incluso un crash de la aplicación. Sigue leyendo

Análisis PL/SQL con SonarQube – Blockers

PLSQL_BlockersCriticalEn el post anterior, hemos creado nuestro propio Quality Profile PL/SQL, activando todas las 132 reglas presentes en SonarQube. Luego, hemos ejecutado de nuevo nuestro análisis de código PL/SQL.

Pues vamos a poder trabajar con todas las normas de calidad del Quality Profile predeterminado de SonarQube y seleccionar las que nos interesan para crear un cuadro de mando para nuestro entorno de demos. Sigue leyendo

Análisis PL/SQL con SonarQube – El Quality Profile PL/SQL

SonarQubePLSQL3En el post anterior, hemos configurado nuestro primer análisis PL/SQL con SonarQube y Jenkins. Lo ejecutamos, y luego podemos ver los resultados en el dashboard de SonarQube.

Será una oportunidad para examinar y explicar en los próximos articulos las reglas de SonarQube sobre las mejores prácticas de programación PL/SQL. Pero en primer lugar, vamos a ver lo que nos ofrece el Quality Profile PL/SQL de SonarQube. Sigue leyendo

Análisis PL/SQL con SonarQube – Configuración

SonarQubePLSQL2Hemos visto en el primero post de esta serie acerca de análisis de código PL/SQL con SonarQube, cómo he organizado mi entorno de análisis, con:

  • una carpeta ‘C:\SRC\’ con todos mis proyectos,
  • un subdirectorio por cada proyecto,
  • y luego diferentes otras carpetas, incluyendo un directorio ‘..\Source’ donde localizamos el código que analizar.

Entonces, para nuestro análisis PL/SQL, el código se encontrara en la carpeta ’C:\SRC\Demo\PLSQL\Source’.

Vamos a ver ahora cómo crear y configurar un análisis SonarQube de este código PL/SQL, con Jenkins. Sigue leyendo