Tu código como forma de comunicarte
Este artículo lo tienes también disponible en inglés aquí.
This articule is also available in English here.
Perfecto, eres desarrollador, ¿y si te dijera que tu trabajo no es sólo un trozo de código sino una manera de comunicarse en sí misma?
Bueno, estoy casi seguro lo que estas pensando ahora mismo:
“Tío, ¿te crees que has descubierto la rueda? ¡Mi código es como hablo con mi ordenador y todos sabemos eso!”
Y eso no lo dudo, el código por sí mismo es la manera en la que nosotros los desarrolladores hablamos con los ordenadores para decirles lo que queremos hacer, ¡pero eso es sólo la punta del iceberg!
El código es una manera de comunicarse con un ordenador, con otras herramientas, con otras personas y contigo mismo (ahora mismo, en un futuro cercano, ¡E INCLUSO en unos meses!).
Hablando con mi ordenador
Rara vez (o nunca) hablamos con nuestras CPU usando su lenguaje natural (Espero que nadie intente escribir una API REST solo con código máquina…), pero usamos estos intérpretes para traducir nuestro código humano a código máquina. Este puede ser literalmente un “intérprete” para los lenguajes de scripting que son interpretados en tiempo de ejecución como Python o JavaScript. O usamos un traductor: un compilador como en Go o C++.
Hablamos con nuestros ordenadores dándoles una lista directa de instrucciones para la CPU.
Imagina que escribes una lista de tareas de lo que quieres hacer hoy, por ejemplo:
- Comprar comida.
- Si la nueva película de Marvel ha salido en cine, ir a verla esta noche.
- Limpiar la cocina.
¿Pero qué sucede si la lista de tareas no es lo suficientemente clara, ambigua o incluso no tiene sentido?
- Comprar la cocina.
- Si la nueva comida ha salido en cine, ir a verla esta noche.
- Limpiar la nueva película de Marvel.
Si queremos que nuestro código haga exactamente lo que queramos, tiene que ser perfectamente claro y sin ninguna ambigüedad para que tus instrucciones se lleven a cabo de la manera que esperas.
Hablando con otras personas (¡incluyéndote a ti!)
Tu código es una manera de comunicarte con otras personas, pero no para hablar sobre el partido de anoche o el episodio de tu serie favorita de la semana pasada.
Tu código habla con otros que tienen que leer lo que tu has escrito. Lo leen gente con la que trabajas (o colaboras). Lo leen la gente que revisa tu código. Lo lee otro miembro de tu equipo que tiene que añadir algo a tu código más adelante. Incluso lo lees tu mismo cuando tengas que arreglar algún bug en unos meses.
Nuestro código es una comunicación con otras personas. Incluso contigo mismo. También tiene que ser perfectamente claro y sin ambigüedades si otros tienen que mantenerlo.
¡Esto es bastante importante!
Nuestro código debería ser transparente: exponiendo claramente los algoritmos y mostrando su intention, no haciéndolo oscuro y didicil de leer.
Debería permitir a otros modificarlo fácilmente. Si el código no es auto explicativo, mostrando claramente lo que hace, entonces sera difícil de cambiar o mantener.
Recuerda que respecto a la programación lo único que sabemos es que la única constante es el cambio en sí mismo.
El buen código ni se ha reducido hasta el punto de ser ilegible ni es largo, aburrido y lleno de comentarios. Más comentarios no hace un mejor código, solamente lo hacen más largo y al menos genera dos posibles problemas:
- Si tienes que saltarte una línea de código cada dos o tres porque se trata de un comentario, es más complicado entender el proposition del código.
- Los comentarios no se actualizan tanto como el código que pretenden explicar, lo que puede causar que pierdan totalmente el sentido.
Si te ves obligado a añadir un comentario para explicar un bloque de código, deberías de pensar primero en reescribir mejor ese bloque de código.
Un buen trozo de código es un equilibrio entre usar la potencia que nos ofrece nuestro lenguaje de programación y todo el contexto que rodea a ese código. Y ese contexto incluye a la gente. Hacer el bloque de código perfecto que nadie más que tu va a entender lo hará mucho más difícil de mantener, y con el tiempo alguien lo reemplazará con una versión menos avanzada pero mucho más comprensible por todo el equipo.
Además, debes de tener en consideración el lenguaje natural en el que programas. Si todo tu equipo habla el mismo idioma, esto no debería ser un problema, pero hoy en día muchos de los proyectos son multinacionales por lo que esto tiene que ser una decisión consensuada que implique a todo el equipo para elegir un lenguaje común a usar. Lo normal es utilizar el Inglés como lenguaje debido a que las librerías estándar y las librerías más comunes están escritas en Inglés por lo que usar el mismo lenguaje hace el código más homogéneo.
El código se lee muchas más veces de las que se escribe. Por lo tanto debe estar optimizado para ser leído, no para ser escrito.
Hablando con otras herramientas
Nuestro código se comunica con más cosas que nuestra CPU u otras personas, también habla con otras herramientas que trabajan a partir de él.
Ahora mismo hay muchas herramientas que interactuan con nuestro código: generadores de documentación, linters de código, sistemas de control de versiones, herramientas de gestión de errores, analizadores de código, etc. Incluso nuestros editores o IDEs interactúan con él.
Es normal añadir líneas de código o directivas adicionales para que nuestro código funcione bien con estas herramientas, pero es importante saber cuándo parar antes de que afecte a la legibilidad de nuestro código.
