procesos para escribir cdigo mantenible y

estable
por Daniel Micol Ponce

104

105

Introduccin
A la hora de escribir cdigo que ser llevado a produccin, es
necesario seguir un cierto grado de disciplina que permita que dicho
cdigo sea legible, mantenible y correcto. Para esto proponemos una serie
de procesos que son, en cierta medida, estndares de facto en empresas
punteras en el mundo del desarrollo de software. La aplicacin de stos de
una forma correcta y estricta facilitar la escritura de cdigo que podr ser
mantenible a lo largo de los aos, mientras que la no aplicacin de dichos
procesos y disciplina dificultar en gran medida que el cdigo en cuestin
llegue a ser un producto estable y fcil de mantener.
El objetivo final de este captulo es permitir entender cmo realizar
modificaciones controladas y seguras del cdigo, con el objetivo de poder
evitar su desestabilizacin, as como intentar no llegar a un punto en el
cual sea demasiado difcil de mantener. Para ello, vamos a describir una
serie de buenas prcticas para usar sistemas de control de cdigo, ya que
es un elemento fundamental para poder aplicar el resto de prcticas o
procesos y tener una buena gestin del cdigo. Seguidamente pasaremos a
detallar el proceso de revisiones pre-commit, que nos ayudarn, adems de a
compartir conocimiento y escribir cdigo de mayor calidad, a tener un
cierto grado de orden y control sobre los cambios que se realizan sobre el
cdigo. Una vez tenemos dicho proceso, podemos empezar a hablar del
ciclo de vida del desarrollo de software, el cual establece una serie de fases
as como distintas medidas de calidad requeridas para el cdigo que se
modifica. La aplicacin de este ciclo de vida ser posible gracias al
correcto manejo de los sistemas de control de cdigo, as como la
aplicacin de revisiones de cdigo que permitirn el control de los
cambios que se suban al repositorio.

El SCM: ese gran desconocido

Antes de pasar a describir los procesos en cuestin, conviene
recordar cul es la finalidad de un sistema de control de cdigo (SCM por
sus siglas en ingls) como puede ser Subversion o Git. Un error comn es
concebir al SCM como un sistema de copia de seguridad externo, al cual
se intentan enviar tantos cambios y tan frecuentemente como sea posible.

106
Este error es facilitado por sistemas ms sencillos como puede ser
Subversion, donde el comando svn commit permite subir al repositorio
todos los cambios que se hayan hecho, sin tener que decidir de antemano
cules se subirn y cules no. Por lo tanto, una prctica comn es realizar
cambios y cada cierto intervalo de tiempo ejecutar svn commit, a modo de
copia de seguridad. Sistemas ms avanzados como Git incluyen una
gestin de cambios a subir al repositorio, en su caso conocido como
staging area (rea de montaje), en parte para evitar este tipo de malas
prcticas.
La finalidad de un SCM es la de servir como punto de gestin de
versiones relativamente estables, atmicas y completas del cdigo. El
grado en el que esto debe cumplirse depender de la estructura del
repositorio en cuestin, procesos de desarrollo, y el producto que se est
desarrollando. Por lo tanto, nicamente los cambios de cdigo que pasan
un cierto grado de medidas de calidad deben ser subidos al repositorio.
Otro de los objetivos de un SCM es servir de historial de los cambios
realizados en el cdigo. Esto resulta muy til a la hora de averiguar quin
introdujo una determinada funcionalidad y cundo lo hizo, cundo se
arregl un bug o problema, o cuntas veces se ha refactorizado una porcin
de cdigo. Tambin es muy til a la hora de deshacer cambios. Si el
desarrollador en cuestin ha realizado muchos commits, ser complicado
utilizar esta capacidad de historial que tan til puede llegar a resultar. Por
otro lado, si los commits no son atmicos y contienen varios cambios que
afectan a diferentes funcionalidades, ser difcil distinguir qu cambios
pertenecen a una u otra funcionalidad, y tambin ser complicado revertir
las modificaciones a una funcionalidad concreta.

Las revisiones de cdigo: cuatro (o ms) ojos ven

mejor que dos
Una vez detallada la funcionalidad de un SCM, podemos entender
los beneficios de la aplicacin de las revisiones de cdigo. Se trata de uno
de los procesos ms importantes a la hora de desarrollar software correcto
y mantenible, y consiste en solicitar a uno o ms miembros del equipo que
revisen el cdigo escrito. Existen dos tipos de revisiones de cdigo, precommit y post-commit. Las primeras ocurren antes de enviar el cdigo nuevo

