Page 29 - REVISTA 2016

Los entornos de desarrollo modernos, tales como Visual Studio o Eclipse (por nombrar algunos populares) ayu-
dan muchísimo con varios de estos problemas, al punto que si no se cumplen algunas restricciones el código no
compila. De todos modos, hay muchas cosas más que las podemos analizar con herramientas específicas para
analizar la calidad del código. Hoy en día, la herramienta más popular para este fin es SonarQube, pero existen
varias como PMD y CheckStyle. Estas herramientas realizan un estudio estático del código y de caja blanca, o sea,
analizan el código sin ejecutarlo. Dentro de las verificaciones que realizan, verifican los defectos comunes que
mencionamos antes, como el código duplicado o la complejidad ciclomática. Algo bien interesante, es que So-
narQube es capaz de indicar cuál es la deuda técnica, sumando cuántos minutos nos llevaría resolver cada issue
detectado.
Si bien SonarQube me puede decir dónde está la deuda técnica, es importante también saber cómo pagarla. Ahí
lo fundamental es no tocar cualquier código, no alcanza con ordenar los issues por severidad. Es necesario cruzar
la información de los issues y su severidad con la cantidad de commits que hay en cada clase. De esta forma, va-
mos a poder enfocar nuestro esfuerzo a mejorar la mantenibilidad de aquellas clases que son modificadas más a
menudo. En cambio, si se observan problemas de mantenibilidad de clases que no se tocan nunca y que funcio-
nan adecuadamente, es mejor no atacarlos. Parafraseando a una frase popular relacionada al fútbol: código que
funciona, no se toca.

Si no perdemos de vista que estamos buscando armar un entorno de integración continua, es claro que
vamos a necesitar que el código esté accesible en un repositorio bien organizado, y que se realicen diver-
sos chequeos de calidad sobre el código, como por ejemplo la verificación con SonarQube.

Los entornos e infraestructura

Por lo general todos suelen estar de acuerdo que lo mejor es tener distintos ambientes, por lo menos 3:
uno para desarrollo, donde se compila y se prueba en forma local cada modificación, uno para los testers,
para que prueben las versiones “cerradas” prontas para probar, y luego el de producción, donde está el
código que usan los usuarios. A nadie se le ocurre pasar de desarrollo a producción sin pasar por testing,
¿cierto? Lamentablemente hay muchos equipos que ni siquiera tienen tres ambientes y realizan estas
prácticas, con las claras consecuencias negativas que puede acarrear, como “en mi máquina anda” pero al
usuario no le funciona.

Agreguemos la complicación de que tal vez tenemos distintas pruebas a realizar con distintas configuraciones,
parametrizaciones, etc. Entonces para esto tenemos más de un ambiente de pruebas, o tenemos un ambiente y
muchos backups de base de datos, uno para cada conjunto, de la complejidad extra que agrega esto es que hay
que realizar un mantenimiento específico a cada backup (por ejemplo, cada vez que hay cambios en el sistema
en los que se modifica la base de datos, será necesario impactar a cada backup con esos cambios). Pero si uno
de estos elementos no está en sintonía con el resto, probablemente las pruebas fallarán y no estaremos siendo
eficientes con nuestros esfuerzos. Es importante que cada vez que una prueba reporta un fallo, es porque hay un
bug, y no generemos falsas alarmas. Es así que vemos la necesidad de tener varios ambientes y gestionarlos en
forma apropiada. O sea, evitar problemas del tipo “¿estás seguro que estás probando sobre la última versión?”.
También es fundamental contar con todos los entornos que los testers necesitan, y eso puede incluir dar acceso
a sistemas operativos diversos, con distintas configuraciones, diferentes versiones de browsers, o incluso tener
disponible el acceso a diversos dispositivos mobile, ya que con la alta variedad de dispositivos existentes es nece-
sario probar las apps en un conjunto variado de estos.

Para resolver todos los problemas a nivel de ambientes y entornos se suele contar con perfiles especiales dentro
del equipo, y algo que está muy “de moda” últimamente, es contar con DevOps. Básicamente es alguien que
conjuga la visión de operaciones (gestión de infraestructura y entornos), la de desarrollo y negocio. Teniendo
vinculadas estas áreas será posible resolver más rápido y eficiente todas las necesidades del equipo con foco en
el cliente y el usuario final.

Reflexiones sobre Ingeniería 31