La Mente de Grug: Complejidad, Código y Pruebas

Introducción

Esta colección de pensamientos sobre desarrollo de software fue reunida por un desarrollador de grug brain.

No es tan inteligente, pero lleva muchos años programando y aprendiendo, aunque a veces siga confundido.

Busca convertir sus aprendizajes en una página pequeña, digerible y divertida, para ti y para él, porque con la edad a veces olvida cosas como lo que desayunó o si se pone los pantalones.

Muchos desarrolladores de gran cerebro existen, y algunos no están contentos con esto y ponen cara amarga.

Se piensa que hay muchos más y que incluso quizá no les guste; así es Internet.

Nota: Grug alguna vez creyó ser de gran cerebro, pero aprendió a la fuerza.

Está bien.

Es un país libre, por así decirlo, y al final del día no importa tanto, pero Grug espera que disfrutes leyendo y tal vez aprendas de sus muchos errores a lo largo de su vida como programador.

El Enemigo Eterno: la Complejidad

La complejidad es el depredador principal del Grug.

La complejidad es mala. Muy mala.

Si hay que elegir entre complejidad o enfrentarse a un T-Rex, Grug prefiere al T-Rex: al menos lo ve.

La complejidad es un demonio espiritual que entra en el código a través de desarrolladores que, con buenas intenciones, no temen al demonio ni saben que existe.

Un día el código es entendible y se puede trabajar; al siguiente, es imposible porque el demonio de la complejidad ha entrado y pone a prueba a todos.

Grug no ve al demonio, pero lo intuye y siente su presencia en el código, burlón, haciendo que cambios pequeños rompan otras partes.

El club no ayuda a enfrentarlo: a veces Grug mismo cae en la trampa.

Con frecuencia, Grug se ve a sí mismo envuelto en esa trampa.

Por eso repite: la complejidad es muy, muy mala.

Decir No

La mejor arma contra el demonio de la complejidad es la palabra mágica: "no".

"No, Grug no va a construir esa característica."

"No, Grug no va a construir esa abstracción."

"No, Grug no va a bañarse en la ducha todos los días ni beber jugo negro para evitar repetir lo ya dicho."

Nota: esto es buen consejo de ingeniería, pero mal consejo de carrera: decir "sí" trae más brillo y más responsabilidad; aprender a decir "sí" y luego culpar a otros es una receta para la carrera.

Pero Grug debe ser fiel a sí mismo: "no" es su palabra mágica.

No es fácil al principio, sobre todo si eres simpático y no quieres decepcionar a nadie, pero con el tiempo resulta más sencillo, incluso si la pila de brillo no alcanza para todos.

Está bien: a veces hay que ceder o hacer compromisos para sostener a la familia, la casa y la vida.

En esas situaciones, se recomienda decir "ok".

"Ok, Grug construye esa característica."

Después, pensar en una solución 80/20: la idea de que el 80% de valor proviene del 20% del esfuerzo.

Esa solución puede carecer de algunas campanas y whistles, pero funciona y evita gran parte de la complejidad demoníaca.

A veces es mejor no informar al gerente de proyecto y hacerlo a 80/20.

Es más fácil perdonar que pedir permiso; la mentalidad del gerente suele cambiar con el tiempo y a menudo olvida para qué sirve la característica o decide seguir adelante, ser despedido o simplemente abandonar el proyecto.

Pero al final está en su interés, así que no hay que sentirse mal.

La Fragmentación de tu Código

La siguiente estrategia es más difícil: dividir adecuadamente el código (lo que, en jerga, se llama "factorear tu código correctamente").

Es un tema distinto en cada sistema, pero una idea clara es que no hay que factorizar demasiado temprano.

Al principio del proyecto todo es muy abstracto, y no hay fundamentos sólidos a la vista.

Tómate el tiempo para entender la forma del sistema y lo que realmente hace.

Evita factorizar demasiado pronto; con el tiempo aparecen buenos puntos de corte: interfaces estrechas que ocultan la complejidad interna, como si estuvieras atrapando al demonio en un cristal.

Cuando aparecen estos puntos de corte, refactoriza poco a poco para que el código tome forma con la experiencia.

No hay reglas rígidas: reconoce el punto de corte cuando aparece; desarrolla la habilidad de verlo con paciencia.

A veces se avanza demasiado rápido y las abstracciones quedan equivocadas; la tentación de los "desarrolladores de gran cerebro" es enorme, pero hay que controlar esas pasiones y en su lugar usar diagramas UML o presentar demostraciones para que los grandes cerebros trabajen en algo que realmente funcione.

La demostración temprana, llamada a veces prototipo, puede ayudar a que el cerebro grande vea la realidad.

Resaltar que el cerebro grande tiene que ser canalizado para el bien, no para alimentar al demonio de la complejidad.

Pruebas

Grug tiene una relación de amor/odio con las pruebas: salvan muchas veces, pero hay shamans de las pruebas que elevan las pruebas a un ídolo y exigen "la primera prueba" antes de escribir código o entender el dominio.

¿Cómo se prueba lo que aún no se entiende?

Grug prefiere escribir la mayoría de las pruebas después de la fase de prototipo, cuando el código ya se ha asentado, pero con disciplina: es fácil moverse y no escribir pruebas, pero eso es muy perjudicial: no hay garantía de que funcione en otros entornos ni a futuro.

Los shamans de pruebas tienen razón en la importancia de las pruebas, aunque a veces no cubren bien una característica.

Se habla mucho de pruebas unitarias, pero Grug no las encuentra siempre útiles: suelen romperse al cambiar la implementación y dificultan el refactor; a menudo se desechan cuando el código cambia.

Grug escribe pruebas unitarias principalmente al inicio, ayudan, pero no deben convertirse en obsesión.

Las pruebas de extremo a extremo muestran que todo el sistema funciona, pero pueden ser difíciles de entender cuando fallan, y pueden hacer que Grug se vuelva loco.

En su lugar, Grug prefiere pruebas de integración para equilibrar la cobertura con la facilidad de depuración.

Se mantiene una cantidad modesta de pruebas end-to-end bien curadas, centradas en las funciones más usadas y en los