107
al repositorio, ya que slo se podr hacer el commit cuando los revisores
hayan aprobado los cambios. Por otro lado las post-commit se realizan
despus de haberse subido los cambios correspondientes. La finalidad de
ambas es muy distinta.
Por una parte, las revisiones pre-commit tratan de identificar posibles
bugs, aspectos que se podran mejorar, inconsistencias en la arquitectura o
el estilo de cdigo, duplicidades, etc. Realizar este tipo de revisiones
ayudan a compartir el conocimiento del cdigo entre los distintos
miembros del equipo, ya que ms de una persona habr visto cualquier
lnea que haya sido escrita, fomenta las discusiones sobre la mejor manera
de disear e implementar cdigo, ayuda a tener uniformidad y sirve para
que todo el equipo aprenda del resto habiendo mayor sincronismo entre el
cdigo que escriben los distintos miembros del equipo. Por lo tanto, las
revisiones pre-commit introducen todas las ventajas del proceso de peerreviewing (revisin en grupo). Esto es habitual en las publicaciones
cientficas y la programacin extrema. Adems, y como se explicar ms
adelante, facilita la tarea de tener commits controlados en las fases de
estabilizacin del cdigo.
Para obtener el mximo beneficio de las revisiones pre-commit, hay
una serie de requisitos que deben cumplirse. La primera es que todos los
cambios que vayan a ser subidos al repositorio pasen una revisin previa y
no sean aadidos a un commit hasta que los revisores hayan aceptado
dichos cambios. Adems, ser necesario el compromiso de los miembros
del equipo de intentar realizar la revisin tan pronto se les haya solicitado,
con el fin de no bloquear a los autores de los cambios en cuestin y
permitir que el cdigo se suba al repositorio lo antes posible. Por ltimo,
los cambios debern ser lo ms pequeos posibles con el fin de permitir
revisiones eficientes, ya que cambios largos dificultan el entendimiento de
todo el cdigo y ralentizan el proceso de revisin.
Hay distintas herramientas que se integran con SCMs para realizar el
proceso de revisin de cdigo, como por ejemplo Reviewboard, la
funcionalidad de pull request de GitHub, rietveld, etc. Estas herramientas
permiten visualizar las diferencias que van a ser commiteadas, y realizar

108
comentarios en las lneas en cuestin para as permitir la discusin entre
autor y revisores.
Las revisiones post-commit, a diferencia de las pre-commit, sirven
para realizar discusiones en grupo sobre cambios en el cdigo que ya han
sido commiteados al repositorio. Tienen varias desventajas, como el
hecho de que cambios posteriores requerirn nuevos commits para
solventar los problemas detectados, lo cual choca con la definicin
realizada anteriormente de buenas prcticas para el uso de SCMs. Adems,
al estar el cdigo ya subido al repositorio, cabe la posibilidad de que estas
revisiones nunca se realicen o que los cambios tampoco se produzcan. Por
lo tanto, ms que para mejorar la calidad del cdigo, sirven para compartir
conocimiento entre los miembros del equipo.

El ciclo de vida: estabilizar para triunfar

Otro proceso importante a la hora de escribir cdigo de produccin
es tener un ciclo de vida definido, con distintas fases en las cuales el grado
de permisividad de los cambios que se pueden realizar vare. Es
importante que haya una o varias fases dedicadas a la estabilizacin del
cdigo, donde el objetivo es tratar de resolver problemas o fallos sin
introducir funcionalidad nueva. Para ello habr que realizar un proceso
conocido como bug triaging o bug council, donde se determinar la severidad
de cada uno de los bugs, el coste y riesgo de arreglarlo, y el tiempo
restante para liberar una nueva versin. Por lo tanto, cuanto ms cerca
est la fecha de release, ms severos tendrn que ser los bugs arreglados y
menor el riesgo de poder introducir regresiones. Esto supone una poltica
de commits controlados que sera muy difcil de hacer sin las revisiones
pre-commit. Adems, esto permitir que el nmero de commits decrezca
conforme nos acercamos a la fecha de release para as minimizar la
variabilidad del cdigo y conseguir que la calidad se vaya estabilizando. Es
frecuente observar que, en proyectos donde no existen este tipo de
procesos, el nmero de commits se mantiene estable conforme se acerca
la fecha de release, o incluso aumenta, incrementndose la posibilidad de
introduccin de fallos nuevos y dificultando en gran medida la
estabilizacin de la calidad del producto.

109
El objetivo final de los procesos descritos en este documento es
conseguir un ciclo de vida estricto con fases de desarrollo bien
diferenciadas que permitan crear software estable y mantenible. Esto es
posible si se tiene un buen entendimiento de las mejores prcticas de uso
de los sistemas de control de cdigo, y adems se emplean revisiones precommit que permitan controlar la calidad del cdigo que se modifica en el
repositorio. Esto conlleva grandes beneficios no solo para el producto,
sino para los desarrolladores tambin.
Daniel Micol (Murcia, 1984) es Experto Tecnolgico y
Tech Leader en Telefnica I+D, habiendo trabajado
previamente de ingeniero de software en Google,
Microsoft, el CERN y Caltech. Compagina el trabajo
con una tesis doctoral que espera leer en breve.
Durante su carrera profesional ha publicado ms de
veinte artculos en revistas cientficas, congresos,
captulos de libros, y patentes.