DEV Community: Santiago Persico

Programación Basada en Slogans

Santiago Persico — Tue, 18 Apr 2023 15:08:51 +0000

El software existe para proporcionar valor a alguien. Generalmente a nuestros clientes o empleadores. Como desarrolladores, se nos paga para construir software de la forma más efectivamente posible, para maximizar ese valor.

Como profesionales, tratamos de que nuestro código haga lo que tenga que hacer, y que sea fácil de mantener y mejorar a futuro. Para eso, hacemos uso de Patrones de Diseño que son, en esencia, soluciones comprobadas ante problemas habituales, que sirven como guía para tomar decisiones al momento de construir software.

Muchas veces los conocemos a través de mini frases, o eslóganes, como Don't Repeat Yourself, Don't Reinvent the Wheel, Keep It Simple, Stupid, Composition over Inheritance, y varias otras.

Todo esto tiene un punto, pero para eso quiero arrancar con dos de estas frases: DRY y Don’t Reinvent the Wheel.

DRY

DRY, ó Don’t Repeat Yourself, es un principio de diseño de software bastante conocido. La idea general es que la repetición de código debe evitarse, ya que dificulta mantener una pieza de software, a medida que esta va creciendo.

La lógica tiene sentido, si duplicamos código, a la hora de cambiarlo o arreglarlo, uno tiene que acordarse de arreglarlo en todos los lugares donde este se usa, y cada uno de estos lugares puede que tenga comportamientos diferentes. Esto conlleva VARIOS problemas:

Puede que te olvides de aplicar un cambio en alguno de los lugares repetidos.
Probablemente, va a llevar más tiempo al tener que aplicarlo (y probarlo) en todos los lugares donde se repita.
Puede que al aplicar el cambio, lo apliques de la misma forma en código que tiene o contextos diferentes, o comportamientos esperados diferentes.
Ligado al anterior, puede no ser inmediatamente obvio el hecho de que dos piezas de código hagan lo mismo, pero estén en lugares diferentes.

Okay, te vendí un montón el porqué aplicar DRY, del porqué evitar la duplicación de código. ¿Entonces cuál es el problema?

Bueno, de lo que no se habla mucho, es que aplicar DRY (y generalmente de la aplicación de patrones de diseño), conlleva una serie de desventajas:

Problema 1 - Acoplamiento

¿Qué pasa cuando tu Manager, o el equipo de Producto o UX, decide que de los 35 inputs que hiciste, quieren que uno (solo uno) en particular se comporte de forma diferente?

Si, el código DRY, generalmente es código más acoplado. ¿Se puede resolver esto? ¡Seguro! Podemos agregar ifs por todos lados, o implementar otros patrones para solucionarlo de forma prolija, pero siempre a costa de más complejidad.

El código, al unificarse, no puede evolucionar de forma independiente, es generalmente un todo o nada.

Problema 2 - Complejidad y Tiempo

¿Cuánto tiempo te lleva hacer un componente genérico, frente a uno bien especifico para un caso particular? No me arriesgo al decir que el genérico, que contempla más casos, te lleva más tiempo.

Hacer componentes genéricos, conlleva hacer componentes que son más versátiles. Esto en la gran mayoría de los casos lleva más tiempo que hacerlos específicos para el caso a considerar.

El aumento de complejidad no solo afecta al tiempo de desarrollo inicial, sino a la dificultad de manutención de los componentes:

Dale la tarea a un junior de agregar una validación extra a esa función que genera CRUD automáticos de forma mágica en el backend hace meses, y miralo llorar.

Y sí, seguro de que el generador de Forms genérico que se usa en toda la empresa funciona bien, pero si le toca hacer un cambio que le pidieron al nuevo, de que algunos mensajes de error estén en mayúscula y en violeta, le va a llevar mucho más tiempo.

La complejidad es un concepto un poco difícil de explicar. A efectos prácticos, digamos que es la tasa de “Que Carajo” por minuto que te genere leer una pieza de código.

Aumentar la complejidad de una pieza de software, implica aumentar la curva de dificultad de un nuevo desarrollador en el equipo (o de un junior/semi-senior) a la hora de entender y poder mantener una pieza de código. Esto no es poca cosa, porque de nuevo: se nos paga para hacer código mantenible y mejorable.

Cambiemos de eslogan antes de que me tiren con algo. Voy a volver a este tema al final.

Don’t Reinvent the Wheel

Que pasa si tomamos DRY, y lo aplicamos en todo un ecosistema de desarrollo de software?. No reinventar la rueda (Don’t Reinvent the Wheel) es otro eslogan que se suele escuchar bastante, relacionado con el anterior.

La idea es que como desarrolladores, teniendo en cuenta que nuestro trabajo implica producir software que genere valor a nuestros clientes, no deberíamos intentar hacer todo desde cero, sino reutilizar donde podamos el código.

