Hace un tiempo di una charla en la BeerJS, que pueden ver acá. Y quiero compartirla con ustedes por escrito, en forma de guía de “buenas prácticas” a la hora de agarrar un nuevo trabajo, y ahorrarnos unos cuantos dolores de cabeza, y para:

1. Sentirte productivo y que no estás atrapado en un pozo.
2. Quedar bien con tus compañeros y jefes.
3. No tener un “periodo de ajuste” de 1 mes hasta poder codear algo más complicado que el color de un título.

No voy a proponer ideas muy locas, ya que los consejos que voy a dar, son los que me sirvieron y que, vas a terminar aprendiendo a la larga.

A tener en cuenta, asumo en varias partes que estamos hablando de aplicaciones web escritas en JavaScript, pero los consejos son aplicables a cualquier stack.

3 Cosas a Hacer en Todo Proyecto

En muchos trabajos, te van a dar un tiempo inicial para aclimatarte e ir entendiendo el proyecto. Y si tenés mala suerte y no tenés ese tiempo, lo que podés hacer es calcular de más los primeros tickets teniendo en cuenta que vas a tener que hacer estas cosas. No estoy recomendando mentir, sino tener en cuenta de que el tiempo de algún lado va a tener que salir, porque siempre vas a tener que hacer la configuración inicial del proyecto para arrancar a trabajar.

En este tiempo extra inicial, te recomiendo que hagas siempre estas 3 cosas (puede que en simultáneo), así que a arremangarse.

1. Levantar el proyecto

Necesitas tener el proyecto corriendo. La aplicación tiene que poder abrirse y estar funcionando.

¿El Objetivo final? Poder meter un “Hola Mundo” en alguna parte del proyecto (en varias, idealmente), y verlo corriendo en tu PC.

Para esto, al momento de levantar el proyecto, toca lo siguiente:

• Identifica el punto de partida, y la estructura del proyecto: Partiendo del/los repositorio/s, trata de reconocer lo familiar, herramientas que ya hayas utilizado y que te puedan ayudar a ubicarte en el proyecto, y así ubicar el punto de partida. Este es un punto crítico, por lo que prestá atención a lo que hacés.

  Para darte un ejemplo: ¿Te toca levantar un servidor REDIS? Es muy posible que tu proyecto haga uso de una caché en algún lado (o tal vez rate limiter, u otra cosa), tenelo en cuenta a medida que vas armando la imagen mental de la estructura del sistema.

• Entendé las dependencias a nivel código interno del proyecto: Es parte de la mirada muy por encima que le tenés que dar a cualquier proyecto. ¿Qué dependencias usa (no hace falta que mires todo)? ¿Qué linter tiene instalado? ¿Usa Prettier o ESLint o ambos o alguna otra cosa? En unos segundos, mirando el package.json del proyecto (o equivalente), podés llegar a ver todo el stack tecnológico de un proyecto. Incluso podés ver que extensiones deberías tener instaladas en tu entorno de desarrollo.

• Cuidado con la versión de las dependencias: Si estás empezando un proyecto nuevo, y ves que tiene dependencias por actualizar, resistí la tentación del update, porque es muy posible que rompas todo y la pases mal por un buen rato.

Es más, si es posible y tu proyecto utiliza yarn o npm, tratá de usar npm ci o yarn --frozen-lockfile, que te va a asegurar tener las mismas dependencias que tiene instalado el ambiente de producción.

• Lee la Documentación: Si se da el caso de que tengas la gran suerte de tener una guía de como levantar el proyecto, LÉELA Y SEGUILA, pero teniendo en cuenta que es posible que no esté actualizada, o que tengas que cambiar algún paso.

• Tomá notas de lo que vas haciendo: Los comandos que corriste, las cosas que instalaste, los archivos que cambiaste, el orden de lo que hiciste y los errores o resultados inesperados que te encuentres.

  Recordá que si te trabás, no tenés que tener miedo en preguntar a tus compañeros sobre problemas o dudas que tengas, y las notas que hayas tomado te van a ayudar a vos y a tus compañeros para destrabarte, en caso de que no puedas avanzar. Además, tomar notas tiene la gran ventaja, de que si algo cambió respecto a la documentación, o no es correcto, ese puede ser tu primer Pull Request para la empresa. Literalmente podés hacer tu primera contribución a la hora de arrancar a configurar todo!! (si tenés suerte y logras configurar el proyecto rápido 😅*)*.

• Revisa que tengas las variables de entorno correctas y permisos de acceso habilitados: Casi todos los proyectos necesitan de variables de entornos, ya sea la URL de la base de datos, alguna secret key de alguna API, o el usuario y contraseña de algún servicio. Usualmente, a estas cosas te la pasan de forma independiente al acceso del repositorio. Si te encontrás con un error al correr el proyecto, esto es de las primeras cosas que pueden ser la causa, y una de las cosas a pedir.

• Corré los Tests: Es posible que te encuentres algún tipo de test automatizado (si esto pasa, tenés suerte). Todo depende de la empresa y el proyecto.

Una buena prueba para saber si tenés todo andando bien, es corriendo los tests localmente. De la misma manera, no tomes a los test no funcionando como un fallo inmediatamente, porque algunos test dependen de bases de datos o cosas externas que puede que no tengas.

---

A tener en cuenta

Levantar el proyecto es el paso más urgente, porque para poder trabajar necesitas el proyecto funcionando, por lo que siempre dale prioridad por sobre comprender en detalle la arquitectura o el contexto de negocio.

---

2. Entender la Arquitectura

Algunos proyectos van a tener un documento sobre esto, y si el documento es una representación válida de la realidad actual, de una, aseguráte de entenderlo.

