Continuous Integration System ¡Qué buen programador que soy! [1ª parte – reflexión]

Hacía tiempo que no escribía una entrada en este blog (igual que en el otro), y no será por no tener cosas que explicar, pero el tiempo como siempre es justo. Esta primera parte del artículo es más bien a una reflexión personal a partir de la experiencia, y que nos introducirá la segunda parte del artículo que es la integración de Jenkins y Symfony2.1.

¡Qué buen programador que soy!

Seguro que más de una vez habéis escuchado esta expresión de un programador. Pero ¿cómo podemos evaluar lo bueno que es un programador?. Primero de todo aclarar que no me considero “programador”, aunque siempre me he dedicado a la programación, me considero desarrollador. Ya desde hace tiempo soy partidario de no reinventar la rueda, y si hay algo que ya funciona es mejor adaptarte a ello, y dentro de lo que sea posible colaborar con la comunidad. Siempre cien cabezas pensarán mejor que una.

Los lenguajes de programación han evolucionado mucho en los últimos años, y aunque algunos arrastran una mala fama (como PHP) su extensión y popularidad permiten su acceso a prácticamente cualquier iniciado de la programación. Aquí llega el primer problema, ¿cómo considerar que código que estamos haciendo es bueno, y sobretodo, como consideramos que este código seguirá siendo bueno en el futuro?.

Por desgracia, en este país, globalizado por consultoras, conocidas como carnicerías, que vende el “kilo de informático” al más alto precio al cual remunera con el mínimo coste termina incentivando a que nuestro “sello de calidad” sea la ñapa. El entregar el producto  lo antes posible y los continuos cambios de requerimientos en el producto, hacen que esta profesión termine siendo una pesadilla.

Pero por suerte, descubrí que hay otras formas de programar y trabajar como el desarrollo ágil o el TDD, aunque sea desde la soledad.

Pruebas unitarias

Durante los estudios nos enseñan a realizar test de prueba a nuestros códigos, pero cuando entramos en el mundo laboral, las pruebas terminan siendo las que hacemos nosotros mismo durante el desarrollo del código y una vez terminado, no volvemos a revisarlo hasta que nos notifican de un BUG.

Las pruebas unitarias son pequeñas porciones de código que nos simulan el acceso a ciertas partes de la aplicación, así como la simulación del comportamiento de un usuario: clic en un enlace  rellanar un formulario, comprobar que los datos enviados corresponden a los guardados. Y además tenemos la ventaja, que en cualquier momento del desarrollo podemos lanzar todas estas pruebas y comprobar que todas las partes del programa continúan comportándose tal como deberían.

Pero también hay que decir que la escritura de las pruebas unitarias no son sencillas comparado con hacer una prueba frente la pantalla y con el ratón. Hay que saber distinguir las partes que se renderizan del código, así como saber buscar e identificar los enlaces correspondientes. Para los que sois linuxeros, es como navegar una página web en modo texto, como con Lynx, puedes “descifrar” su contenido, pero para llegar hasta un enlace te puedes volver loco.

Continuous Integration System

Bueno, visto lo que son las pruebas unitarias, descubrimos el Continuous Integration System, que no es más que una máquina que se encarga de efectuar las pruebas unitarias de forma programada (cron) y nos muestra (con posibilidad de noticiación por email), cuando no se pasan los test.

En el mercado existen muchos servicios o software de integración continua: Travis, Sismo (de los creadores de Symfony), Bamboo (comercial)  o Jenkins. En mi caso, me decanté por Jenkins, primero por que se puede instalar localmente, es gratuito y por que gráficamente me gustó (soy un apasionado de las gráficas y estadísticas).

La posibilidad de programar la ejecución de los test de forma periódica nos permite que, como habitualmente pasa, se cambien partes de una aplicación, asegurarnos antes de subir código a producción de que otras partes no van a dejar de funcionar.

La calidad de nuestro código

Los servidores de integración continua como Jenkins nos permite además poder evaluar la calidad de nuestro código:

  • Errores de estilo (variables cortas, parámetros no tractados).
  • Funciones o variables no utilizadas.
  • Procedimientos no implementados.
  • Código no documentado.
  • Dependencias.
  • Etc…

En la práctica

La pruebas unitarias han de ser prácticamente de obligada realización. Es como empezar un proyecto sin escribir la documentación de este o haber hablado con el cliente, vale, que es tiempo dedicado que “no avanza el proyecto” (me remito a técnica de consultora), pero más vale hacer medio paso seguro, que avanzar dos y luego retroceder tres.

En cuanto a la evaluación de código, siendo sincero, si desde un principio del proyecto no utilizas esta evaluación de código te vas a volver loco. Como práctica es muy aconsejable, ya que te permite ir mejorando la calidad, pero tampoco se ha de convertir en una obsesión.

En la segunda parte del artículo

Tras esta reflexión personal, y de la experiencia con la nueva web de Clubmazda, os intentaré explicar los pasos para que podáis evaluar vuestro código de Symfony2.1 con Jenkins desde cero.

Podeis leer la segunda parte aquí.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s