Bastante parecido a DRY, pero con código de otros, ¿verdad?

La realidad es que la industria del desarrollo web, en parte, creció gracias a este patrón. La web está construida, desde el principio, sobre los hombros de gigantes. Sin el Open Source, y al ecosistema de aplicaciones que nos da NPM y Node, la web no sería lo que es hoy.

Las razones son simples: Dinero y Tiempo

Para una empresa emergente, el tiempo entre idea y MVP puede llegar a ser cortísimo, y el coste de alcanzar una audiencia grande, bastante bajo.

Con herramientas y productos como Wordpress, Wix, Squarespace o Shopify, una empresa puede levantar un proyecto en re poco tiempo de forma muy barata, y si nos vamos más a lo nuestro, los frameworks y librerías que usamos abstraen mucha de la complejidad que implica hacer una aplicación, reduciendo el tiempo y esfuerzo necesario para hacer algo hoy en día.

No solo eso, sino que cuando el código es probado, revisado, y mejorado por más gente, generalmente mejora.

React y Angular son mejores hoy que hace unos años, por simple hecho de que tienen gente interesada en ellos, que aporta con revisiones de código, bug reports, casos de uso, optimizaciones, tiempo, plata.

Esto va haciendo que la calidad, performance y seguridad mejore.

Pero, al final del día, este enfoque también tiene problemas:

Problema 1 - Es un montón de Código

Las librerías de las que dependemos generalmente hacen lugar para tantos, pero tantos casos de uso, que por más tree-shaking que hagamos, el código que se corre no es el óptimo, que no sea la herramienta correcta. Estamos enviando enormes cantidades de JavaScript a nuestros usuarios, en gran medida por incluir librerías y código que no nos hacen falta, no realmente.

Simplemente, porque ese código hace demasiadas cosas. Y el problema se va agravando año a año.

Esta es la cantidad de kilobytes de JavaScript enviados este último año en promedio desde hace unos 3 años a ahora.

Este número debería ir en descenso!. Las API de los navegadores se van haciendo mejores y más fáciles de usar, estamos creando herramientas para eliminar código muerto, pero la tendencia sigue en alza, y seguimos pusheando cada vez más código.

Problema 2 - Supply Chain Attacks (Ataque a Cadena de Suministro)

No solamente nuestro software puede terminar siendo más lento, sino que también puede ser menos seguro. Las dependencias abren nuevos vectores de ataque en nuestras computadoras, y a las de nuestros clientes y usuarios.

Traducción: Arriba: Toda la infraestructura moderna digital.
Abajo: el proyecto de un loco cualquiera que lo viene manteniendo desde 2003.

A veces no tomamos en consideración, lo mucho que estamos confiando en otros programadores a la hora de ejecutar npm install (o sus equivalentes) en nuestras computadoras. El proceso de instalación de dependencias permite correr software aleatorio con un MONTÓN de permisos. Y cada vez se ve más y más software malicioso siendo subido a NPM.

Y cada vez pasa más seguido, que gente malintencionada (o perturbada) rompa nuestras apps o librerías, porque todo depende de todo, todo por No Reinventar la Rueda, aun cuando hay razones para hacerlo.

Y por si no me creen, les cuento de algunos casos reales:

OpenSSL se encarga de firmar las peticiones y respuestas para cientos de millones de usuarios, en millones de servidores. A pesar de esto, era mantenida solo por 4 desarrolladores, de hobby nomás. Apareció un agujero de seguridad, y tardaron 3 años en darse cuenta de que un atacante podía, de forma bastante fácil, obtener mucha información confidencial.
En otro caso, un desarrollador que había hecho como 250 paquetes de NPM, decidió sacarlos a todos del registro. Rompiendo por ello miles y miles de apps y librerías. Por primera vez en su historia, NPM republicó un paquete que había sido borrado por su creador. No fue la última vez que pasó algo así.

// Esto es, literalmente, toda la librería leftpad.
// Solo le agrega caracteres a un string
module.exports = leftpad;

function leftpad (str, len, ch) {
  str = String(str);
  var i = -1;
  if (!ch && ch !== 0) ch = ' ';
  len = len - str.length;

  while (++i < len) {
    str = ch + str;
  }

  return str;
}

También hubo un tema con ESLint, donde una dependencia/plug-in muy popular, empezó a meter malware en la PC de muchos desarrolladores. El proceso de NPM install descargaba un archivo de texto, que era básicamente un virus que después ejecutaba.

Problema 3 - No entender cómo funciona la rueda

Más de una vez vi gente que en vez de filtrar un array, con los métodos de filtrado de array, importa lodash. Esto nos atrasa como profesionales, tenerle miedo a reinventar la rueda también implica que no tenemos incentivos para aprender cómo funciona. Aunque sea para aprender nomás.

