La Idealización del Código

O creer que el código de otros es una maravilla.

Todo desarrollador de software a medida que progresa sus habilidades va entendiendo que su código actual es mejor que el de hace algunos años atrás.

Pasa que volvemos a ver código pasado y nos da pena lo que escribíamos. Cómo resolvíamos ciertas cosas muy diferente a como lo hacemos actualmente.

Con el pasar del tiempo, comprendemos que «no somos tan buenos» como creemos. Siempre habrá alguien que hará las cosas mejor que nosotros. Alguien que escribiría el código de manera prodigiosa, elegante y formidable.

Y es la realidad. Nada de malo en ello.

Esto nos puede llevar a creer que ciertas personas o proyectos tienen código hermoso, excelente, maravilloso, perfecto. Uno gasta horas leyendo cómo mejorar nuestro código, hacerlo más elegante, más corto, más auto legible, cómo implementar un patrón de diseño, cómo no repetir tanto o cuando decidir hacer abstracciones.

Es bueno que pensemos en ser mejores profesionales del desarrollo de software. Es muy bueno. Siempre hay que buscar la excelencia profesional, la cual trae como beneficio mejores capacidades para resolver problemas con menor gasto de tiempo y esfuerzo o de la mejor manera posible que tal vez antes desconocíamos.

Solo que esto tiene una realidad que puede resultar chocante.

Cuando creemos que en ese proyecto donde hay personas que relacionamos con código de calidad, con buenos procesos y prácticas, pero en realidad hay más de lo mismo. Más empanadas, más código espagueti, nada de buenas prácticas, nada de documentación, cosas enredadas, comentarios que están desactualizados, clases muy complejas, métodos extremadamente largos, etc, etc.

Foto de Amy Elting.

No hay nada más chocante que tener la idea de un código que debería ser perfecto y no lo es.

A veces creemos que por no saber patrones de diseño no seremos capaces de escribir código de alto nivel y resulta que hay código en proyectos importantes y enormes donde eso no tiene relevancia.

Ni la tendrá.

¿Por qué pasa esto?

Primero que nada, somos humanos. Escribir código es de las cosas más humanas que pueda haber. Lo que escribimos es la interpretación de un problema y la forma en cómo visionamos su solución en un espacio de tiempo.

Somos propensos a cometer errores en nuestras vidas normales, del mismo modo introduciremos errores en nuestro código. No hay escape.

Otro motivo puede ser que a medida que el proyecto crece habrá más razones y más espacio para complicar las cosas.

Ya lo dijo Sandi Metz:

Big things can only get bigger.

Entre más crece el proyecto más probable será encontrar empanadas y código espagueti. Es la naturaleza de esto.

¿Es todo esto malo? No necesariamente. Así como en nuestras vidas hay cosas que se dan con naturalidad porque es la forma en como esta se desenvuelve, lo mismo pasa en proyectos de software.

El ciclo de vida del software es nacer, crecer, seguir creciendo hasta que eventualmente caduca. Durante todo ese tiempo de crecimiento pasarán muchas cosas y es donde aparecen las empanadas. Esas empanadas pueden ser manejadas y mejoradas o simplemente se dejan ahí porque no afectan el funcionamiento del mismo.

Hay que aceptarlo y aprender a vivir con ello.

En muchos proyectos no hay tiempo suficiente para resolver un problema de la mejor forma posible, no tenemos las habilidades o hacerlo de esa forma más «elegante» puede complicar todo aún más (de pronto es un código que interactúa con muchos otros sistemas).

Foto de Macau Photo Agency.

Los afanes del día a día, los cambios constantes en requerimientos, los cambios en los miembros de los equipos, pocas buenas prácticas de colaboración y compartir el conocimiento de partes específicas, falta de actualización con respecto al lenguaje de programación o framework de desarrollo son algunas de las causas por las cuales se introduce código empanada en toda clase de proyectos.

Otra cosa que puede resultar (en raras ocasiones) entorpeciendo el avance de proyectos y dificultando la colaboración en los mismos es cuando las mejores prácticas son abusadas. Los patrones de diseños y conceptos como SOLID son buenos cuando se aplican bien al contexto y cuando no se abusa de ellos. El hecho de que existan no significa que vayan a solventar cualquier problema para organizar el código fuente.

Abusar de patrones es tan dañino como no usarlos.

¿Hay forma de evitarlo?

Creería que más que evitarlo es reducir sus incidencias. Un proceso sano de code review puede bajar la cantidad de veces que ingresará código espagueti al proyecto.

Usar linters o herramientas de análisis de código puede sentar las bases para establecer la forma en cómo se debe organizar y escribir ciertos aspectos del mismo. Estos linters deben aplicarse mediante comandos de consola en hooks de Git o por otro software que analiza el código próximo a unirse mediante un Pull Request.

La programación en parejas también es una forma de reducirlos. Al discutir la implementación en el momento con alguien más se puede llegar a consensos para no ingresar código espagueti.

Si en el equipo de trabajo hay un líder o líderes que se encarguen del bienestar y salud de la base de código, el ingreso deliberado de empanadas se reducirá drásticamente. Un líder de equipo velará porque el equipo esté contento y entregando a un ritmo adecuado y además que el código en general no se llene de cosas que con solo verlas nos duela la cabeza.

Foto de Bill Oxford.

En una base de código sana y con buena calidad cambios futuros son mucho más sencillo de ingresar y habrá menos temor en mover o cambiar cosas.

Al final de cuentas, creo que no hay forma de impedir que haya código «feo» al 100% porque siempre habrá algún motivo que facilite que se cuelen tales «defectos», sin embargo, debe haber procesos continuos de mejora en los ciclos de trabajo para facilitar a los desarrolladores para que cuenten con tiempo para resolver tal código de baja calidad.

Por ejemplo, tener un backlog de errores y cosas a mejorar y que en cada ciclo una de las tareas sea solucionar alguno o como hace Basecamp que en un período de dos semanas se dedican a solo resolver errores y mejorar el código.

Aprender a Vivir con Código «Sucio»

Hay muchos libros, artículos, vídeos, tutoriales, repositorios con ejemplos en donde podemos ver, leer y aprender sobre las que se entienden son las mejores prácticas al escribir software:

• Clean Code
• DRY
• KISS
• SOLID
• Patrones de Diseño
• etc

Todas esas nociones son muy buenas y bueno que un desarrollador se interese por entenderlas y aprender a implementarlas en los proyectos en los que trabajan.

También debemos aprender y entender que en todo software hay y habrá código que va en contra de todo aquello. Cuando lo veamos nos dolerá la cabeza y se retorcerá el estómago pero debemos preguntarnos ¿por qué está así? ¿qué hizo que la persona escribiera eso: falta de tiempo, falta de talento, era lo mejor en el momento?

Hay muchas razones por las cuales el código espagueti ingresa a una base de código y algunas serán más válidas que otras. Como desarrolladores de software debemos aprender a vivir con ello y buscar formas de evitar que suceda en menor cantidad.

Lecturas al respecto:

• Clean, DRY, SOLID Spaghetti
• You don’t believe in Clean Code
• Are There Actually Companies out There That Write Good Code?