WR 142: Buenas prácticas en programación para novatos

Buenas prácticas para programar con criterio ¶

La diferencia entre un proyecto que aguanta el paso del tiempo y otro que se desmorona al primer imprevisto suele estar en hábitos pequeños. No en grandes metodologías o en herramientas de moda, sino en decisiones cotidianas que marcan tu nivel de profesionalismo.

El cowboy developer no sobrevive al código serio ¶

Arreglar directamente en producción puede ahorrar minutos, pero a largo plazo te costará horas (o incluso días) de crisis. El cowboy developer:

• Edita en vivo a través de FTP o el editor integrado del servidor.
• Omite pruebas locales.
• Corre el riesgo de introducir errores fatales.

En un entorno productivo, basta un punto y coma de más o una función inexistente para tumbar páginas que generan ingresos. Si hay algo que falla, podrías no darte cuenta al instante, o lo peor, descubrirlo cuando ya hay clientes delante.

Montar un entorno de desarrollo local ¶

La solución es tan simple como obligarte a trabajar en un entorno de desarrollo o preproducción que refleje tu servidor en vivo. Así:

• Cualquier fallo queda aislado.
• Ganas confianza al probar cambios.
• Puedes versionar con Git sin prisas.

No hace falta un ecosistema complejo: un contenedor Docker, un servidor local con línea de comandos o incluso MAMP/WAMP son suficientes para empezar.

Evitar programar con los ojos cerrados ¶

A veces basta añadir al final de un archivo CSS unas reglas más específicas para parchear un estilo roto. Eso funciona, lo ves al instante y piensas “ya está”. Pero cada añadido al azar:

• Multiplica la complejidad.
• Hace más difícil localizar el origen de conflictos.
• Rompe el principio de responsabilidad única.

Cuando olvidas ver lo que hay arriba en el archivo, dejas de ser consciente de que cada fragmento de código es parte de un sistema.

Responsabilidad única en CSS y componentes ¶

Adopta el principio single responsibility también para el código “plano”:

• Separa estilos por componente (header, footer, card, checkout).
• Cada archivo CSS atiende solo su ámbito.
• Eliminar dependencias cruzadas evita wars de especificidad.

Al volver al proyecto medio año después, agradecerás no tener que adivinar para qué sirve cada bloque.

No copiar y pegar tapándote la nariz ¶

StackOverflow está a un clic de distancia y, con jQuery o JavaScript, puedes resolver casos concretos en segundos. Pero pegar código que no entiendes es como tragarte una medicina sin leer el prospecto:

• Podrías incorporar hacks o dependencias innecesarias.
• Pierdes oportunidad de aprender la API del lenguaje.
• Olvidas soluciones más simples o nativas.

En lugar de “funciona y ya”, dedícale unos minutos a:

• Leer qué hace cada línea.
• Probar variaciones.
• Anotar dudas para investigar después.

Registrar el aprendizaje ¶

La curva de conocimiento crece con cada problema resuelto. Si anotas lo que has aprendido, en lugar de olvidarlo, obtienes un recurso invaluable:

• Mantén un pequeño diario técnico con Markdown.
• Usa Gist de GitHub para snippets privados.
• Guarda ejemplos en carpetas de Google Drive o en un repositorio local.

Al buscar una solución similar, no volverás a reinventar la rueda y reforzarás tu memoria.

Exponer para crecer ¶

Compartir fragmentos de tu diario puede elevar tu visibilidad:

• Publica entradas cortas en un blog personal.
• Convierte tips en tarjetas de redes sociales.
• Ayuda a otros y construye tu reputación.

Un seguidor de usabilidad o un proyecto de CSS pueden empezar con una simple anotación que a ti te llevó minutos.

Simplificar sin miedo ¶

La tentación de adornar el código con la última librería o una abstracción extra es constante. Recuerda dos máximas:

• KISS (Keep it simple, stupid).
• YAGNI (You aren’t gonna need it).

No necesitas todas las capas de abstracción si tu caso de uso es sencillo. Cada línea extra es una deuda técnica que tendrás que pagar más tarde.

Elegir herramientas con criterio ¶

La lista de IDEs, editores y plugins copiosa puede marear a cualquiera. En vez de cambiar cada semana:

• Elige un editor o IDE que te resulte cómodo (VS Code, PhpStorm, Vim).
• Aprende atajos clave para acelerar tu flujo.
• Usa una interfaz de Git (consola integrada o cliente gráfico) y domina lo esencial.

Las herramientas son esteroides: mejoran tu rendimiento sólo si sabes usarlas con disciplina.

“La mejor forma es presionar los laterales del elemento que rota, haciéndolo girar en perpendicular al eje longitudinal de tal forma que la alicoide se desplace 2mm sobre el contacto superficial. Mantenga la presión constante durante 2,3 segundos y entonces conseguirá su objetivo.” Utilizar esta precisión para abrir un bote de pimientos es gracioso, pero no tengas menos rigor con tu código.

Tu camino profesional se construye con pasos pequeños pero constantes. Cada buena práctica que adoptes no es un capricho, es un activo: ahorra tiempo, reduce fallos y te convierte en un desarrollador más seguro.

Esta semana he mirado al pasado para encontrar en él fallos cometidos, malas prácticas ejecutadas.

Sorprendentemente he encontrado con que algunas siguen vigentes en mi tarea hoy en día.

Muy mal.

Así que en el episodio propongo seis ideas prácticas y concisas para incluir la mejora.

Sea cual sea tu nivel y conocimiento en programación.

Esta semana ¶

El domingo en el newsletter, como es primero de mes, te enviaré la recopilación mensual de enlaces sobre programación y desarrollo e incluso diseño.

La semana siguiente trataremos un tema que tiene mucho que ver con el del episodio de hoy: Las comparaciones son odiosas.

El viernes en la Premium llegará un directo para aprender de forma práctica que es eso del GraphQL.

Y si quieres echarte unas risas y salseo personal, no te pierdas el episodio 107 de Fenómeno Mutante.

Enlaces del episodio ¶

• Curso gratis de buenas prácticas
• SOLID para novatos
• Busca “para novatos” en la página del podcast.
• Jrnl
• El diario de Aunitz Giménez (y no Gómez, me equivoqué en el podcast)
• Tidbit en instagram de Samantha Ming

¡Nos escuchamos el próximo martes!