Aclaraciones sobre WET y Zero-Deps

Antes de que me tiren con algo, voy a mencionar que ante DRY, existe WET, que propone siempre escribir todo código al menos dos veces antes de abstraer, para tener una imagen mejor formada de lo que se planea abstraer y simplificar. Es un approach que me gusta más, pero que tampoco seguiría a ciegas.

Frente a Don’t Reinvent the Wheel, hay librerías que se jactan de no tener dependencias y que por ello, sí, son inmunes a supply chain attacks, pero eso no implica que esas mismas librerías no vayan a ser las que tengan problemas de seguridad u otros problemas.

Conclusión

La solución no es un approach o el otro el 100 % del tiempo. No hay balas de plata. Todo patrón tiene implicancias positivas y negativas en su aplicación y entender el balance de pros y contras es parte de nuestro trabajo. Siempre hay una contra, aunque esta sea el aumento de complejidad de aplicación que desarrollamos.

El resultado neto de su aplicación suele ser positivo, especialmente para programadores junior, ya que funcionan como guía de estilo a seguir, frente a la incertidumbre. Para alguien que recién arranca, seguir un patrón a ciegas es mejor opción que avanzar a oscuras.

Pero es importante no ser dogmático al respecto.

A medida que vamos creciendo profesionalmente, tenemos que empezar a considerar los contras que tienen nuestras prácticas, a tomar las cosas con pinzas y de forma pragmática, y a tener en consideración los posibles problemas que pueden surgir, para tomar decisiones informadas, y preparados para las posibles consecuencias.

Eso es lo que me interesa que se lleven de este artículo, de que cuando vean uno de esos eslóganes, piensen “okay, pero por qué?”, y… *“Como lo podría romper?”.*

Eso es todo. Suerte! 🤙🏻

Si te quedaste con ganas de Leer más, y sabes inglés, acá van algunos artículos interesantes del tema:

The Fallacy of Dry.
Moist Code y AHA programming
The Hidden cost of don’t reinvent the wheel
The cost of Javascript 1 y 2.
When to Reinvent the Wheel.
When it’s okay to reinvent the wheel
10 Useles NPM packages with million

Créditos de las imágenes:
Lukas Tennie, Ante Hamersmit, Jeppe Hove Jensen y XKCD Infraestructure comic

Proyecto Nuevo, Problemas Nuevos (2/2)

Santiago Persico — Tue, 01 Mar 2022 00:00:00 +0000

En esta segunda parte de la guía (si no vieron la primera parte, está acá), y asumiendo que ya tenemos el proyecto levantado y una idea general de la arquitectura del sistema y del contexto de negocio en el que trabajamos, voy a compartirte algunos consejos para esos primeros tickets y días de trabajo.

Caminante no hay camino!

En general, a menos que estés haciendo algo realmente muy extraño (como un proyecto de investigación, o algo así), considero que la mejor forma de aprenderte como funciona el código de un proyecto, es haciendo tareas simples en el mismo, generalmente bugfixing.

Y no estoy solo, en mi experiencia, la mayoría de PMs, POs y Líderes Técnicos comparte esta manera de pensar y, al "recién llegado" inicialmente le van a dar tareas más simples para que vaya aprendiendo el proyecto, y limitando el alcance de los problemas que el recién llegado se pueda encontrar o pueda causar.

Por lo que no tengas miedo, que tu equipo y superiores sabe que los primeros días son complicados, y que lleva tiempo amoldarse a un proyecto.

Equilibrando el Tiempo

Como recién llegados, nuestra cabeza tiene que hacer un balance en como usar nuestro tiempo. Queremos al mismo tiempo pasar rápido de hacer estas primeras tareas, y entender el código del proyecto.

Queremos entender el código, para no frustrarnos a futuro cuando tengamos que hacer algo más complicado y no entendamos nada de como funciona y la situación nos sobrepase. Queremos estar preparados digamos.

Y queremos pasar rápido de las primeras tareas, porque el 99.9% de las veces las primeras tareas son más aburridas que chupar un clavo, o mirar el pasto crecer, y aparte nos hace quedar bien con el resto del equipo y la empresa.

Respecto a mindset, recomiendo dejar la brújula en "entendamos como está estructurado en líneas generales el proyecto" y en "entendamos en líneas generales el código involucrado en la tarea". Esto último es importante: no hace falta que entiendas todo, absolutamente todo de lo que estás tocando, lo importante es que entiendas como funciona el contexto de lo que vas a modificar (más o menos) y en caso de que sea algo relacionado con datos, el flujo de datos de la aplicación.

Entendé por donde llegan los datos desde el backend al frontend, o desde la base de datos a la respuesta que tengas que dar de una petición (si, estos consejos aplican para backend también).

Aplicá el método científico:

