Cuando empezamos a programar ( sea en el lenguaje que sea) no le damos demasiada importancia a la calidad del código. De hecho cuando somos jóvenes en el ámbito de la programación ni tan siquiera somos capaces de ver que tenemos problemas en la calidad de nuestro código hasta que ya es bastante tarde.
No es hasta que llevamos un tiempo desarrollando y los proyectos empiezan a obtener una cierta entidad en el tiempo de desarrollo y en el volumen de lineas de código que nos damos cuenta que las cosas no marchan bien.
Cada vez cuesta más hacer cambios. Cada vez con más frecuencia aparecen fallos y estos son más complejos. Hasta que llegamos al punto de darnos cuenta que la calidad de nuestro proyecto es extremadamente baja.
Pero.. que podemos hacer? Si seguimos estos sencillos pasos (sencillos como concepto, la aplicación nunca es tan sencilla :) ) que te explicaré a continuación podrás generar un código limpio , con alta calidad y que permitirá poco a poco ir mejorando el código ya existente.
Duplicación de código: La duplicación de código es el típico copy-paste de toda la vida. Que problema tiene? Que cuando hacemos copiar-pegar lo que estamos haciendo es incrementar innecesariamente la cantidad de lineas de código y por ende, la complejidad.
Falta de tests (unitarios o TDD): Es muy normal desarrollar sin implementar test, demasiado normal. Esto hace que los desarrollos se vuelvan inestables y a tientas. Es como hacer malabarismos a 20 metros de altura sin red de protección. O sabes muy bien lo que haces o mueres.
Alta complejidad ciclomática : La complejidad ciclomática es una de las medidas más extendidas para medir la calida de código. Mantener la complejidad ciclomática controlada no asegura que tu código sea bueno, pero tener una complejidad alta asegura que tu proyecto va a acabar en desastre más tarde o más temprano.
Funciones extremadamente largas y complejas : No recuerdo quien dijo que el código : "es un texto que ha de leer una persona y que eventualmente sirve para ejecutar algo". Lo más importante del código es que sea legible e inteligible. Funciones de 1000 linias de código, o con estructuras de código demasiado enrevesadas hacen que esas funciones se transformen en "intocables". Trozos aberrantes de código de tiempos prehistóricos que nadie entiende y que nadie se atreve a tocar que limitan el desarrollo del proyecto y que son fuente de gran cantidad de bugs de forma directa o indirecta.
Nombres poco claros : Los nombres de las variables y las funciones han de ser claros y autoexplicativos y por supuesto, han de ser veraces. Llamar a una función sghkfersc12() por que son las siglas en sueco de la empresa a la que va destinada el código tal vez tenga sentido en un momento muy concreto de la historia del proyecto, pero tiempo después ese nombre no sirve para nada que no sea generar confusión.
Funciones que parasitan funcionamientos ajenos : Con el tiempo siempre hay nuevos requisitos que hay que meter con calzador en el código y no siempre es trivial reestrucutrar el código para que todo tenga sentido. Es decir, con el tiempo la función HazPan() que en un inicio hacia pan, es muy posible que acabe comprando la harina, haciendo el pan, distrbuyendo las barras de pan a los comercios locales y yendo al banco a pagar la factura del gas. Creo que ha quedado claro lo que quiero decir :).
Parches : Los parches nunca son deseables pero pocas veces son evitables si se ha de apagar un fuego rapido. El problema es que la deuda técnica que se genera en muchas ocasiones no se paga quitando el parche y haciendolo bien sino que se recita el mantra de : "no lo toques, si funciona no lo toques"
Abuso de comentarios: Los comentarios son correctos y necesarios para explicar cosas ajenas al código. Situaciones tecnicas o comerciales que impulsan a hacer cosas "raras" que no se podrían justificar de otra manera y que no son evidentes a siemple vista, poner la bandera de alerta en alto en sitios críticos, etc... El gran problema es que los comentarios se usan como parches a la legibilidad del código. "Como el código no se entiende, no mejoro el código, pongo un parche y así queda claro". Posteriormente, el comentario se puede copypastear de forma erronea, se puede quedar desfasado por que el código se ha cambiado pero el comentario no, etc...
Darle poca importancia a los Code Review: En muchas ocasiones el CR se considera un trámite menor cuando realmente es una de las mayores herramientas para asegurar que la calidad de código que introducimos en el sistema cumple con unos mínimos.
Espero que os haya servido, iremos ampliando.
Nos vemos en el blog.
