Como mejorar la calidad del código

Artículo perteneciente a la sección de calidad del código
Artículo intimamente ligado al artículo   ¿que es la calidad del código?


Hola a todos,

Si habeís seguido los post de la sección de calidad de código ya teneís claro que es la calidad de código, como evaluarla  y por que es necesario mejorarla, pero.. como la mejoramos??

Este es un tema que se ha tratado en infinidad de ocasiones tanto por empresas como por particulares y grupos de software libre. El tiempo que tenemos para dedicar a un proyecto es limitado (ya sea por que forma parte de nuestro tiempo libre o por que conforma nuestra jornada laboral) y por lo tanto un recurso valioso a optimizar. Si estamos en una empresa cada hora de trabajo es dinero,  si programamos por ocio cada hora de dedicación que nos falta es una posibilidad de frustrarnos y abandonar el proyecto. Así que, está claro que a todos nos interesa.

Metodologías para mejorar la calidad del código:

- TDD: Test Driven Development (Desarrollo guiado por test), o lo que es lo mismo, primero hacer los tests y luego hacer programas que cumplan con esos test. Parece una tontería y una perdida de tiempo pero realmente lo que te permite es programar más tranquilo sabiendo que esos tests en cualquier momento te dirán si lo estás haciendo bien o no. Elimina en gran parte el problema de tocar una función que afecte a otras. Ya haré otro artículo para hablar de TDD más en detalle.

- Integración continua: Esto es la madre del cordero. Un servidor de integración continua (también llamado servidor de compilación) es un servidor que se encarga de bajarse el código del svn , compilarlo y aplicarle test. Los test básicos que aplicará será los que habremos definido en TDD, que serán sencillos y en segundos nos podrá dar un resultado pero también puede aplicar test más largos (por las noches por ejemplo) que aseguren estabilidad o casuísticas raras y complejas. Con esto gran parte de las pruebas que se tienen que hacer al software se harán automáticamente, pero no al final del desarrollo, sino en todo momento, descubriendo los fallos mucho antes.


- Análisis estático: El análisis estático es más o menos lo que es explique cuando os comenté que era la calidad del código. No son más que consejos y buenas prácticas de programación que nos permiten mecanizar la búsqueda de fallos en el código. Nos permiten dar una visión objetiva al código y se pueden ejecutar junto con los test de TDD en el servidor de integración continua.

- Refactorización: La refactorización del código no es más que limpiar el código, es decir, cambiar su estructura sin cambiar su funcionalidad. Este es un proceso peligroso (de ahí la necesidad de los test de TDD) pero necesario para la mantenibilidad. Le hemos de perder el miedo o la vagancia a tocar el código. Por mucho que el código funcione, si el análisis estático (por ejemplo) nos dice que tendremos muchos problemas de mantenibilidad hemos de invertir tiempo en mejorar el código, ya que si no, cuando menos nos demos cuenta todo el castillo se nos habrá caido encima.


- Programación por parejas:   Esta es otra cosa que parece una perdida de tiempo, pero que realmente va bastante bien, ya que cuando uno programa el otro revisa, y cuando a un problema no se le ve solución fácil, la otra persona puede aportar ideas en las que no habíamos ni caído  Adicionalmente ayuda mucho a la formación.  Obviamente si estás solo en casa es más complicado... :D

- Revisión de código: Está muy emparentado con la programación por parejas y los test. Sencillamente significa que una persona que no ha tocado el código se lo lea y diga su opinión. El svn de google , por ejemplo, permite hacer revisiones de código encima de lo que hay subido, permitiendo que la comunidad revise lo que se está haciendo.

- Plazos de entrega: Si estás trabajando para una empresa tranquilo que ya te darán plazos de entrega :D, si programas por ocio es muy recomendable que te marques tiempos de entrega propios (sin estresarte), en que puedas enseñarte a ti mismo y  a la comunidad lo que llevas hecho hasta el momento. Sobretodo, que funcione. Nada de cosas a medias. Mejor que no esté hecho,  a que esté casi hecho.

- No al "multitasking": Tanto en la vida profesional como en la del ocio es muy normal tener 84 cosas en la cabeza. Bien. Está más que demostrado que una persona puede hacer "bien" 2 cosas a la vez, no te pidas más. Si piensas en el motor de audio, gráfico, fisicas, IA y XML todo a la vez y vas saltando de un código a otro cada 5 minutos no acabarás nada, pero además lo que generes será basura. Es mejor centrarte en un tema (como mucho darle vueltas a otro de mientras) y ya está. Que por temas personales no puedes? No pasa nada, no lo hagas. Haz cosas más sencillas, diseña tests o dale vueltas a como diseñar el achilipú cuántico que te hará falta para tu juego, pero no programes con demasiadas cosas en la cabeza.

Espero que os haya gustado. Si se os ocurren más maneras de mejorar el código no dudeis en hacermelo saber.

Bibliografía recomendada para este artículo:


Nos vemos