Consejos de desarrollo

Consejos de oficio, de los que se aprenden a base de golpes: código, git, depuración, pruebas, rendimiento y equipo. Arriba sale uno al azar; debajo están todos, con buscador, filtro por tema y una estrella para quedarte con los que te sirvan. Y apunta el tuyo: se queda en tu navegador, así que cópialo y proponlo para que lo lea todo el mundo.

Git

Rama corta, rama que entra

Una rama de dos semanas es un conflicto esperando su turno.

  • Escribe el nombre entero

    Código

    «usuariosActivos» se entiende dentro de seis meses; «ua» no.

  • Comenta el porqué, no el qué

    Código

    El qué ya lo cuenta el código; comenta la decisión rara.

  • Sal pronto de la función

    Código

    Un return en cuanto sabes la respuesta ahorra tres sangrados.

  • Borra el código muerto

    Código

    Comentado por si acaso no: para eso está el historial.

  • A la tercera se abstrae

    Código

    Antes no sabes qué parte varía y sale una función con siete parámetros.

  • Un commit, un cambio

    Git

    Si al describirlo tienes que usar un «y», eran dos commits.

  • El mensaje dice qué y por qué

    Git

    «arreglos» no cuenta nada, y dentro de un año lo lees tú.

  • Nada de force un viernes

    Git

    Y si hace falta, --force-with-lease, que respeta lo de los demás.

  • Rama corta, rama que entra

    Git

    Una rama de dos semanas es un conflicto esperando su turno.

  • Léete tu propio diff

    Git

    git diff --staged pilla el console.log y la clave pegada sin querer.

  • Reprodúcelo antes de arreglarlo

    Depuración

    Lo que no sabes provocar tampoco sabes si lo has arreglado.

  • Cambia una cosa cada vez

    Depuración

    Si tocas tres y funciona, no sabes cuál de las tres era.

  • Duda de tu código primero

    Depuración

    Casi siempre es tuyo: un tipo que no era, un await que falta.

  • Lee el error entero

    Depuración

    La primera línea dice qué reventó; las de abajo, quién lo llamó.

  • Explícaselo a alguien en voz alta

    Depuración

    La mitad de las veces das con el fallo a mitad de la frase.

  • Cada bug se va con su test

    Pruebas

    Primero uno que falle por ese motivo, y luego el arreglo.

  • Prueba el comportamiento

    Pruebas

    Si se rompe al renombrar algo privado, estabas probando el cómo.

  • Los bordes son donde revienta

    Pruebas

    Cero, uno y muchos. La cadena vacía, el negativo, el nulo.

  • El test que falla a ratos, fuera

    Pruebas

    Enseña a ignorar el rojo, y un día el rojo va en serio.

  • El nombre del test cuenta el caso

    Pruebas

    «devuelve 400 si falta el email» se lee en la salida; «test1» no.

  • Mide antes de optimizar

    Rendimiento

    La intuición sobre qué va lento acierta poco: saca el perfil.

  • La consulta dentro del bucle

    Rendimiento

    Una por fila son mil viajes; pídelos de una vez y júntalos.

  • Lo más rápido es lo que no se envía

    Rendimiento

    Quita la librería de 300 kB que usas para una fecha.

  • Un índice arregla más que un rediseño

    Rendimiento

    Sin él la base se lee la tabla entera: mira el plan.

  • Cachear es asumir una deuda

    Rendimiento

    Ponle plazo al ponerla, no cuando ya está sirviendo algo viejo.

  • Pregunta a los treinta minutos

    Equipo

    Atascarse es normal; atascarse callado tres días, no.

  • Revisa el código, no a quien escribe

    Equipo

    «peta si la lista viene vacía» se arregla; «está mal» no.

  • Manda la revisión pequeña

    Equipo

    Cuatrocientas líneas se aprueban sin mirar; cincuenta se revisan.

  • Escribe la decisión donde se vea

    Equipo

    Lo hablado en una llamada se olvida; en el repo, no.

  • Deja la puerta abierta al que venga

    Equipo

    El README con cómo se levanta esto también es producto.

El tuyo

Lo que apuntes se queda en este navegador y sale el primero de la lista. Para que lo lea todo el mundo, cópialo como idea y proponlo en la portada.