La constante necesidad de querer reescribirlo todo para satisfacer su ego. Esta es una de las mayores separaciones entre principiantes y profesionales cuando se enfrentan a código que fue escrito por alguien más.
Reescribir código solo por el capricho de poder hacerlo, no agrega ningún valor tangencial al producto ni al equipo. Solo te hará sentir temporalmente mejor contigo mismo. Reescribir y refactorizar código es una tarea sencilla; solo requiere conocimientos del lenguaje en específico.
¿Sabes qué es lo realmente retador? Comprender tan bien la intención y el propósito de un proyecto que, aunque entiendas que hay cosas que se pueden mejorar o no lo entiendas todo, te enfoques en hacer únicamente eso que se te pidió hacer introduciendo la menor cantidad de cambios posibles. Eficiencia y efectividad.
La situación es más adversa cuando no estás familiarizado con el código y te enfrentas a cientos de archivos con miles de líneas de código y no tienes ni idea por dónde empezar. Es por esto que a continuación te presentamos otros enfoques que ayudarán a trabajar efectivamente en código desconocido.
No todo es acerca del código
El código es una consecuencia de decisiones que toman unas o varias personas para solucionar un problema en particular. A medida que pasa el tiempo, esas decisiones quedan implícitas en el código sin dejar rastro en ningún otro lado.
Preguntar a tus colegas, directores y dueños del producto sobre cómo debería funcionar algo y por qué funciona, de la manera que funciona aumentará tu dominio del negocio y el contexto en el que vive el código. Este conocimiento es fundamental para tomar las decisiones correctas.
Eso sí, siempre ten presente que las decisiones pasadas se hicieron con la mejor intención con los datos e información que había disponibles al momento. En otras palabras, no juzgues y sé humilde al preguntar.
Enfrenta los problemas de afuera hacia adentro
Imaginemos la siguiente situación:
- Hmmm… el frontend está mostrando
“Welcome, undefined” - ¿Qué componente está renderizando
“Welcome, ”? - Hice un
console.log(user)yuser.nameen efecto es vacío. - ¿Cómo el frontend obtiene al objeto
user? - La respuesta HTTP también muestra que la propiedad
nameestá vacía. - ¿Qué endpoint es?
- ¿En qué parte del backend está este endpoint y cómo obtiene la data?
- ¿El modelo que describe y conecta la base de datos está correcto?
- ¡Eureka! La base de datos dice
userNamepero el backend únicamentename. Aquí era el error.
Lo mejor de este enfoque es que no necesitas saber a detalle la arquitectura de un proyecto. ¿Es React, Vue o Angular?, ¿Es Node.js, Django o Ruby? No importa, logramos escavar lo suficiente como parar detectar que hay una disparidad entre la base de datos y los modelos del backend.
Para quienes nos obsesionamos con los conocimientos fundamentales y no con frameworks en específico, este enfoque práctico es tremendamente efectivo, dura para toda la vida y para todas las situaciones.
Usa la herramienta de búsqueda de tu editor
Hace parte del enfoque mencionado anteriormente. ¿Sabes que el error sucede en un componente que dice “Detailed user information” pero no tienes idea dónde se encuentra?
Buscar en el Editor de Código por esas palabras es un gran inicio.Funciona mucho mejor entre más sepas, reducir la búsqueda. Por ejemplo, si inspecciono el DOM y ubico el elemento en cuestión, ¿tendrá un ID único que me facilite la búsqueda? Si no, tal vez su clase CSS sí lo sea y esto me ayude a descartar otras coincidencias.
¿Cuáles son las tuyas?
¿Te has enfrentado anteriormente con estos retos? Comparte en los comentarios cómo lo superaste y qué harías diferente la próxima vez.
¿Quieres retarte, enfrentarte a código desconocido y resolver problemas que se te presentan aterrizados a la vida real? No te pierdas entonces de nuestros nuevos Laboratorios de Platzi para que apliques todo lo que has aprendido:
Laboratorio de Node.js: Autenticación y Seguridad
