El número de líneas de código no es tan significativo

Por Carlos Blé Jurado

Tras leer el libro Clean Code, muchas personas se quedan con la idea de que las funciones deben de ser cortitas, no más de 4 o 5 líneas. Las clases también deben de ser pequeñitas, con unos pocos métodos. En realidad, el número de líneas no deja de ser una heurística, al igual que lo es el porcentaje de cobertura de test. No existe el número perfecto que funcione siempre bien para todos los casos. No podemos tomar esos números como verdades absolutas universales, porque hay contextos en los que no aplican.

He visto diseños empobrecidos, forzados, para que todas las funciones fueran muy cortas y las clases muy pequeñas. Así hasta el punto de que una responsabilidad estaba esparcida por varios métodos o por varias clases. Esto produce una pérdida de cohesión en métodos, clases y paquetes, a la vez que genera un nivel de acoplamiento que dificulta el mantenimiento. No hay nada malo en que un fichero llegue a tener 1000 líneas de código o en que una función ronde las 40 líneas de código. Es peor introducir abstracciones artificiales que añadan indirección innecesaria al código y que confundan al lector con nombres rocambolescos. Cuando una abstracción no entra ni con calzador, es imposible encontrar buenos nombres para ella. Si tenemos que priorizar heurísticas, prioricemos que el código sea legible, que los nombres sean expresivos y que la intención de quien programa quede clara. Que el código no de sorpresas, que el nivel de cohesión sea alto y el de acoplamiento bajo. Cuando todo eso esté bien trabajado, entonces podemos utilizar el número de líneas como refuerzo para volvernos a preguntar si el diseño es adecuado. Un exceso de líneas de código podría ayudarnos a detectar que un método tiene demasiadas responsabilidades, siempre y cuando lo hayamos terminado de implementar. El mejor momento para refactorizar un método o una clase que tiene más de una responsabilidad, es cuando se ha terminado de implementar su funcionalidad, no cuando estamos a medio camino. Durante el proceso lo que tenemos que buscar siempre es la simplicidad, teniendo en cuenta que simplicidad no necesariamente implica menos líneas de código. Que un bloque de código sea grande o pequeño es muy subjetivo, lo que no es subjetivo es lo que le cuesta a una persona nueva en el proyecto entenderlo. Hacer revisiones de código con personas que no lo han escrito, es un ejercicio muy beneficioso. Hay varias formas de hacerlas, desde reuniones de equipo compartiendo pantalla hasta pair programming cambiando de compañeros con frecuencia.

Los números nos pueden dar pistas, pero no deben llegar a estropear el diseño. Sucede lo mismo con los porcentajes de cobertura de test, que el número no es nada relevante comparado con la calidad de los test. He visto proyectos donde para conseguir X% de cobertura, se hacían todo tipo de guarradas en el código de producción y en los test. Incluso he visto test sin asserts, para elevar el porcentaje de cobertura registrado por el analizador sin estar probando nada en absoluto. Este es el peligro de decir que un porcentaje de cobertura adecuado es 80% o 90% o el número que sea, que la gente se intenta ceñir a ese número y se olvida de lo que es más importante.

En nuestro libro, código sostenible, encontrarás toda una serie de principios y heurísticas para hacer que tu código sea más fácil de mantener, más allá de números estimativos.