Page 28 - REVISTA 2016

pero en cada caso habría que hacer un análisis en base a lo que nosotros le llamamos “la rueda del testing”. En esta
rueda se muestra gráficamente la relación que hay entre cada tipo de testing y cada factor de calidad. Habiendo
hecho esta aclaración, veamos ahora en profundidad los aspectos más relevantes de las áreas más importantes.

El código fuente

Este es uno de los activos más preciados en todo equipo de desarrollo, ya que ahí está todo nuestro trabajo. De
hecho, es el único artefacto que en todo proyecto siempre se va a construir. En muchos equipos no se documen-
ta, no se hacen determinados tipos de pruebas o no se siguen ciertas prácticas, pero sin código no hay software,
así que siempre habrá código. Esto da la pauta que es el área fundamental a prestarle atención para asegurar la
calidad, reducir los riesgos y los costos. Al considerar el área relacionada al código fuente nos estamos refiriendo
a varias cosas, principalmente a la gestión del código y a la calidad del mismo. Ambos aspectos deben ser con-
templados para poder llegar a un buen enfoque de integración continua.

Gestión del código

Al tratarse de un activo muy importante, hay un riesgo que es fundamental tener bajo control y es el de asegurar-
nos de gestionar adecuadamente el código y todas sus modificaciones. Para esto se utilizan herramientas espe-
cíficas que permiten trabajar con un repositorio centralizado, donde todos los integrantes de un equipo puedan
almacenar en forma confiable todo el código. Las herramientas han evolucionado en cuanto a los enfoques de
trabajo, pasando desde los repositorios compartidos, CVS, SVN y ahora Git. En menor o mayor nivel, lo que permi-
ten es tener el código en un lugar centralizado, y que cada desarrollador pueda enviar código, consultarlo, recu-
perar versiones anteriores, que pueda agregar comentarios a cada “commit” que se hace (o sea, comentarios que
indiquen por qué se decidió enviar determinado código al repositorio) y mucho más. Estas herramientas también
se acompañan por una gestión acorde a una metodología. En especial esto se refleja en cómo se administran las
ramas de las versiones, lo cual permite que distintas personas estén trabajando en distintas versiones del código.
Hay quienes mantienen una rama por cada cliente (si cada cliente tiene código diferente), o una rama por grandes
versiones de código, o a un nivel más fino, en el cual se abre una nueva rama por cada funcionalidad o fix que
alguien va a realizar. Sea como sea, lo importante es tenerlo definido y que todos lo manejen de la misma forma,
así luego es más fácil encontrar las modificaciones que se busquen, y recuperar versiones anteriores.

Calidad del código

Por otra parte, tenemos la mantenibilidad del código. Suele decirse que es un atributo interno de calidad, ya que
no se hace visible al usuario. Puede pasar que un software que nosotros consideramos que es de buena calidad
(fácil de usar, rápido, sin bugs críticos, etc.) tenga grandes problemas de calidad de código, pero como no pode-
mos ver ni analizar el código, no nos enteramos. En cambio, los factores de calidad de rendimiento, fiabilidad,
usabilidad y varios más, son externos, ya que los percibimos al utilizar el software. Pero pasa algo bien interesan-
te, hay un momento en que ese factor de calidad interno pasa a ser externo: cuando queremos un cambio en el
sistema. Si modificar una funcionalidad del sistema lleva semanas, estamos percibiendo un problema de mante-
nibilidad, o sea, qué tan fácil de mantener es ese código.
Hace años que se habla de “deuda técnica” para explicarle el problema de mantenibilidad de código a alguien que
no tiene conocimientos en programación, gracias a que se hace una analogía con un dominio bien conocido que
es el de las deudas financieras. Básicamente se dice que, si tenemos que programar una determinada funcionali-
dad, y al no tener suficiente tiempo lo hacemos rápido, sin cumplir el “definition of done” establecido como bue-
nas prácticas del equipo, entre lo que se podría estar salteando la documentación en comentarios en el código,
adecuación a estándares y convenciones de codificación, o la implementación de pruebas unitarias, dejándolo
“para cuando tengamos tiempo”, entonces estamos ahí en ese preciso instante adquiriendo una deuda. Le debe-
mos al sistema la implementación de una prueba unitaria. Lo tendremos que hacer la semana que viene cuando
tengamos más tiempo. ¿Cuál es el problema? Que además de la deuda, debemos pagar los intereses, ya que
seguramente la semana que viene no recordemos bien todo lo que hicimos, tengamos que volver a ponernos en
contexto de esa funcionalidad, etc. Todo problema de mantenibilidad genera deuda técnica, y siempre alguien la
paga: a veces la paga el desarrollador, y a veces el usuario, sufriendo la mala calidad del sistema.

30 Revista de la Facultad de Ingeniería