6 pecados que os desenvolvedores de back-end não devem cometer

6 pecados que los desarrolladores de backend no deberían cometer

Un buen desarrollador back-end podría marcar la diferencia entre una casa que puede resistir un huracán y una que se derrumba en una temporada de fuertes vientos.

desenvolvedores de back-end

Portuarios

Además, necesitan trabajar bajo presión para cumplir con los plazos y refactorizar, depurar o escalar rápidamente. Hay mucho con lo que lidiar y algunos de los pecados más comunes cometidos por los desarrolladores backend pueden tener consecuencias duraderas. Repasemos los 6 más importantes.

#1 No deberías acumular demasiada deuda técnica

El primer pecado es común tanto a los desarrolladores de back-end como a los de front-end: tener una gran cantidad de deuda técnica. De hecho, los equipos ágiles dependen de la deuda técnica para proporcionar soluciones más rápidas y mejores productos, pero lo más probable es que cuanto más acumule, mayor será la posibilidad de que sea más difícil implementar nuevas soluciones o escalar el proyecto más adelante.

La máxima aquí es: no cree código sobre código incorrecto , porque tan pronto como refactorice, el nuevo código probablemente se romperá. El código espagueti, las funciones/métodos extensos, mucha sangría, declaraciones if/else excesivas y malas prácticas de nomenclatura de variables pueden parecer pequeños detalles con consecuencias insignificantes, pero pueden generar muchos problemas.

Con buenas prácticas de codificación y una buena planificación, se puede evitar la deuda técnica y, en los casos en que sea necesario, un buen protocolo será de gran ayuda para evitar que el equipo construya una montaña encima de un castillo de naipes. .

#2 No deberías escribir documentación de mala calidad

Una buena documentación es como un mapa bien dibujado o una buena receta: no deja nada a la imaginación. Para seguir una página del zen de Python, explícito es mejor que implícito . En este sentido, uno de los mayores pecados de los desarrolladores back-end es pensar en la documentación como una ocurrencia tardía.

La documentación deficiente o faltante causará, en el mejor de los casos, confusión o detendrá completamente un proyecto, ya que los desarrolladores tendrán que revisar manualmente el código línea por línea para descubrir qué está pasando.

Con buenas prácticas de documentación, a los desarrolladores front-end les resultará más fácil comprender cómo se comunicará su parte del proyecto con el back-end, y aquellos que vengan después tendrán una fuente confiable de información a la que recurrir cuando busquen errores o durante reestructuración.

Como beneficio adicional, podemos agregar otro mandamiento: debes comentar tu código . Al igual que la documentación limpia, el código comentado ayudará a los revisores de código y a otros desarrolladores a comprender la lógica subyacente. Estos comentarios pueden incluso ayudar a los propios desarrolladores cuando regresan a revisar el código que no han tocado en mucho tiempo.

#3 No debes faltar a los exámenes

Las pruebas son una parte integral de cualquier ciclo de desarrollo. Escribir pruebas y buscar casos extremos ayuda a los desarrolladores backend a detectar errores y explorar escenarios que de otro modo podrían pasar desapercibidos hasta que sea demasiado tarde. Aún así, algunos desarrolladores optan por saltarse algunas pruebas, tal vez porque quieren cumplir con un plazo ajustado o porque tienen exceso de confianza.

Entonces, este pecado generalmente ocurre cuando los desarrolladores se quedan sin tiempo o cuando confían demasiado en su propio juicio/revisión de código. Ningún par de ojos tiene suficiente experiencia para predecir el comportamiento de un código en todas las situaciones posibles.

Una forma sencilla de evitar este problema es escribir las pruebas junto con el código o compartir el pseudocódigo con otro desarrollador y pedirle que escriba un conjunto de pruebas. De hecho, algunos equipos llegan incluso a crear primero las pruebas más extremas posibles y luego escribir el código. De esta manera, se están desarrollando eficazmente para resolver casos extremos.

Las pruebas son una forma confiable de garantizar que el código funcione como se espera y que la lógica detrás de él sea lo suficientemente flexible como para adaptarse y escalar según lo requiera el proyecto.

#4 No debes utilizar demasiadas tecnologías para una misma solución

Una de las mayores ventajas de trabajar con lenguajes de programación populares como Python o node.js es la cantidad de recursos disponibles. Entonces, ¿por qué escribir algo desde cero cuando puedes simplemente importarlo?

Pero eso abre la puerta a su propia serie de problemas. Depender demasiado de software y bibliotecas externas significa, ante todo, que se trata de múltiples API al mismo tiempo, y eso en sí mismo es un desafío.

Pero aparte de eso, las tecnologías se actualizan constantemente, lo que puede generar cambios no deseados o errores que pueden arruinar su propio proyecto. Además, los proyectos se vuelven obsoletos y esa increíble biblioteca que encontraste puede desaparecer repentinamente en un abrir y cerrar de ojos.

Esto no significa que debas limitarte a una solución, sino más bien una advertencia: introducir nuevas tecnologías en un proyecto siempre debe ser una decisión bien pensada y que a veces hacer un esfuerzo extra para hacerlo tú mismo te evitará dolores de cabeza en el futuro. futuro. línea.

#5 No debes olvidar un protocolo de respaldo

Casi todos los desarrolladores backend tienen que lidiar con bases de datos en su carrera y, como todos sabemos, si una aplicación es un cuerpo, entonces los datos son su alma. Los buenos desarrolladores de back-end mantienen amplias copias de seguridad de sus datos, en la nube, en medios físicos, en servidores remotos y prácticamente en cualquier lugar. Sin ellos, los ingenieros corren el riesgo de perder todo su trabajo debido a una falla del hardware o software.

Por eso las copias de seguridad deben ser frecuentes y fiables. Si tus datos se actualizan minuto a minuto, perderse unos días puede ser catastrófico para un proyecto. Es mejor invertir en una solución de almacenamiento que perderlo todo por un error.

#6 No debes tener una mala planificación antes de construir el modelo de datos

Reconstruir un modelo desde cero puede ser una pesadilla, por lo que hacerlo bien a la primera ahorrará tiempo e inversión en el proyecto. A veces la reestructuración de los modelos de datos es inevitable, pero que estos momentos sean producto de influencias externas y no de una falta de previsión.

Los buenos desarrolladores backend obtienen una idea muy clara de lo que se supone que debe hacer el proyecto y diseñarán un modelo que se ajuste al proyecto teniendo en cuenta la escalabilidad, incluso si el proyecto no implica escalar en el corto plazo.

Diseñar un buen modelo de datos es un excelente ejemplo de planificación a largo plazo y evitará los problemas que surgen con bases de datos que exceden sus capacidades.

Un buen desarrollador backend es un estratega y un jugador de equipo.

La habilidad técnica no es lo único que un desarrollador back-end necesita para ser bueno. Lo que realmente hace brillar a un especialista es que comprende el papel que desempeña en el equipo de desarrollo y cuánto depende el proyecto de su trabajo. Contratar a un buen desarrollador back-end podría marcar la diferencia entre una casa que puede resistir un huracán y una que se derrumba en una temporada de fuertes vientos.

contenido relacionado

Regresar al blog

Deja un comentario

Ten en cuenta que los comentarios deben aprobarse antes de que se publiquen.