8/18/2019 Procesos Para Escribir Codigo Mantenible

1/7

procesos para escribir código mantenible y

establepor Daniel Micol Ponce

 

8/18/2019 Procesos Para Escribir Codigo Mantenible

2/7

104

8/18/2019 Procesos Para Escribir Codigo Mantenible

3/7

105

Introducción

 A la hora de escribir código que será llevado a producción, es

necesario seguir un cierto grado de disciplina que permita que dicho

código sea legible, mantenible  y correcto. Para esto proponemos una serie

de procesos que son, en cierta medida, estándares de facto en empresas

punteras en el mundo del desarrollo de software. La aplicación de éstos de

una forma correcta y estricta facilitará la escritura de código que podrá ser

mantenible a lo largo de los años, mientras que la no aplicación de dichos

procesos y disciplina dificultará en gran medida que el código en cuestión

llegue a ser un producto estable y fácil de mantener.

El objetivo final de este capítulo es permitir entender cómo realizar

modificaciones controladas y seguras del código, con el objetivo de poder

evitar su desestabilización, así como intentar no llegar a un punto en el

cual sea demasiado difícil de mantener. Para ello, vamos a describir una

serie de buenas prácticas para usar sistemas de control de código, ya que

es un elemento fundamental para poder aplicar el resto de prácticas o

procesos y tener una buena gestión del código. Seguidamente pasaremos adetallar el proceso de revisiones pre-commit , que nos ayudarán, además de a

compartir conocimiento y escribir código de mayor calidad, a tener un

cierto grado de orden y control sobre los cambios que se realizan sobre el

código. 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 código que se

modifica. La aplicación de este ciclo de vida será posible gracias alcorrecto manejo de los sistemas de control de código, así como la

aplicación de revisiones de código que permitirán el control de los

cambios que se suban al repositorio.

El SCM: ese gran desconocido

 Antes de pasar a describir los procesos en cuestión, conviene

recordar cuál es la finalidad de un sistema de control de código ( SCM  por

sus siglas en inglés) como puede ser Subversion o Git. Un error común 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.

8/18/2019 Procesos Para Escribir Codigo Mantenible

4/7

106

Este error es facilitado por sistemas más 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

cuáles se subirán y cuáles no. Por lo tanto, una práctica común es realizarcambios y cada cierto intervalo de tiempo ejecutar svn commit, a modo de

copia de seguridad. Sistemas más avanzados como Git incluyen una

gestión de cambios a subir al repositorio, en su caso conocido como

staging area   (área de montaje), en parte para evitar este tipo de malas

prácticas.

La finalidad de un SCM es la de servir como punto de gestión de

 versiones relativamente estables, atómicas y completas del código. El

grado en el que esto debe cumplirse dependerá de la estructura del

repositorio en cuestión, procesos de desarrollo, y el producto que se esté

desarrollando. Por lo tanto, únicamente los cambios de código 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 código. Esto resulta muy útil a la hora de averiguar quién

introdujo una determinada funcionalidad y cuándo lo hizo, cuándo searregló un bug  o problema, o cuántas veces se ha refactorizado una porción

de código. También es muy útil a la hora de deshacer cambios. Si el

desarrollador en cuestión 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 atómicos y contienen varios cambios que

afectan a diferentes funcionalidades, será difícil distinguir qué cambios

pertenecen a una u otra funcionalidad, y también será complicado revertir

las modificaciones a una funcionalidad concreta.

Las revisiones de código: cuatro (o más) ojos ven

mejor que dos

Una vez detallada la funcionalidad de un SCM, podemos entender

los beneficios de la aplicación de las revisiones de código. Se trata de uno

de los procesos más importantes a la hora de desarrollar software correcto

y mantenible, y consiste en solicitar a uno o más miembros del equipo que

revisen el código escrito. Existen dos tipos de revisiones de código,  pre- 

commit  y  post-commit . Las primeras ocurren antes de enviar el código nuevo

8/18/2019 Procesos Para Escribir Codigo Mantenible

5/7

107

al repositorio, ya que sólo se podrá hacer el commit cuando los revisores

hayan aprobado los cambios. Por otro lado las post-commit se realizan

