Cuando hablamos de calidad de código siempre nos planteamos un escenario perfecto, en que empezamos un proyecto desde cero, donde podemos usar TDD desde el principio, donde todo el mundo que trabaja en el proyecto tiene muy claras las normas para mantener la calidad del código y donde , evidentemente, es más importante que el proyecto sea mantenible que no llegar a una fecha en concreto. En ningún momento de mi vida he llegado a ver un proyecto con estas características, ni tan siquiera en mis proyectos personales.
La realidad es que siempre hay prisas para acabar las cosas y las chapuzas (consciente o inconscientemente) van apareciendo sin cesar. Además es bastante raro que el proyecto se haga totalmente desde 0, ya que en el mejor de los casos tendremos que usar librerías externas hechas por terceros (en el peor de los casos el proyecto ya estará empezado de hace tiempo y lo habrá tocado una cantidad ingente de programadores antes que nosotros). En conclusión, casi siempre nos vamos a tener que pelear con el legacy code
He aquí mi lista personal de trucos para mejorar la calidad del código:
1. No cambiar todo el código de golpe. Mi primer consejo para poder ir mejorando la calidad del código es que os lo toméis con calma y apliquéis los siguientes trucos solamente en las zonas de código que tengáis que tocar para arreglar otros fallos(yo normalmente uso la norma de 10 lineas por encima, 10 lineas por debajo, pero eso es una medida personal). No empecéis a hacer grandes cambios en todo el proyecto por que sino moriréis en el intento. Ya veréis como poco a poco la legibilidad de vuestro código (y por consiguiente el número de fallos) ira mejorando.
2. Mantener un estilo de código homogéneo. Da igual cual siempre y cuando todo el mundo esté de acuerdo. Indentaciones, uso de llaves, nomenclatura de variables y funciones, se ha de intentar que después de un tiempo nadie pueda distinguir el estilo de programación propio de cada programador dentro del código.
3. Eliminar los comentarios y usar nombres autoexplicativos: Durante muchos años se ha dicho que el código ha de estar bien comentado, pero realmente es un error. Los comentarios no se mantienen, pierden el significado, se copian en lugares que no deberían y acaban generando más confusión y error que otra cosa. Si el motivo para poner un comentario es para que el código se entienda mejor, tal vez la solución es hacer directamente que el código se entienda mejor: usar comentarios no es más que un parche ineficiente.
Si tenemos un código del estilo:
int a; //contador de bucle
Es mejor que el código quede como:
int contador_bucle;
4. Que las funciones hagan solamente una cosa: En muchas ocasiones se nos hace complicado separar comportamientos dentro de una función, o directamente, se añade funcionalidades a código que no estaba pensado para eso. Esto puede hacer que el reuso de código o la llamada a código desde diferentes sitios nos afecte a variables o tenga efectos paralelos no deseados con los que no contábamos. Imaginemos que tenemos una función a la que llamamos HazPan() que originariamente hacía pan, pero que con el tiempo se quedo con las atribuciones de hacer el pan, almacenarlo, distribuirlo y comercializarlo. Obviamente el nombre de la función HazPan es incorrecto y estaríamos violando el tercer principio de esta lista, pero aunque le cambiásemos el nombre (HazTodaLaCadenaProductivaDelPan) seguiría sin ser correcto debido a que el código de esa función tendría la responsabilidad de hacer demasiadas cosas a la vez. Lo lógico sería que el código quedase de esta manera, con funciones que solo tendrían una responsabilidad.
void HazTodaLaCadenaProductivaDelPan(void)
{
HazPan();
AlmacenaPan();
DistribuyePan();
VendePan();
}
Esto permite que el testo del código sea mucho más sencillo y reduce efectos colaterales al llamar a cualquier función.
5. Que las funciones sea cortas: Muy relacionado con el punto anterior está el hecho que las funciones deben ser cortas. ¿Cuánto es cortas? Depende de los gustos del equipo, del entorno de desarrollo , del tipo de proyecto,etc.... A mi, 10 lineas me va bien, pero eso es un tema que cada uno se lo ha de mirar en su caso concreto aunque nunca debería exceder el tamaño de la pantalla. Con esto se obliga a que el código de una función se pueda ver y entender con un simple vistazo (1000 lineas de función no se entienden ni mucho menos con la misma velocidad y seguridad que 10 lineas) y que aunque cada función haga una sola cosa nunca será una cosa muy muy compleja.
6. Que las funciones tengan el mínimo de parámetros de entrada necesarios: Esta norma está muy relacionada con el hecho que las funciones sean cortas y que solo hagan una cosa. Cuantos menos parámetros tenga una función, menos complejidad albergará y por lo tanto más complicado será que tengamos errores debido a llamadas incorrectas. En muchas ocasiones los parámetros que les pasamos a las funciones son redundantes y o bien no se usan todos o bien se solapan información entre ellos. Si al intentar reducir el número de parámetros ves que se te hace muy complicado o imposible plantéate que tal vez los puntos anteriores ( solo 1 responsabilidad por función, funciones cortas, etc... ) no se están cumpliendo como deberían.
7. Reducir el número de if's y código duplicado: Si somos capaces de ir reduciendo el número de if's (y de case dentro de los switchs) disminuiremos la complejidad ciclomática y si somos capaces de reducir el código duplicado favoreceremos el cumplimiento de los demás puntos anteriores. Con esto conseguiremos que el código sea bastante más sencillo de entender y por lo tanto de mantener. Un ejemplo sencillo de como hacer esto sería el siguiente:
Delante de este código...
if(condicion1)
{
if(condicion2)
{
a++;
b++;
}
else
{
a++;
c++;
}
}
else
{
a++;
c++;
}
Podríamos reestructurarlo tal que así:
a++;
if (condicion1 && condicion2)
{
b++;
}
else
{
c++;
}
Si os fijáis hace exactamente lo mismo, pero con menos código siendo bastante más fácil la comprensión.
8. Usar las herramientas adecuadas: La orientación a objetos de C++ por ejemplo o el uso de patrones de diseño está muy bien, pero mal usados (o abusados en muchas ocasiones) pueden generarnos un incremento de complejidad innecesario en el código. Usad estas herramientas solamente cuando os permitan reducir la duplicación de código o la complejidad ciclomática y usadlas solo para este fin.
9. No ser vago: Todos los trucos que os pueda explicar y toda la experiencia personal que os pueda transmitir no servirán de nada si en el momento de aplicar estas normas os ponéis en formato vago o miedoso. Si aplicáis estos trucos a medias o mal será peor que dejarlo como estaba (al menos lo que había antes estaba testeado y "seguro" que no fallaba), así que cuando os pongáis a arreglar código que no os de miedo borrar una función entera para reescribirla de nuevo, ya que en muchas ocasiones reescribir el código es la única manera para poder mejorar el código.
10. Ajustar los tiempos disponibles y necesarios: Con esto quiero decir que la variable tiempo siempre va a ser la que nos va a ir apretando para que tomemos un criterio de diseño u otro. Así que por mucho que he dicho que no se ha de ser vago tampoco se ha de ser kamikaze, si no da tiempo, no da tiempo, se apunta la zona conflictiva con una posible descripción de la solución y se archiva para cuando se tenga más tiempo, no os enfrasquéis en obras faraónicas de la programación el día antes de entregar un proyecto (ni una semana, ni un mes antes si me apuraís). Hemos de diferenciar entre ser vago y tener sentido común.
Espero que con estos sencillos consejos podáis ir mejorando la calidad de vuestro código de forma rápida y sencilla.
Espero vuestros comentarios explicando como os funciona mi método o bien con vuestras propuestas para mejorar el código.
Espero que os haya gustado
Nos vemos
0 comentarios :
Publicar un comentario