45

Cómo enfrentar código desconocido | Nuevos Laboratorios Avanzados

6671Puntos

hace un año

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) y user.name en efecto es vacío.
  • ¿Cómo el frontend obtiene al objeto user?
  • La respuesta HTTP también muestra que la propiedad name está 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 userName pero el backend únicamente name. 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:

@jonalvarezz

Jonathan 🦑
Jonathan 🦑
jonalvarezz

6671Puntos

hace un año

Todas sus entradas
Escribe tu comentario
+ 2
Ordenar por:
2
1507Puntos

Hace un año me hicieron la misma pregunta en una entrevista. El trabajo en equipo consiste en confiar en el trabajo de los demás, lo que alguna vez se hizo se hizo con la mejor intención según las herramientas que tuvo disponibles… pero este numdo corre tan rapido que es posible que estos escenarios ocurran frecuentemente y deternos a refactorizar el codigo pasado nos frena de aportar valor y crecimiento hacia el futuro.

2
24189Puntos

Yo voy aprendiendo aprendiendo CSS ¿Crees que sería buena idea buscar proyectos de otros compañeros y tratar de entender su código? O tal vez tratar de hacer mejoras en l código usando su metodología de trabajo.
¿Cómo puedo practicar esto desde ahora?

2
1507Puntos
un año

Siempre es una buena idea mirar lo que otros han hecho!!, se aprende mucho de otros puntos de vista. En codepen puedes encontrar mucho para observar.

2
37521Puntos

Mi parte favorita de esta lectura:

El código es una consecuencia de decisiones que toman unas o varias personas para solucionar un problema en particular.

2
39012Puntos

Yo utilizo mucho la busqueda en mi editor, para encontrar los componentes en los que debo trabajar.

1
68946Puntos

Muy buen aporte, muchas gracias