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 con tu cuenta de GitHub: lo lee todo el mundo. Lo que guardas se queda en tu navegador.

Código

Sal pronto de la función

Un return en cuanto sabes la respuesta ahorra tres sangrados.

  • 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

Para apuntar el tuyo, entra con GitHub.

Lo que apuntes lo lee todo el mundo, con tu nombre de GitHub, y sale el primero de la lista. Lo que guardas y el filtro solo están en tu navegador.