después 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 podrían mejorar, inconsistencias en la arquitectura o

el estilo de código, duplicidades, etc. Realizar este tipo de revisiones

ayudan a compartir el conocimiento del código entre los distintos

miembros del equipo, ya que más de una persona habrá visto cualquier

línea que haya sido escrita, fomenta las discusiones sobre la mejor manera

de diseñar e implementar código, ayuda a tener uniformidad y sirve para

que todo el equipo aprenda del resto habiendo mayor sincronismo entre el

código que escriben los distintos miembros del equipo. Por lo tanto, las

revisiones pre-commit introducen todas las ventajas del proceso de  peer- 

reviewing   (revisión en grupo). Esto es habitual en las publicaciones

científicas y la programación extrema. Además, y como se explicará más

adelante, facilita la tarea de tener commits controlados en las fases de

estabilización del código.

Para obtener el máximo 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 revisión previa y

no sean añadidos a un commit hasta que los revisores hayan aceptado

dichos cambios. Además, será necesario el compromiso de los miembros

del equipo de intentar realizar la revisión tan pronto se les haya solicitado,

con el fin de no bloquear a los autores de los cambios en cuestión y

permitir que el código se suba al repositorio lo antes posible. Por último,

los cambios deberán ser lo más pequeños posibles con el fin de permitir

revisiones eficientes, ya que cambios largos dificultan el entendimiento de

todo el código y ralentizan el proceso de revisión.

Hay distintas herramientas que se integran con SCMs para realizar el

proceso de revisión de código, como por ejemplo Reviewboard, lafuncionalidad de  pull request   de GitHub, rietveld , etc. Estas herramientas

permiten visualizar las diferencias que van a ser “commiteadas”, y realizar

8/18/2019 Procesos Para Escribir Codigo Mantenible

6/7

108

comentarios en las líneas en cuestión para así permitir la discusión entre

autor y revisores.

Las revisiones post-commit, a diferencia de las pre-commit, sirvenpara realizar discusiones en grupo sobre cambios en el código que ya han

sido “commiteados” al repositorio. Tienen varias desventajas, como el

hecho de que cambios posteriores requerirán nuevos commits para

solventar los problemas detectados, lo cual choca con la definición

realizada anteriormente de buenas prácticas para el uso de SCMs. Además,

al estar el código ya subido al repositorio, cabe la posibilidad de que estas

revisiones nunca se realicen o que los cambios tampoco se produzcan. Por

lo tanto, más que para mejorar la calidad del código, sirven para compartir

conocimiento entre los miembros del equipo.

El ciclo de vida: estabilizar para triunfar

Otro proceso importante a la hora de escribir código de producción

es tener un ciclo de vida definido, con distintas fases en las cuales el grado

de permisividad de los cambios que se pueden realizar varíe. Esimportante que haya una o varias fases dedicadas a la estabilización del

código, 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 versión. Por lo tanto, cuanto más cerca

esté la fecha de release, más severos tendrán que ser los bugs arreglados ymenor el riesgo de poder introducir regresiones. Esto supone una política

de commits controlados que sería muy difícil de hacer sin las revisiones

pre-commit. Además, esto permitirá que el número de commits decrezca

conforme nos acercamos a la fecha de release para así minimizar la

 variabilidad del código y conseguir que la calidad se vaya estabilizando. Es

frecuente observar que, en proyectos donde no existen este tipo de

procesos, el número de commits se mantiene estable conforme se acerca

la fecha de release, o incluso aumenta, incrementándose la posibilidad deintroducción de fallos nuevos y dificultando en gran medida la

estabilización de la calidad del producto.

8/18/2019 Procesos Para Escribir Codigo Mantenible

7/7

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 prácticas de usode los sistemas de control de código, y además se emplean revisiones pre-

commit que permitan controlar la calidad del código que se modifica en el

repositorio. Esto conlleva grandes beneficios no solo para el producto,

sino para los desarrolladores también.

Daniel Micol (Murcia, 1984) es Experto Tecnológico y

Tech Leader   en Telefónica I+D, habiendo trabajadopreviamente 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 más de

 veinte artículos en revistas científicas, congresos,

capítulos de libros, y patentes.