Reproducir el problema, e identificar el componente más importante.

Si lo que estás haciendo es resolver un bug, lo primero es reproducirlo, el bugfixing es muy difícil y poco confiable si no podés reproducir el problema.

Luego toca identificar el código más relevante en el proyecto. ¿Cómo? Buscando en el código del proyecto, a partir de las palabras que veas en la UI afectada. En el caso de ser un problema de backend, podés buscar a partir del nombre del endpoint.
O más o menos, por donde creas que esté el componente/controlador.
Si no, ¿Tenés QA en el proyecto para preguntarle? Puede que ese error tenga un test que no esté bien armado, o sea algo no cubierto por tests, pero que el QA sepa por donde viene la cosa.

Pudiendo reproducir el bug y el código donde más o menos ocurre, podés empezar a entender el problema específico.

Armar una hipótesis de cuál es el problema y que deberías hacer para resolverlo. Habiendo podido reproducir el problema y sabiendo el componente donde ocurre (puede que a fuerza de debugger y console.log), tratá de identificar porque ocurre, usando la línea temporal de GIT, o investigando la situación. Puede ser muy útil tomar notas o hacer diagramas de lo que vas viendo, para que te ayuden a entender que lo que estás viendo.

Una cosa a tener en cuenta siempre que estés haciendo funcionalidades, es que es posible que lo que estés haciendo ya fué hecho antes en el proyecto. Te recomiendo revisar componentes parecidos, buscate si lo que estás haciendo (o algo parecido) ya fué implementado. No te recomiendo copiar y pegar sin entender (eso es muy peligroso, y te va a hacer quedar mal), pero fijate como se encaró el problema en una situación parecida.

Implementar tu solución.
Probar la solución, si no funciona volver al segundo paso.
Si funciona, dejarla en condiciones, lista para aplicar en un Pull Request.

Cuando te sientas perdido, aplicar el método científico (y tomar notas) puede ser de gran ayuda, para ordenar las ideas y llegar a una solución (o al menos entender el problema).

Anticipá los Problemas, Arrancá por lo Lento:

Tratá de aprovechar el tiempo, asegurando que los supuestos sobre los que se basa tu tarea sean realmente válidos: Si el ticket dice que lo que estás haciendo depende de un endpoint del backend ya existente, probá primero el endpoint, y después te ponés a hacer la UI. ¿Por qué? Porque la comunicación entre equipos usualmente es más lenta que maquetar un div con un par de inputs y un botón, y puede que hagas tu feature en 2 horas y te pases un día esperando por un endpoint.

Por eso, Atacá lo más difícil, probá los supuestos sobre los que se maneja el ticket.

Somos pocos y... ya nos vamos a conocer

Quiero dejar claro tres cosas que creo es lo más importante a recordar y realzar de esta guía:

PEDÍ AYUDA, NO SEAS TERCO.

Esos primeros días se espera que tengas dudas, no tengas miedo de quedar mal.

MANEJÁ TUS EXPECTATIVAS

El proceso de onboarding es una inversión que la empresa hace en vos, ellos saben que tenés que aprender como funciona su proyecto, su código y sus prácticas, por lo que no te persigas a vos mismo por no rendir tanto como el resto del equipo, en esas primeras semanas.

OPINÁ Y DISCUTÍ.

Con respeto y razones, obvio, pero recordá que sos un par más de ojos que pueden ver algo que puede que esté mal. Especialmente en equipos chicos, o en cosas que no tengan una suite de tests como la gente. Tus ideas valen.

ES PREFERIBLE SOBRE-COMUNICAR, QUE SUB-COMUNICAR.

Esto es algo que vi hasta en gente con mucho seniority.
Comunicá el estado de lo que vas haciendo a tu PM, PO, o lo que sea seguido.
Si te trabas, decilo rápido. Es más rápido y eficiente que el PM, PO, o un par te tire un centro a que te trabes por un día entero.

Recordá lo siguiente: El tiempo de los programadores es el recurso más caro y preciado de una empresa. Que te trabes (después de investigar y tratar de resolver/entender algo) es más caro para la empresa a que le avises a tu PM y te tengan que explicar de nuevo un ticket o una parte del código.

Eso es todo, espero que te sirva. ¿Se te ocurren más consejos? Compartilos en un comentario acá mismo!

Te quedaste con ganas de leer más? :

Artículo que me inspiró a escribir esto

Top tips to finding your way around a new codebase

Proyecto Nuevo, Problemas Nuevos (1/2)

Santiago Persico — Tue, 01 Mar 2022 00:00:00 +0000

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:

Sentirte productivo y que no estás atrapado en un pozo.
Quedar bien con tus compañeros y jefes.
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 (que ya está disponible acá), comparto unos cuantos consejos a la hora de encarar los primeros tickets que nos tiren, para esos días de transición y onboarding.