Vida y muerte del buen código

Este artículo está dirigido a todos aquellos que se inician en la programación o desean contar con una guía rápida para la revisión de la calidad del código.

En un día de reflexión, recostado en el sofá y después de unas cervezas, curiosamente no recordé los días de gloria en el fútbol ni los sueños frustrados de ser una estrella de rock. Aun así, no podía evitar el ruido que resonaba en mi cabeza, como martillazos que se volvían cada vez más intensos. En ese momento recordé a mi yo más joven: atlético, soñador y decidido, pero inexperto y torpe en la programación. Por un instante, volví a sentir la misma sensación de estar perdido en aquel momento, sin saber a quién preguntar ni a dónde acudir, con el temor de que los demás descubrieran mi gran secreto, aunque este era evidente para todos: mi inexperiencia. Cuánto hubiera deseado contar con una guía paso a paso que me ayudara a sobrellevar esos días. Esta es la razón de este artículo: sencillo pero efectivo.

Venciendo el síndrome del impostor

El síndrome del impostor, que se manifiesta cuando uno se exige demasiado, cuando se encuentra en un entorno de ritmo rápido y no sabe cómo mantenerse a la par, solo vives por un dia más. Seguro se pregunta, ¿cómo se relaciona esto con la programación? Es fácil mencionar antipatrones y malas prácticas, pero es aún más fácil decir: “Solo sé que este código funciona, no sé cómo, pero funciona”. Seguro que en este momento les resulta familiar esta frase, lo sé porque a mí me sonó así durante varios años.

Ejemplo: Imagina a un programador novato que se siente abrumado por la cantidad de términos y conceptos técnicos en un proyecto. Siente que no está a la altura de sus compañeros y se exige demasiado para intentar igualar su nivel de conocimiento.

Que el remedio no salga más cara que la enfermedad

Es común caer en la desesperación y resolver los problemas con prácticas aprendidas a través del sudor, lágrimas y errores en el camino. Casualmente, esta es la forma más rápida de aprender, pero si alguien les pregunta: “¿Por qué lo haces de esta manera?”, seguramente responderían: “Porque así funciona”.

El buen código es simple

En algún momento, un amigo me dijo: “El código es como escribir”. todos saben escribir, pero algunos saben escribir con buena ortografía y unos pocos son capaces de redactar un libro. En lugar de escribir un código complicado y confuso para resolver un problema, es preferible escribir un código simple y claro que todos los miembros del equipo puedan entender fácilmente. Por ejemplo, en lugar de utilizar bucles anidados y condiciones complejas, se puede utilizar una estructura de código más simple y directa.

El ABC de la ortografía del buen código

Partiendo del hecho de que escribir código va más allá de hacer que las cosas funcionen; es el arte de hacer que otros entiendan lo que quieres expresar. Al dar nombres a variables y funciones, es importante utilizar nombres descriptivos. Por ejemplo, en lugar de nombrar una variable “x,” es preferible nombrarla “contador_de_facturas” para que otros programadores puedan comprender su propósito.

Consejos para mi yo del pasado

Los fundamentos siempre serán la base de todo lo que es y de todo lo que llegará a ser. En otras palabras, la habilidad para mantener, escalar y hacer crecer una aplicación que perdure en el tiempo. Y ahora, ¿qué hago?

Comenzar por la semántica siempre es una buena idea. Que todo tenga sentido. Veamos un ejemplo: “Supongamos que nos piden crear una funcionalidad que permita a un usuario crear una factura y anularla”. Para desarrollar este ejercicio, lo abordaremos en una revisión por etapas, con el propósito de lograr un código limpio y claro.

Estructura jerárquica: Comience por definir una estructura de carpetas que describa lo que se pretende hacer. Por ejemplo, si se trata de una funcionalidad de facturación, es posible que se nos soliciten más funcionalidades en el futuro. Por lo tanto, describa una estructura genérica que cubra lo que se está solicitando y prevea posibles casos relacionados.

Ejemplo 2: Estoy trabajando en un proyecto de software para una empresa de logística. En este proyecto, tienes que gestionar el seguimiento de envíos, el inventario de almacén, la facturación y la administración de clientes. Dado que el proyecto es grande y complejo, necesitas organizarlo de manera eficiente para que sea fácil de entender y mantener.

  TiendaEnLinea
  |-- Productos
  |   |-- GestionProductos.java
  |   |-- DetalleProducto.java
  |-- Pedidos
  |   |-- GestionPedidos.java
  |   |-- DetallePedido.java
  |-- Clientes
  |   |-- GestionClientes.java
  |   |-- DetalleCliente.java
  |-- Envios
  |   |-- GestionEnvios.java
  |   |-- DetalleEnvio.java
  |-- Main.java

Nombres de variables: Evite nombrar variables con una sola letra o dos. No utilice términos técnicos como “insert,” “save” o “read.” Recuerde que está describiendo los pasos de una receta (funcionalidad). Use nombres relacionados y términos dentro de la receta.

Ejemplo: En un código relacionado con el procesamiento de imágenes, en lugar de utilizar nombres como “img1” o “tmp,” es recomendable nombrar las variables como “imagen_original” o “imagen_temporal” para que se entienda claramente su función.

Declaración de métodos: Recuerde que los métodos son verbos que ejecutan acciones y por lo tanto, deben comenzar con un verbo.

Ejemplo: Cuando se crea una función para calcular el promedio de una lista de números, es apropiado nombrarla “calcular_promedio” en lugar de simplemente “promedio.”

Revisión de la arquitectura: Apoyarse en las arquitecturas existentes para validar las estructuras. Aunque estas arquitecturas proponen ciertos nombres, es su responsabilidad garantizar que cuando alguien lea la estructura y el código, lo entienda con facilidad.

Ejemplo: Al desarrollar una aplicación web, es importante seguir alguna arquitectura como puede ser MVC (Model-View-Controller) para mantener una estructura clara y coherente en el código. Esto facilita la comprensión y colaboración entre desarrolladores.

Respetar la uniformidad: No mezcle diferentes estilos de escritura. Si comienza a utilizar una convención de nombres para métodos y variables de cierta manera, conviértala en el estándar para futuras funcionalidades. Mantenga la misma estructura gramatical.

Si se ha adoptado una convención de nomenclatura para nombrar variables y funciones en un proyecto, es esencial respetar esa convención en todas las partes del código. Por ejemplo, si se ha decidido utilizar el formato “camelCase,” se debe mantener esta convención en todo el proyecto.

Menos es más: Si nota que está escribiendo mucho código y luego le lleva más de cinco segundos leerlo, es posible que pueda dividir este código en fragmentos más pequeños para evitar la fatiga visual y aumentar la comprensión.

Ejemplo: Si tienes una función larga que realiza múltiples tareas, es recomendable dividirla en funciones más pequeñas, cada una encargada de una tarea específica. Esto hace que el código sea más legible y más fácil de mantener.

Revisión par: Sabrán que su código tiene buena calidad cuando se lo entreguen a otra persona que no conozca lo que están haciendo y esa persona pueda describir la funcionalidad escrita rápida y sin esfuerzo en sus propias palabras.

Ejemplo: Antes de enviar el código para su revisión, dos programadores pueden colaborar en la revisión del otro. Uno puede leer el código del otro y asegurarse de que sea comprensible y siga las mejores prácticas.

Felicidades por llegar hasta el final. Más que una guía sencilla y efectiva, esto es una reflexión para entender que “lo que hace un programador no es simplemente programar”, sino escribir para describir algo para alguien más, que incluso podría ser usted en el futuro.