Refactorización de código: cómo escribir un código mejor

Simplemente hay mucho que aprender en el mundo de la programación.

A los 3 años de desarrollo web front-end, me siento tan mal en la codificación como siempre. Simplemente hay mucho que aprender en el mundo de la programación para que un desarrollador lo suficientemente humilde nunca se atreva a decir que su código es perfecto.

He estado mejorando mis habilidades de CSS durante la mayor parte de mi carrera, y eso me hace perder la confianza en mis habilidades de JavaScript por buenas razones. Siendo una persona positiva que busca crecimiento todo el tiempo, elegí convertir este sentimiento de insuficiencia en motivación en lugar de odio hacia uno mismo.

A continuación se muestra una prueba de código que mi compañero colega senior redactó para el proceso de contratación. Compartió con otros compañeros de equipo para que podamos dar su opinión sobre la eficiencia del uso de esta prueba de código para determinar las habilidades de programación de los candidatos. Aproveché esta oportunidad para mejorar mis habilidades de JavaScript al dedicar todo el día a pensar en el código.

La pregunta

Escriba una función que cuando se le da una cadena de número de versión, es decir. "1.12.4" y una cadena de rango semver, es decir. "~ 1.12.0", devuelve si la versión dada cae dentro del rango de semver dado como un booleano.
El rango de semver debería admitir los tres patrones siguientes:
 1) coincidencia exacta
 2) ^ Versiones mayores en el mismo rango de versiones principales
3) ~ Versiones mayores en el mismo rango de versiones menores

Primer intento

En el primer intento, busqué la forma más fácil de completar la tarea, usando .substring (), cambiar mayúsculas y minúsculas, para bucles y si las condiciones. Aunque el código se ve feo, funciona y es muy simple terminar esta solución porque todos estos son los conceptos básicos de JavaScript. Mi hábito en la codificación es hacer que funcione primero, luego refactorizarlo hasta que esté satisfecho y finalmente considerarlo como completado. Probablemente no sea la mejor manera para la mayoría de las personas, pero estoy acostumbrado a trabajar de esta manera. (En el futuro, me encantaría cambiar mi forma de trabajar y dedicar más tiempo a pensar antes de comenzar a codificar).

Segundo intento

Conozco la parte de la caja del interruptor y las condiciones si son muy feas, así que intenté reescribirlas. Quería encontrar una función que pueda recorrer la matriz en shouldMatch como .forEach () pero que pueda romper el ciclo cuando result === true, así que busqué en Google y encontré .some () que es exactamente lo que quería. Estaba bastante avergonzado de no recordar esta función, pero me he perdonado. Después de todo, hay funciones que no usamos a menudo y es natural olvidarlas. Mi actitud es: úsalas más si las encuentras útiles, y eventualmente las recordarás.

Tercer intento

Compartí el código con el ingeniero senior, y él me dio algunos comentarios constructivos. Me pidió que pensara en una mejor manera de obtener rangeSymbol e intente no modificar rangeNumArr después de la declaración. Por último, pero no menos importante, me dijo que usara .every (), que es bastante similar a .some (), pero en cambio el bucle se rompería cuando el valor de retorno sea falso. Seguí su consejo e hice algunos cambios adicionales, y resultó en una hermosa pieza de código:

Conclusión

Es muy importante admitir que no eres bueno en algo y buscar mejoras.

Pida ayuda si la necesita. Siempre es bueno tener una perspectiva diferente porque todos tienen un proceso de pensamiento diferente. ¡A veces las opiniones de otros pueden inspirarte!

No temas perder el tiempo en una función simple cuando estás haciendo ejercicio de codificación. ¡Recuerde que la programación es un proceso creativo que consume una buena cantidad de energía cerebral cuando se hace correctamente!

¡Aplauda y sígueme si te gusta este artículo!

Compartiría mis experimentos frontales y mis pensamientos sobre programación cada vez que tenga tiempo;)