En mi experiencia, casi nunca está actualizado, o completo del todo. Te recomiendo molestar sin asco a algún senior o responsable del equipo, para que te dé una guía de la arquitectura actual del proyecto, el responsable del equipo debería saber que tan al día está el documento (si es que existe), y hacerte una explicación más fácil de entender respecto a como es la arquitectura del proyecto.

Algunas preguntas que me parece que son importantes a responder:

• En que contexto corre el código?:
  • El código de producción corre en servidores Linux? ¿Usa Docker/Kubernetes? Serverless?
  • Está armado con micro-servicios o es un monolito?.
  • Que soporte de Sistemas Operativos tiene? ¿Funciona en Windows? ¿Que OS tienen mis compañeros de trabajo?
• En donde se guardan los datos?
  • ¿El proyecto usa bases de datos SQL, o alguna cosa NoSQL? Si es NoSQL, que tipo de NoSQL?
  • Como se dividen los datos de las DB entre el ambiente de development y produccion?
  • Que permisos tengo en cada ambiente?
• Como se reparte el codigo del proyecto?
  • Que repositorios son los que vamos a usar más frecuentemente, que hace cada uno? ¿Por dónde debería empezar?
• Como es el flujo de desarrollo y despliegue?
  • ¿Cómo llevo un fix/feature local de código en mi PC al ambiente de producción?
  • ¿Cómo es el modelo de branching acá? ¿Hay un esquema de nombrado?
  • ¿Utilizan un entorno de Staging? ¿Tengo acceso a eso?
• Hacen testeo del código? Pertenecen al flujo diario de desarrollo?
  • ¿Tengo que hacer tests de cada feature o fix que haga? Hacen TDD?
  • ¿Qué nivel de granularidad y coverage precisan de los tests?
  • Cuál es el estado de los tests del proyecto? ¿Se espera que funcionen en local?
• Que cosas me conviene esquivar a la hora de arrancar para no romper?
  • Hay algún componente que esté muy atado con alambre y solo el creador sabe cómo funciona?
  • Cuál es la expectativa y situación actual de ownership de código de la empresa?
• Que servicios externos usa el sistema y la empresa?
  • Que API (e.g. SendGrid, DataDog, Sentry) o productos externos utiliza el sistema o la empresa?
  • Tengo acceso a todas las API que necesito?
• Tienen alguna preferencia o buenas prácticas de código especificas?
  • Cuál es la preferencia del proyecto en términos de comentarios en el código?
  • Tienen alguna política a respetar ya sea legal o técnica respecto de como tiene que ser el código?

Estas preguntas son importantes, te pueden ayudar a levantar el proyecto, resolver problemas que te encuentres eventualmente y, en general, te ayudan a formar una imagen más completa de como está armado el sistema, y como tenés que trabajar.

Si tenés la mala suerte que nadie sabe nada, te va a tocar arremangarte y ver el código y buscar, y responderte a vos mismo esas preguntas. Generalmente, alguien siempre sabe, porque alguien paga por la infraestructura, y poco a poco vas a ir entendiendo. Llegado este punto no tengas miedo de preguntar, eso es lo más importante. Y si nadie responde, toca ponerse a investigar, y apuntar para arriba en la cadena de mando. Los bautismos de fuego son feos, pero no son tan comunes, es cuestión de tiempo hasta que te puedas armar una imagen de como funcionan las cosas.

Recomendación: Tratá de ayudar al equipo a documentar lo que te van enseñando y respondiendo. Ya sea escribiendo un primer esbozo de lo que entendiste que es la arquitectura y publicándolo y perfeccionarlo, o completando o actualizando las partes que falten de lo que ya haya. Ponele fecha, cosa de que quede claro cuando fue la última que se actualizó, todos los proyectos cambian y evolucionan.

3. Entender el Negocio

La idea es armarte una idea de en donde están parados el proyecto, la empresa, y tu posición en la misma.

A nivel general, querés saber: ¿Qué hace la empresa o el proyecto?, ¿Quiénes son los clientes, que es lo que ofrece de valor?, ¿Cuáles son las prioridades a nivel general?, ¿Cuáles son las expectativas de la empresa sobre el proyecto?, ¿Son una empresa “avanza rápido, rompe cosas” o es más madura y rígida?.

Y ya a nivel proyecto, deberías preguntar: ¿Como se relaciona tu equipo y proyecto con la empresa o el producto?, ¿Quién se enoja si el proyecto se rompe?, ¿Qué tan crítico es el proyecto para la empresa?, ¿Con qué otros equipos voy a terminar interactuando seguido?, ¿El código entre equipos se comparte o como funciona la cosa respecto a eso?, ¿Hasta dónde llega la responsabilidad de mi equipo?.

Este tipo de cosas son las que le preguntás al de Recursos Humanos al momento de entrar a la empresa, o al PO, o al PM, o es algo que te va a tocar investigar o darte cuenta. No tengas miedo de hacer estas preguntas, porque te va a dar un contexto más claro del proyecto, tu posición y la empresa, y tomar decisiones con más información.

Usá la aplicación!

Probala en producción o en staging o donde sea. No siempre es aplicable (puede que estés arrancando el desarrollo de 0, o que sea una librería compleja o algo así), pero literalmente probar a ver que tal te parece lo que estas meter mano es una de las mejores formas de entender “de que va” el sistema.

Lo Importante es Mantenerse en Movimiento

No tengas miedo de pedir ayuda, pero no te duermas en los laureles y seguí probando y avanzando todo lo que puedas, y no te cierres si las cosas no salen.

Continuará

Como esto se está haciendo demasiado largo ya, en el próximo artículo, comparto unos cuantos consejos a la hora de encarar los primeros tickets que nos tiren, para esos días de transición y onboarding.