Un error común que hacen los desarrolladores de software para principiantes y cómo evitarlo

Foto de Fancycrave en Unsplash

Llevaba solo un mes en mi trabajo como desarrollador de software, recién salido de la universidad. Me estaba calentando para contribuir a mi equipo. De alguna manera, me sorprendí teniendo pensamientos muy interesantes mientras revisaba la base de código existente. Mi equipo había construido esta base de código durante meses y años de esfuerzo.

Como mi primera tarea, tuve una pequeña corrección de errores que ayudaría a estabilizar futuras versiones del servicio. Mi equipo me explicó la arquitectura del servicio y dónde encajamos en el gran esquema del proyecto más grande. Estaba en mí encontrar dónde debía agregarse / eliminarse o modificarse el código para corregir el error.

Comencé a buscar en la base del código, la mayoría de los cuales habían sido creados en los últimos dos años. Por ningún estándar, era código heredado. A medida que profundizaba más y más en ello, me encontré con pensamientos bastante profanos. Decir que el código no era estéticamente agradable, sería una forma moderada de decirlo. Así es como reaccioné a la base de código de mi equipo:

Esto apesta!

Yuck, hay doscientas funciones de línea aquí.

¿Quién escribió esta basura?

Oh Dios, hay un bloque if-else dentro de un bloque if-else.

¡Este código es un gran desastre peludo! ef it.

Esto necesita ser reescrito desde cero.

Estaba furioso. Mientras tenía estos pensamientos, una parte de mí se preguntaba, ¿podría haber una manera de darle sentido a todo esto? Hubo algunas cosas que no sabía que estos muchachos de mi equipo que escribieron la mayor parte de este código. Empecé a descubrirlo.

Agarré al chico mayor de mi equipo para una conversación rápida y comencé a hacerle mis preguntas.

Lo que supe después de la discusión fue muy esclarecedor para mí. El equipo sabía que el código tenía algunos problemas de mantenimiento. Sin embargo, la base de código existente estaba en la forma que es por algunas razones. A medida que me explicó esas razones, pude ver por qué esta publicación tiene sentido.

Siga leyendo para encontrar la respuesta a por qué cuando le pregunta a un desarrollador de software la calidad del código en el que está trabajando, la respuesta predeterminada es: "Es un desastre". Y también, por qué construir cosas desde el suelo no es una solución en la mayoría de los casos.

El código está escrito por una razón diferente

La mayoría de las personas nuevas en el desarrollo de software, incluido yo, piensan que el código está escrito para máquinas. Incorrecto. Nada Fue escrito para humanos. La máquina ni siquiera ve el código JavaScript que escribes, todo lo que ven es una secuencia de 0s y 1s. Y a medida que se estaba construyendo el servicio para mi equipo, había plazos reales con entregables que debían entregarse. Los desarrolladores de software ya están muy gravados mentalmente. En algún lugar en la presión de entregar, hacer que el código funcione tiene prioridad sobre la escritura de código súper estéticamente agradable.

Una gran porción de código es más fácil de escribir y explicar a un compañero desarrollador en persona, en lugar de saltar de un archivo a otro para darle sentido a las cosas. Estas decisiones pueden permanecer por mucho tiempo.

Código de producción probado en batalla

Mi equipo recibe muchos informes de incidentes, que a veces conducen a correcciones de errores críticos en el código. Un error al manejar la cláusula if-else aquí, un try-catch allí, y de repente, toda la base del código ha crecido. Así es como la base de código comienza a complicarse a pesar de las mejores intenciones.

Esto es exactamente por qué reescribir el código desde cero es una idea tan ingenua. Esto resultaría en descartar todas las correcciones de errores y mejoras que se hicieron. Estos fueron acumulados en el transcurso de meses y años, posiblemente por un usuario que tiene algún problema real. Un desarrollador podría haber pasado varias horas para corregir estos errores una vez que fueron reportados.

Lo que funciona es el camino

En el mundo de los negocios, donde puede haber clientes dependiendo de su producto o servicio. A nadie le importa si su código se refactoriza en la mejor medida posible. Cada línea de código está escrita para resolver un problema comercial. Pregúntese, ¿qué valor crearán sus esfuerzos de refactorización? Posiblemente ninguno, y podrían terminar introduciendo más errores. Además, ¿es el mejor uso de tu tiempo?

El antidoto

El primer paso es reconocer el problema. El problema era que mi ego pensaba que podría hacer un mejor trabajo que estos desarrolladores senior que claramente no sabían cómo escribir código de nivel de producción. Esta es una manera muy ingenua de pensar, y me han quemado suficientes veces en el pasado para evitarlo ahora.

Simplemente al reconocer la presencia de tu ego, obtienes una gran ventaja sobre él. De repente, no tiene lugar para esconderse. Reconocer el problema es una cosa, y resolverlo es otra. A continuación se muestra mi forma de evitar esta reacción instintiva. Si tiene una forma diferente, escríbala en la sección de comentarios.

Ponte curioso

¡Comienza a preguntar por qué!

¿Por qué se escribió este código de esta manera? ¿Quien lo escribió? ¿Esa persona todavía está cerca y puedo preguntarle esto? ¿Qué saben estos tipos que yo no? ¿Cuál es el problema que resuelve esta característica?

La mayoría de las veces, la respuesta te sorprenderá.

Desarrollar humildad

Esta no es una tarea difícil. Con toda probabilidad, todavía tienes mucho que aprender sin importar dónde te pongas en la escalera.

Adoptar una mentalidad de crecimiento es lo que me permitió ponerme en el estado mental correcto. Me liberó hacer preguntas sin temor a parecer estúpido. Cuando sabes que se supone que no debes saber todas las respuestas, pero aprendes todas las respuestas, hacer preguntas se convierte en una simple trivialidad.

Conclusión

Es muy fácil pensar que su forma de escribir código es la mejor, y todos los demás apestan. Pregúnteles a tres personas cómo dividirían una cadena en una serie de caracteres, y todos darían tres formas diferentes de hacerlo. Probablemente, todos ellos son igualmente buenos, y se puede aprender algo de todos ellos.

En cuanto a lidiar con el código de mala calidad, tirarlo definitivamente no es la solución. La forma más amigable para los negocios sería comenzar a comer el elefante una mordida a la vez y refactorizar el código.