Hola a todos,
Que es la calidad del código?
La calidad del código es aquello que hace que un proyecto sea viable mantenerlo o no.
Un proyecto sin calidad de código puede funcionar correctamente, realizar su cometido y hasta ser extremadamente eficiente realizando su funcionalidad, pero con el paso de los años nadie podrá entender ese código y se tendrá que reescribir ya que nadie será capaz de mantenerlo (ni tan siquiera su mismo creador).
No es objetivo de este post explicar como mejorar la calidad de nuestro código sino saber de donde viene los problemas. En otro post ya explicaré como se puede mejorar la calidad de forma drástica.
Formas más usuales de perder calidad de código:
- Variables o funciones sin comentarios: Para ir bien, todas, absolutamente todas las variables y funciones deberían estar comentadas (ni que sean 3 palabras) ya que sin esa referencia de para que sirve cada cosa es complicado empezar a entender el código. Junto con los comentarios de código existen dos sub-factores más:
- Código del cual no se mantienen los comentarios: A veces se modifica el comportamiento de una función y una variable y nos olvidamos de cambiar el comentario, haciendo que desde ese momento sea incorrecto y contraproducente para el mantenimiento.
- Mala nomenclatura de variables y funciones: Tan importante como los comentarios son los nombres que les damos a las variables y funciones. Da igual que nomenclatura uses siempre y cuando sea siempre la misma.
- Variables o funciones definidas pero sin usar: Otra cosa que pasa en muchas ocasiones es que desarrollamos código que al final no se usará. Motivos por los que esto pasa hay muchos, pero eso no es el problema. El problema está en que da "miedo" borrar código antiguo, aunque no se use. Cuando una tercera persona tiene que leer el código se puede volver loco para saber que funciones o variables realmente se están utilizando y cuales no, empeorando la mantenibilidad.
- Variables con un scope muy superior al mínimo necesario: Pasa también bastante que por un motivo o por otro acabamos utilizando variables globales solamente en una sola función. De por si no es malo pero puede llegar a dar problemas de mantenibilidad al hacer copypaste por ejemplo.
- "Hardcodeos" de valores: En bastante códigos podreis ver seteos de variables con un valor fijo o hacer comparaciones con un valor estático Esto no está mal de por si pero es bastante más recomendable utilizar define's o algún otro método para no tener valores hardcodeados. Si no, un cambio en estos valores puede volverse un pequeño infierno para buscar de donde venía y a donde iba.
- Usar indirecciones con más de 2 ordenes de separación (punteros triples, quadruples, etc... ). Usar más punteros y más complejos no hace que el código sea mejor. Hay ocasiones en que es necesario usar punteros sextuples (por decir algo), pero que sea necesario para el funcionamiento no significa que sea bueno para la calidad del código. Mi consejo es que si hace falta cambiéis de algoritmo pero nunca uséis más de dos niveles de indirección ya que eso imposible de seguir luego en el código.
- Código duplicado: Esta es la estrella del espectáculo. Todos lo hemos hecho. Siendo novatos o más expertos y todos tenemos la certeza que en algún momento del futuro lo volveremos ha hacer. El copypaste es malo, muy malo y cuando nos hemos dado cuenta ya tenemos 100 bloques de 5 lineas que se podrían parametrizar en una función haciendo que todo el conjunto ocupase 10 lineas.. pero no lo hacemos por pereza. Esto se debe de evitar, ya que aunque los trozos de código normalmente son bastante sencillos se ha de intentar tener ni una sola linea de código de más de lo estrictamente necesario.
- Usar GOTO: Por suerte esta práctica está casi erradicada pero en los años 80-90 aún era habitual que los programadores usaran GOTO de forma usual. No nos engañemos, os pongan la excusa que os pongan, no hay ninguna justificación para usar el GOTO, por lo tanto intentad evitarlo. Pensad que es una instrucción que de por si viene cargada directamente por el diablo (cualquier fallo tonto nos puede enviar la ejecución de código a ves a saber donde)
- Funciones con demasiado código: Todos estaremos de acuerdo que las funciones más largas son las más complicadas de entender (normalmente). El problema es que es complicado marcar un límite a partir del cual se tiene que dejar de aceptar un código como bueno. He leido en más de un sitio que las funciones no deberían ocupar más de 200 lineas, yo soy bastante más estricto y creo que más de 20 o 30 es un error. A fin de cuentas, es un criterio personal, solamente sed consecuentes y estableceos un máximo de lineas que realmente os permitan entender el código como dios manda.
- Módulos con demasiadas funciones: De la misma manera que con el código, un archivo con demasiadas funciones no es demasiado legible. Cuantas? Depende. Yo nuevamente soy de la opinión de un máximo de 20 funciones por archivo, aunque es un tema que reside en vuestra capacidad de análisis de código, así que lo dejo a vuestra discreción (id probando hasta que veais que realmente podeis entender el código rápidamente)
- Complejidad ciclomática alta: La complejidad ciclomática es un tema tan extenso que permitiría hacer un articulo solo para el y aún me quedaría corto. A modo de resumen solo deciros que es una medida de cuan enrevesado es el código. Una complejidad ciclomática alta es sinónimo de código immantenible y de necesitar un altísimo número de test para verificar que el funcionamiento del código es correcto. En posteriores artículos hablaré más sobre el tema.
- Ausencia de test automáticos y revisiones de código: Si programas solo es muy normal que nadie te revise el código, pero ni que sea ese tu caso utilizar tests automáticos que te prueben unos mínimos a tu aplicación siempre te irán bien. Si no, tienes la posibilidad que los errores se te vayan acumulando y que los veas cuando ya sea demasiado tarde.
- Abuso innecesario de patrones de diseño: Este error es muy divertido por que afecta a gente que lleva años prorgamando más que a los novatos como tal. Cuando alguien que tiene experiencia en programación descubre lo que són los patrones de diseño, alucina. Le ve un potencial impresionante y se enfrasca a usar patrones de diseño para todo. Normalmente este situación acaba en un código ortopédico de mucha "belleza visual" pero poca utilidad práctica y además con unos tiempo s de producción horribles. Esto no quiere decir que los patrones de diseño sean malo, ni mucho menos. Son extremadamente útiles, pero se han de usar en la justa medida.
- No seguir la filosofía KISS : Se que esto parece muy dogmático, pero realmente, si no se sigue el principio KISS es bastante complicado que en un proyecto grande se consiga el código mantenible. Para más información mirad el artículo que hice en su momento sobre KISS.
- Demasiada deuda técnica: Si trabajamos con código antiguo, tocado por muchas manos o sencillamente al que se le ha dado más importancia a la velocidad de producción que a la calidad de esta, tenemos un problema. Para más información mirad el artículo sobre deuda técnica.
- Falta de objetividad en la evaluación de la propia calidad del código: De todas las cosas que he explicado esta es casi la única que es inevitable. El código es sangre de nuestra sangre y casi siempre le veremos con buenos ojos. Es por ello que es muy necesario automatizar el testeo de todas las características anteriormente citadas para que de una forma objetiva podamos analizar el código y decidir si estamos mejorandolo o no. Sin esto, es imposible que se pueda mejorar el código de nuestro proyecto.
Finalmente, si veis que en vuestros proyectos pasan demasiadas de las cosas que hay en esta lista: TRANQUILOS,QUE NO PANICO EL CUNDA!! :D. Hay maneras de solucionar estos problemas de manera automática que ya os iré posteando.
Espero que os haya gustado
Si os gusta el tema siempre le podéis echar un ojo a alguno de estos libros:
Nos vemos
P.D : Si creéis que falta algo poned un comentario explicándolo.
0 comentarios :
Publicar un comentario