Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Douglas (00:00)
Y es que el code review es tan importante y tiene tantos propósitos. Y de nuevo, esto va variar por proyecto, por empresa, por producto.
Pero un propósito puede ser el senior supervisando al junior para asegurarse de que está siguiendo los estándares correctos, para asegurarse de que va a funcionar de la manera más efectiva, más eficiente, Pero también puede ser simplemente tener un par de ojos frescos. A veces el junior le va a revisar el código al senior.
Aunque sepa menos, pero se va a fijar con ojos nuevos, y sin estar sesgado por algo en particular, Entonces...
Tiene normalmente esas dos connotaciones, un code review, pero más allá de ello, muchas veces las empresas lo que quieren es asegurarse de que varios ojos miren el código antes de que sea publicado.
Juan (00:50)
Un propósito
que en lo personal considero que es bien importante y se pasa de alto es el hecho de que todo el equipo tiene el conocimiento de qué está pasando si bien tal vez yo no estoy al tanto de qué se hace en un proyecto de mi misma empresa pero como estoy haciendo code review tengo ya un conocimiento más tal vez generalizado y no tan profundo pero sé un poco de qué está pasando
Douglas (01:16)
Hola a todos. Sean bienvenidos a un episodio más de Dev & Ops, este espacio donde hablamos de tecnología, desarrollo, DevOps y su cultura en general. Como siempre, estoy acompañado de Juan. Bienvenido, Juan. ¿Qué tal estás?
Juan (01:31)
Hola Douglas, ¿qué tal? Me encuentro muy bien, gracias a Dios. Estamos en un episodio más, un episodio que me gusta, me gusta mucho venir a platicar con vos, me gusta compartir con la gente. que muy bien, encantado de estar aquí Douglas.
Douglas (01:46)
Qué bueno, qué bueno, como
siempre con la buena actitud, como siempre intentando aportar valor a las personas que nos ven y nos escuchan. está en esta ocasión, Juan, con un tema muy interesante, porque lo que queremos hablar hoy es cómo colaborar de manera efectiva en un proyecto de desarrollo, ¿verdad? En esto con un equipo de desarrollo, como lo sabemos vos y yo, no son conformados únicamente por developers, por desarrolladores, ¿verdad?
o no son conformados únicamente por la gente del sistema o de DevOps. Son un equipo grande donde tenemos incluso en desarrollo está backend frontend. A veces si la aplicación es compleja tenemos gente de base de datos especializada, DBAs, tenemos la gente que se encarga de sistemas y aún en la parte de sistemas tenemos gente que se encarga sólo de la parte de redes, gente que se encarga sólo la parte de storage.
Tenemos gente que hace QA, tenemos a los project managers, a los account managers, stakeholders, y si sigo voy a aburrir a las personas. Pero el punto que... puede ser tan complejo o puede ser una empresa de una persona, pero el punto que queremos hacer es que normalmente son equipos, ya sea de algunas cuantas personas o son equipos de mucha gente,
Juan (02:56)
sí él puede ser tan complejo como querramos la
Douglas (03:14)
Y cuando hay más de uno, se requiere colaboración, se requiere trabajar de una manera estratégica de tal forma que no nos paremos en los pies del otro al momento de trabajar, de que no le quitemos la autoridad o lo que le correspondía al otro al momento de trabajar. Y lo que queremos hablar y discutir hoy, Juan, es cómo dar algunas ideas.
de qué hacer, cómo colaborar de manera más efectiva en tu experiencia, qué tanto, qué tanta experiencia o qué tanto conflicto has vivido, creo yo que es la pregunta correcta, o qué tan fluido ha sido tu flujo de trabajo colaborando con personas normalmente.
Juan (03:59)
Sí,
Pues yo he tenido un poco de ambas, poco de experiencia donde ha sido un poco complejo, ¿no? Poder pasar el código y luego tiene que venir una persona en específico y hace cherry pick de los cambios. Hay otros donde es un poco más flexible y fluye más. Creo que la palabra ahí de flujo de trabajo implica eso, ¿no? Que nuestro trabajo y nuestros cambios deben salir. La meta final es
que salga el producto y se despliegue en producción así que qué tanta fricción hay en ese camino eso es lo que nos va a indicar si el flujo que tenemos es muy bueno o a veces también hay fricción que es necesaria porque necesitamos poner ciertas trabas para que no hayan tantos bugs pero sí he tenido un poco experiencia recuerdo que de hecho en un proyectito que trabajábamos vos y yo
y subía los cambios al repositorio y luego tenías que ir y correr los servicios de Node y era un proceso un poco manual, recuerdo en aquel entonces pero ya ahora hay herramientas, gracias a Dios, que nos ayudan a que poco a poco el código salga y ya ni nos damos cuenta a veces de todas las cosas que van pasando por detrás
Douglas (05:28)
No, sí, bueno, parece bien Juan y me gusta lo que está diciendo de la fricción, verdad, porque muchas veces es necesario desde el punto de vista, no como algo de generar conflicto por generar conflicto, sino que nos toca defender lo que estamos haciendo o nuestro punto de vista.
Mientras más tengamos el flujo que ya se ha definido, mientras más mantengamos los estándares que podamos tener como empresa. Y hablando de estándares, quiero mencionar, Juan, y aclarar a las personas que nos ven y nos escuchan, que las ideas que vamos a dar, basadas en nuestra experiencia, en lo que creemos que funciona mejor,
son para o lugar de trabajo donde no hay algo bien definido, bien escrito, bien estructural o donde tal vez para personas que quieren sugerir cosas nuevas en su trabajo, quieren implementar algo nuevo, tienen ideas pero no logran materializar el concepto.
Si estás en una empresa donde ya hay un flujo bien definido, estructurado, donde ya hay estándares de cómo hacer algo, cómo manejar el repositorio, cómo manejar pull requests y las diferentes cosas que vamos a hablar, pues entonces hay que seguirlo. En ese caso hay que seguirlo, hay que acomodarnos a ellos y ser lo más abierto posible para colaborar. Y lo que tal vez a raíz de esto pueden surgirle ideas a algunos de ustedes.
de cosas que pueden implementar, cosas que pueden sugerir en esos trabajos y que pueden explorar. Pero estas ideas van dirigidas para estas personas que no está algo definido. Entonces quería aclarar eso, Juan. No sé si vos tenías algo más que mencionar en ese sentido.
Juan (07:17)
sí
no me parece bien pero incluso si ya está definido algo
si lo que hablamos aquí les parece que es algo que vale la pena sugerirlo yo creo que no no hace daño también hacer cualquier sugerencia que consideren que si mejore el flujo que ya tienen pero de nuevo así así como lo que decías si ya tienen algo y les funciona y consideras que pueden seguir no te presenta un problema pues estamos bien ahí está bien
Douglas (07:51)
Sí, sí, sí, no, no,
muy bien, verdad, muy bien. Estamos de acuerdo en eso entonces, verdad, si algo les parece, hagamos la sugerencia, hay que ir mejorando, propongamos cosas, pero donde ya hay algo definido y no depende de nosotros, sugeramos, pero sigamos cumpliendo las reglas mientras se aprueban cambios. Pero entonces,
Juan (08:13)
Si yo creo Douglas que
perdón a veces creemos que no nos van a escuchar creemos que tal vez nuestra opinión no la van a tomar en cuenta y no a veces es importante dar nuestra opinión y es importante hacer sugerencias que consideremos que van a mejorar al equipo no solamente a mi sino a todos porque la idea aquí es hablar de cosas
Douglas (08:37)
mmm
Juan (08:43)
que nos van a ayudar a todos y y de nuevo no traten de no encasillarse en el pensamiento de que no me van a escuchar en que no me van a hacer caso o que o que me van a ver de menos no a veces bueno lo digo por experiencia a veces creemos que no nos van a escuchar pero lo mejor es hablar si no nos van a escuchar si no hablamos entonces siempre traten de dar sugerencias
Douglas (09:11)
Me gusta ese consejo,
Juan, me gusta porque es parte de ser buenos profesionales, por más que creamos que no nos van a escuchar o por más que nos parezca que somos nuevos, siempre y cuando lo hagamos sin conflicto. Yo creo que esa es la parte que hay que resaltar. No busquemos conflicto, no peleemos, no nos molestemos si dimos la opinión, dimos la sugerencia y no la quisieron tomar.
Juan (09:26)
Claro, claro.
Douglas (09:37)
tratemos de tener una mente abierta en ese sentido, pero me gusta el consejo, definitivamente lo comparto con vos. Pero bien, para que entremos en materia y tal vez empezar a dar estos consejos, de qué hacer o qué implementar para poder colaborar de manera efectiva en un proyecto de desarrollo, y yo creo que lo primero, y...
Juan (09:40)
Sí.
Douglas (10:07)
Eso que viene de mí, que no soy un desarrollador como tal, estoy en la parte de operaciones y de sistemas, pero yo creo que lo primero y lo más importante es definir la estrategia de flujo de trabajo de tu control de versiones, de tu version control, de tu git workflow, como lo quieran llamar, dependiendo de qué forma lo conocen, ya sea en español, en inglés, o por...
diferentes conceptos, pero definir un flujo de trabajo de control de versiones que normalmente es Git, lo que se usa hoy en día, ¿verdad?
hay por ahí algunas cuantas empresas muy antiguas que todavía usan SVN, pero mayormente vamos a trabajar con Git. definir ese flujo de trabajo que nos permita la colaboración, que nos evite en la medida de lo posible conflictos a la hora de hacer merge de diferentes branches, nos evite perder el historial de cambios, que nos permita colaborar.
de forma fluida, aun cuando diferentes personas están trabajando, ya sea en la misma funcionalidad o en funcionalidades similares, verdad. Entonces yo creo que es clave Juan, comenzar definiendo ese flujo de trabajo, ese Git Workflow. ¿Vos qué pensás?
Juan (11:39)
Me parece que tenes toda la razón Al final del día, Git Y es cierto, a veces hay empresas que utilizan otras opciones Pero seamos honestos, hoy por hoy es Git De vez en cuando me salen unos cuantos videos en Youtube acerca de el nuevo GitKiller Siempre aparece por ahí Pero no, es Git Si, hay varias estrategias para versionar nuestro código
me gusta a mí es Git Flow pero no es algo que si mi consejo le vale no es algo que tiene que ser tan específico yo creo que siempre va a depender de cada empresa cómo van a estructurar estas o definir las ramas que vamos a tener en nuestro proyecto hay empresas que tienen una rama llamada producción y hay otras empresas que la rama master o main es producción
ese tipo de cosas creo que no son tan importantes, sin embargo lo importante aquí es como decías que varias personas puedan trabajar al mismo tiempo sin influir o sin afectar a los demás no importa si yo estoy trabajando en el mismo archivo, el mismo proyecto, en el mismo módulo no va afectar con los demás y eso por un
lado
no por otro lado a mí en lo personal Douglas me gusta mucho las categorías en las ramas me refiero a nombrar una rama como feature es un feature branch también llamarla como hotfix bug fix yo suelo hacer esa distinción para mí un bug fix una rama que empieza como bug fix es eso no estoy corrigiendo un bug pero que tal vez no es tan crítico sin embargo un hotfix
si es un bug que requiere atención inmediata y eso va directamente a producción sin pasar por el ambiente de testing o staging que tengamos definido un hotfix va directamente porque está corrigiendo algo que requiere nuestra atención entonces al utilizar estos prefijos solamente como consejo, esto es lo que a mí me funciona me gusta porque ya de entrada yo con solo ver el nombre del branch ya sé
la severidad ya sé qué es lo que tiene pero bueno eso son cosas que van definiendo las empresas y lo van van encontrando cuál es la forma que mejor les funciona yo he trabajado en proyectos donde bueno al inicio no cuando empezaba a conocer sobre git en una empresa trabajamos donde definíamos las ramas con el nombre de cada uno de los desarrolladores y yo ahí trabajaba yo tenía mi rama
y allá decía todo lo que yo necesitaba hacer. Pero bueno, las empresas van evolucionando, de eso se trata, ir aprendiendo sobre la marcha a veces.
Douglas (14:48)
Sí, me resulta gracioso
porque yo recuerdo esa evolución también de VersoControl en general, de SVN, porque antes de Git, SVN era lo más utilizado. Y esas diferentes fases de descubrimiento de la industria. Y yo recuerdo muy bien eso de desarrolladores con su propia branch, que ahí trabajaban y luego ellos hacían sumers a...
Juan (14:57)
Sí.
No,
Douglas (15:16)
un branch de development y así van subiendo o branches no necesariamente por funcionalidad o feature o fix, sino que de repente alguien surgía como un branch nuevo porque le ponía el nombre del ticket al branch. Pero bien, creo que el punto Juan que se está haciendo es definir el flujo, definir la estrategia de Git y esto puede ser...
Juan (15:19)
Sí.
Douglas (15:44)
tan sencilla o tan compleja como lo es el proyecto en el que estamos trabajando. Los tres más comunes que existen y no vamos a ahondar en ellos porque el tema principal es cómo ser efectivos al colaborar.
estamos hablando específicamente ahorita estamos tocando el punto del repositorio de Git pero vamos a tocar más puntos pero las estrategias más usadas aunque no vamos a andar en ellas son el Git Flow, el Feature Branch Workflow.
Juan (16:07)
Sí.
Douglas (16:20)
y el GitHub Flow, esas son las más utilizadas. Si mal no recuerdo, las primeras dos las hizo populares a Atlassian, los de Jira, y el GitHub Flow es para trabajar en GitHub, meramente. normalmente las empresas o adoptan una de estas tres o se derivan.
Juan (16:29)
Ok.
Douglas (16:43)
de una de estas tres y le adaptan sus cositas dependiendo su proyecto, su flujo, lo que mejor les funcione. En lo personal me gusta más trabajar con el feature branch workflow, ¿verdad? Pero al final la idea es definir tu estrategia de branches, como vos dijiste, es tener una rama principal, normalmente llamada main o master, y de esa rama principal, de ahí creas tus branches.
por feature, que vos dijiste, ponerle prefix y todas esas cosas. De nuevo, puede ser tan complejo, tan sencillo, dependiendo de la aplicación, muchas veces el producto final no es publicar algo a un hosting, ¿verdad? Muchas veces tu producto final es un plugin, es un paquete, ¿verdad? Y entonces lo que eso va a generar en realidad es un nuevo tag, una nueva versión de ese paquete o de ese plugin y en realidad no va a ser publicado. Entonces...
Como flujo va a incluir que antes del release va a haber un tag. Y el tag puede salir de un release branch, el tag puede salir del main branch. Y de nuevo, lo importante es definir ese git flow, ese flujo de trabajo de cómo se va manejar el repositorio y cómo se va a interactuar con los diferentes desarrolladores. Y de la mano con esto, Juan,
Juan (17:47)
Sí.
Douglas (18:09)
viene algo muy importante, que es el momento de interactuar, viene lo que es el code review. ¿Verdad? Estamos trabajando en un flujo, ya sé cómo voy a crear mis branches, dónde se va a merchear pero necesitamos más visibilidad. Y es que el code review es tan importante y tiene tantos propósitos. Y de nuevo, esto va variar por proyecto, por empresa, por producto.
Pero un propósito puede ser el senior supervisando al junior para asegurarse de que está siguiendo los estándares correctos, para asegurarse de que va a funcionar de la manera más efectiva, más eficiente, ¿verdad? Pero también puede ser simplemente tener un par de ojos frescos. A veces el junior le va a revisar el código al senior.
Aunque sepa menos, pero se va a fijar con ojos nuevos, verdad, y sin estar sesgado por algo en particular, sintaxis, typos. A veces el mensaje de error que devolvemos tiene un error ortográfico, verdad, o simplemente con ojos nuevos y decir, hey, esto está bonito, pero está sobrecomplicado. Un simple if statement aquí me resolvía lo que quería. Entonces...
Tiene normalmente esas dos connotaciones, un code review, pero más allá de ello, muchas veces las empresas lo que quieren es asegurarse de que varios ojos miren el código antes de que sea publicado. Entonces, en cuestión de code review, ¿cuál es tanto tu experiencia y cuáles son tus consejos con ello?
Juan (19:49)
Sí, mi experiencia con el Code Review... ⁓
La verdad, ser muy honesto, empezó mucho tiempo después en mi carrera porque, bueno, como te mencionaba, ha ido evolucionando como las empresas lo han estado utilizando. pues, si teníamos una rama llamada Juan, pues te puedes imaginar que no teníamos un proceso de code review tan pulido. Me gusta mucho cuando las empresas sugieren que
Douglas (20:15)
Mm-hmm.
Juan (20:23)
todo el mundo haga code review. Como decías, a veces es el junior quien hace code review al senior. Y eso está bien, porque code review no se trata solamente de buscar errores, no se trata de optimizar el código y estar como el policía o el guardia de la sintaxis. No, el code review también, como decías, tiene diferentes propósitos. Un propósito
que en lo personal considero que es bien importante y se pasa de alto es el hecho de que todo el equipo tiene el conocimiento de qué está pasando si bien tal vez yo no estoy al tanto de qué se hace en un proyecto de mi misma empresa pero como estoy haciendo code review tengo ya un conocimiento más tal vez generalizado y no tan profundo pero sé un poco de qué está pasando también me ha pasado en otros lados que
y estoy seguro que a cualquiera que escuche le ha pasado, que hacemos un código, una función que luego nos damos cuenta que está duplicada porque alguien más ya la había hecho. En cambio si nos involucramos más en los code reviews vamos a tener al menos una noción en nuestra mente de que esto creo que ya lo han hecho o sabemos que existe un módulo dentro de nuestro proyecto que debería alojar una función similar. Entonces podemos ir a
si no existe entonces lo hacemos. Así que esta visibilidad que tenemos con nuestro equipo de trabajo al momento de hacer code reviews es súper importante. Más allá del hecho de buscar errores que pues todos lo tenemos, A mí en lo personal se me pasan mucho los typos y esos son los que siempre me piden que cambien los code reviews pero creo que eso es muy importante. También es como un consejo
consejo digamos general, no tanto sobre las metodologías, es que cuando estamos haciendo code review o nos hacen code review, tenemos que mentalizarnos en el puesto que estamos ocupando.
Lo que quiero decir es que si estamos haciendo Code Review tenemos que adherirnos a las estándares que tienen. Si no hay un estándar, entonces ahí sí podemos ir un poco más laxos y tratar de revisar lo que consideramos bien. También cuando nos hacen Code Review hay que... Creo que a veces en el tema de la programación a veces nos metemos en batallas o en peleas
que siento que no valen la pena. han hecho a veces sugerencias en mi código donde me han dicho, deberías quitar estas go routines, este proceso concurrente, no hacer para... se me fue la palabra... paralelismo.
Douglas (23:26)
Paralelismo. Ajá.
Juan (23:30)
Y a pesar de que en mi mente yo lo veo que sí puede ser útil, pues a veces no se trata de eso, ¿no? A veces se trata de tener un código que todos puedan entender bien y que todos estemos de acuerdo en que funciona, ¿no? Hacer código muy complejo solo porque sí, también crea fricción en los code reviews porque la persona que nos empieza a revisar el código no va a
entender y recordemos que la persona que nos está revisando el código está apartando su tiempo, un tiempo que podría estar utilizando para hacer otras cosas dentro de la empresa, entonces lo que nosotros tenemos que priorizar es darle todo ya bien definido y bien hecho para que sólo lleguen revisen lo más rápido pero sin apuros lo más rápido posible, entonces es muy importante tener una descripción de por qué se hizo
cómo se hizo, no sobrecomplicar el código y de esa forma vamos a tener un flujo de revisión mucho más a menos siento yo. Como te digo la idea es que todos estemos al tanto del código, podamos detectar a tiempo algún fallo y dar sugerencias de algo que notemos en el código. En mi experiencia yo así lo he vivido.
Douglas (24:57)
Me gusta bastante lo que está diciendo
Juan y hay bastante tela que cortar en lo que está diciendo y aunque no vamos a profundizar tanto en esto, me gusta que recalcas...
de que si tu empresa tiene ya estándares, hay que seguirlos. Si no los tiene, entonces, fluir un poco más y ser consciente de darle velocidad al proceso. que dijiste de no sobrecomplicar el código o cuando a veces te han hecho sugerencias de que no pongas un go routine o no hagas esto. Si una empresa, el estándar pide que lo pongas o que no lo pongas, entonces, lo seguimos al momento de code review. Si la estándar no lo dice.
Juan (25:38)
Sí.
Douglas (25:40)
podemos ser un poco más fluidos en beneficio de darle velocidad al proceso. Me gusta lo que decir de los propósitos que tiene el Code Review, verdad, y que a veces no tengo que ser experto para hacerlo, Code Review otra persona. Me ocurrió recientemente, perdón, hace tres semanas tal vez.
Yo le pedía a los desarrolladores para poder publicar la aplicación que creara un endpoint de HealthCheck porque necesitaba... los contenedores se crean y hay unos balancers encima y tiene que ver que la aplicación está viva. Entonces, les dije yo, necesito un endpoint de HealthCheck.
Juan (26:11)
Ok.
Si,
básicamente, para los que no sepan, los orquestradores pueden revisar un endpoint y dependiendo de lo que resulte ese endpoint, determinan si ese contenedor está bien o no, correcto?
Douglas (26:34)
Sí, sí, gracias por la aclaración
Juan. Sí, definitivamente los load balancers o los orquestradores revisan un endpoint y si dependiendo qué devuelve saben si la aplicación funciona o no en ese contenedor o en esa máquina virtual o en ese servidor dependiendo qué se esté haciendo. En este caso era una aplicación corriendo en Kubernetes eran pods y se ocupaba un endpoint.
Juan (26:52)
Ok, ok.
Douglas (26:58)
arriba hay un load balancer porque esto corre en AWS y ocupaba un endpoint para ver que funcionara entonces yo le pedí a los desarrolladores y me dijeron que necesitás ocupa un endpoint pleca health check o como lo quieran llamar que me devuelva un código 200 si la aplicación está corriendo bien le puedes poner un mensaje si querés al final yo voy a ver el código 200 perfecto me dijeron
La aplicación era en Node.js, hicieron el cambio y me dijo, lo hicieron bien rápido, ¿verdad? Y me dijo, me mando el pull request y que le hiciera code review, revisar el código. Yo no programo JavaScript, yo no sé JavaScript, sin embargo, tengo tanto tiempo en la industria, porque gracias a Dios uno interpreta un poco el código. Mientras no sea tan complicado, y ese era crear un nuevo endpoint en un framework, entonces, mi respuesta fue decirle...
No soy programador de Node.js, de JavaScript, pero me parece que sí es eso lo que necesito. Entonces la respuesta de él fue, si te parece que eso es lo que ocupas, entonces dale click en approve y te graduamos como programador de JavaScript. Le hizo la broma, Ajá, ya te certificamos. Pero lo que ocurre es que ese proyecto en particular para ese cliente se requería
Juan (28:07)
Está certificado ya ante sus ojos.
Douglas (28:18)
otros ojos en el código y se requería que alguien le diera a prove, ¿verdad? Entonces, a pesar de no saber JavaScript, entendí lo suficiente como para hacerme la idea de que eso era, si eso hubiese fallado, no hubiese caído sobre mi culpa porque nadie anda buscando a quién culpar. Ya se sabe que yo no hago JavaScript. La idea era que otros ojos vieran ese código y que otros ojos tuvieran la sensación de que funciona como se espera.
y que cliquearan a approve, ¿verdad? Entonces, de lo que vos me dijiste es, me recordó esa experiencia y
también me gustó la parte que dijiste Juan y aquí quisiera conectarlo para que sigamos avanzando con el tema de que también parte de ellos es que todos tengamos visibilidad con que se está haciendo y que puede que esté haciendo una función que ya existe, no con ese nombre.
pero hace lo mismo, ¿verdad? Y que parte de eso, Juan, y lo comparto, ¿no? Lo comparto. Si hacemos code review, todos vemos que hay. Pero parte de eso también es asegurarnos de que esté bien documentado. Y es ahí donde cuando hacemos un pull request, que eso es en GitHub, se llaman pull requests. Si lo haces en GitLab, se llama merge request.
Juan (29:23)
Sí.
Douglas (29:41)
es el mismo concepto, es un request a alguien para que revise el código y si todo está bien se va a mersear el código con un branch, verdad, es lo que va hacer al final. Pero en este proceso tenemos la opción de dar información, la mayor cantidad de información posible va a ser mejor, puede ser el ticket,
Juan (29:50)
Sí.
Douglas (30:05)
en la url del ticket donde se está manejando que tenga una descripción de qué hice cómo lo hice verdad pero también pueden haber checklists de si seguí los estándares de nombrar variables si leí la documentación antes si actualicé documentación de ser necesario actualizar documentación todo eso puede ir en la descripción del pull request verdad
Entonces, si todo eso está contenido ahí, y como ya definimos el flujo, y parte de ello era cuando vos ves eso y decís, hey, lo primero es que yo haya revisado la documentación. Si te bajas la documentación y por el pull request, los estándares, previamente alguien ya hizo una función igual y la documentó, vos solo la vas a consumir. ¿Verdad? Entonces...
es vital, es importante que la información que ponemos en los pull requests sea lo más descriptiva posible, incluyendo escenarios, qué testear, qué resultados esperar, qué documentación se actualizó y todo lo posible, ¿verdad? Entonces, ¿cuál es tu pensamiento en ese sentido, ¿O vos crees que podemos ser ligeros en la información en un pull request?
Juan (31:28)
considero que... ehm... ok. ⁓
Existen muchos procesos que se definen en las empresas y yo creo que vale la pena definir este Vale la pena definir, ok, cuando vas a hacer un pull request, que vas a hacer, que tienes que hacer previamente Si alguien no tiene muy claro cómo debería ser un template de este tipo Yo les puedo recomendar que revisen los pull requests de los proyectos open source Generalmente estos proyectos ya tienen
este tipo de plantillas como las que estás diciendo ellos te recalcan que si vas a contribuir tenés que hacer estos pasos y cuando haces el pull request pegás esos pasos y les vas dando check a los que has concluido entonces en ese aspecto yo creo que vale la pena hay algunas cosas que por ejemplo se pueden ir dando bueno algo que mencionabas
visto cuando ponen el enlace hacia el ticket, en día yo soy un poquito, estoy un poco más no en contra pero no me gusta a tener eso, me gusta más que el pull request en sí tenga la información, aún si es que copiamos el texto que estaba en el ticket me gusta porque tenemos que dar menos vueltas, ya está todo ahí pasa
Douglas (32:56)
o alguien puede que no tenga acceso al ticket porque suelen ser privados los proyectos
Juan (33:02)
si a veces pasa eso entonces si podemos ver en la descripción del pull request directamente por qué se está haciendo y para qué no entonces creo que es mejor también estoy yo a veces es pareciera que es innecesario a veces son pull request muy pequeños es un archivo y sólo estamos cambiando una línea de código y con el título lo decimos todo entonces a veces
es que es mucho más trabajo, en sí no se trata de qué tan cómodo es, sino se trata de definir un estándar que evita que en un futuro cometamos un error por no haber seguido estos pasos que están dados. Si nos están dando estos pasos es por algo, es para evitar que suceda este tipo de cosas. Entonces yo estoy de acuerdo en que se definan esos procesos. A veces no están definidos.
Douglas (33:53)
Exacto.
Juan (34:02)
no importa pero si no están definidos en tu empresa mi consejo es en la descripción del pull request incluí toda la información que se pueda y que información es por qué se está haciendo el cambio cómo se implementó y qué impacto puede tener entonces yo creo que con eso algo muy básico se puede hacer
Douglas (34:23)
Sí, sí, no,
muy de acuerdo Juan y aquí hay, sólo en esta parte, definir la estrategia de cómo manejar el repositorio, el Git, Flow, los diferentes branches, hay tantas experiencias personales que puedo contar como tips que podemos dar, sin embargo, el punto es para colaborar bien, definamos un buen flujo de trabajo con tu repositorio, con Git, ¿verdad?
Juan (34:46)
hay que hacerlo.
Douglas (34:52)
y continuando Juan con la plática, estas pláticas que nuestra intención siempre es...
generarle valor a las personas que nos ven y nos escuchan. Quiero aprovechar el espacio para agradecerles a todos por tomarse el tiempo de vernos, escucharnos, aparte de tomarse el tiempo de interactuar con nosotros en las diferentes redes sociales, en las diferentes plataformas de streaming, dándonos like, dejando comentarios, compartiendo el contenido con personas a las que les pueda ser de valor también. Entonces estamos
muy agradecidos para nosotros, eso significa mucho y es la intención crear esa comunidad que pueda aportar valor.
que pueda darle ideas a las personas o que puedan aprender de errores nuestros porque no hemos sido perfectos, no pretendemos ser perfectos y muchas veces aprenden más de los errores y muchos de nuestros consejos son por favor no cometan el error que yo cometí. muchas gracias por vernos, por seguirnos y por interactuar con nosotros en redes sociales, para nosotros vale mucho y por favor no dejen de seguirlo haciendo.
Juan (35:42)
Sí.
si si por favor denle like, denle follow en la descripción de los videos siempre dejamos los enlaces a nuestras diferentes redes sociales así que pueden revisarlo para que nos regalen ese like
Douglas (36:14)
Sí, sí,
muchas gracias, muchas gracias. Continuando, Juan, ya tenemos claro que para poder colaborar defendemos la estrategia de manejar el repositorio, un Git workflow. Yo creo, y tal vez aquí nos estamos dando como en el orden...
necesario, sin embargo los tips que vamos a dar yo consideraría que tienen que ir todos, ¿verdad? Pero algo que tenemos que hacer es definir escenarios de QA, ¿verdad? QA es Quality Assurance es este proceso que se asegura que el producto que estamos haciendo funciona bien y es de calidad, por eso es...
Quality Assurances, control de calidad, le decimos en español. Y es que cuando tenemos una aplicación, ya sea un paquete, una herramienta, una aplicación que se va publicar, una página web, cualquiera que sea el proyecto en el que estamos trabajando y colaborando, debería de existir un proceso de QA para asegurarnos de que funciona como tiene que ser. Y se comienza.
Juan (37:00)
Sí.
Douglas (37:24)
escribiendo en una empresa como elaborada, grande y que tiene su propio departamento o mínimo tienen una persona que hace QA, ¿verdad? Si no lo tienen en su empresa, yo sugiero que siempre definan estas cosas y que entre los programadores se dividan ese trabajo de hacer QA. Es súper importante, no se lo brinquen y por eso lo estamos dando como consejo, ¿verdad?
Pero hay que escribir esos escenarios de QA, es decir, cada vez que hay una aplicación y tenemos una página y tenemos una sección de promociones, entonces eso es súper importante. Entonces hacer un escenario de cómo testear las promociones, cómo asegurarnos de que la página está jalando las promociones de manera correcta. Y es importante el login. escribir los escenarios, literalmente escribir eso es, ¿verdad?
de que se va a testear en el login y como se va a testear y que respuesta se espera para que el QA lo haga y así definir y escribir los diferentes escenarios para que el QA que puede ser manual o puede ser automatizado todo lo que se pueda automatizar automatizanlo es super importante pero hay algunos hay algunos pasos que tienen que ser manuales ¿Verdad?
Juan (38:41)
Sí.
Douglas (38:46)
hay algunos pasos que tienen que ser manuales sí o sí, aunque les parezca un poco desagradable la idea, hay algunos pasos que tienen que ser manual, pero se escriben, se definen y eso se ejecutan, esos pasos de QA, ya sea manual o ya sea automatizado, cada vez que se hacen cambios a la aplicación, antes de publicar una nueva funcionalidad, antes de publicar un fix, antes de publicar cualquier cosa que se va a hacer,
en los diferentes ambientes de prueba para asegurarse que esos cambios no van a romper la aplicación.
Muchas veces creemos que porque estoy trabajando en la respuesta de una función totalmente aislada al login, no va a romper el login. Pero tal vez había alguna funcionalidad que no estaba documentada, tal vez había algo que yo no me percaté, tal vez le di commit a un file que no me fijé y quien hizo QA no lo notó, ¿verdad? Y puede terminar en producción algo que aunque está remotamente.
ligado al login, terminó rompiendo el login, es importante que se escriban esos escenarios de QA y por ende, implementar un proceso de QA en el workflow.
de colaboración con la intención de evitar que lleguen errores a producción. Entonces, para mí es muy importante, Juan, cuál es tu punto de vista o qué opinión te merece a vos lo que es el QA. ⁓
Juan (40:22)
QA es ese departamento, esa sección que los desarrolladores como que la vemos un poco renuente, no nos gusta un poco, sí, nos rechazan el código. Pero sí, totalmente es necesario. Es necesario asegurarnos que la aplicación no importa que siga funcionando. Eso es. Y bueno, QA también
Douglas (40:32)
con odio
Juan (40:52)
va ligado con algo que podemos ir mencionando más adelante, cómo automatizar todos estos procesos mencionabas que a veces hay algunos que son manuales yo tengo la esperanza que todo va a ser automatizado en algún punto ya hay procesos para automatizar el UI entonces no sé yo creo que bueno la función principal es eso asegurarnos que no hay
hayan problemas y que no haya algo que rompa otra cosa que no esperábamos. Al final del día, estas pruebas que hacemos, ya sea un integration test, un unit test o una prueba que hace una persona manualmente,
pues la finalidad es eso, que no se rompa el código. ¿Cuándo estamos bien? Desde mi punto de vista Douglas, yo diría que estamos muy bien en cuanto a...
el Quality Assurance cuando nosotros podemos publicar un viernes publicar un viernes es... prohibido para todos los developers sin embargo yo creo que no debería ser así debería ser posible que si yo el viernes en la mañana, el viernes en la tarde necesito publicar algo lo pueda hacer porque tengo que esperar hasta el siguiente día y claro estamos de acuerdo que nadie quiere ir un domingo por si ya sucede algo pero
Douglas (42:01)
No,
Juan (42:25)
antes de que suceda un problema tienen que haber muchos procesos y uno de ellos es el de QA tiene que estar bien seteado y más cuando como decía no si se puede automatizar hay que hacerlo porque así ahí es donde realmente el sistema se revisa a sí mismo y evita que que veces que sucedan problemas que una persona tal vez pasó por alto no somos perfectos hay errores humanos que la computadora
puede poder revisar antes pero sí es necesario el QA definitivamente
Douglas (43:00)
Sí, no está sugiriendo que
se publique los viernes, está sugiriendo que nuestro proceso sea lo suficientemente robusto, como que si llegase a haber una emergencia y ocupemos publicar un viernes, el proceso nos da esa confianza. Quiero retocar tus palabras ahi Juan para transmitirle a la gente.
Juan (43:04)
jajaja
Yo lo que digo es que si no podés publicar los viernes todavía tenés que mejorar el proceso de QA y el proceso de automatización y todo eso. Eso es mi hot take.
Douglas (43:32)
Sí, y no, No, no, y
la verdad es que te entiendo y lo comparto, ¿no? O sea, jamás me planifico publicarlos viernes, pero estoy de acuerdo con vos. Nuestro proceso debería de darnos esa confianza cuando sea necesario, ¿no? Igual, recordemos que QA es reducir errores en producción, no eliminarlos. Es imposible eliminar los errores, ¿verdad? Es reducir los errores.
Juan (43:47)
Sí.
Sí.
Douglas (44:00)
y por eso QA se enfoca en la parte más crítica. Y con esto de la automatización, Juan, yo quiero aclarar aquí de que a pesar de que es automatizado lo más que se pueda, QA, el puesto como tal, no va a desaparecer porque la persona de QA entiende el negocio y crea los escenarios, solamente escribir y crear los escenarios es en base al negocio, de nuevo es en base a qué funcionalidad
son importantes para los stakeholders, para los usuarios, qué funcionalidades tiene que estar arriba sí o sí y cómo probar esas funcionalidades. Igual, conoce el negocio, De que el test de QA puede ser de que en Latinoamérica muestra una información, pero en Europa muestra otra. Y eso tal vez yo como developer no lo sabía, pero él como conoce el negocio, crea los diferentes escenarios, las diferentes pruebas.
Juan (44:51)
Sí.
Douglas (44:58)
para asegurarse que eso sea testiado antes de lanzarse. aunque vamos a automatizar, yo quiero aclararle aquí a los developers de que no es que el puesto de QA como tal va a desaparecer. Y de hecho, los QA hoy en día también codifican porque automatizan sus pruebas. De nuevo, todavía hay algunas que toca hacer las manuales, pero automatizan sus pruebas. Y hablando de esto, Juan.
Los QA escriben esas pruebas generales, esas pruebas globales basadas en el negocio de toda la aplicación porque el developer se enfoca en un feature y no se está fijando de que lo que está haciendo pudiera impactar otra cosa y tiene mucha razón, mucho sentido porque es un feature, es un bug fix, verdad, es algo puntual, específico y el QA ve todo, pero también a los que somos programadores.
a los que son programadores, yo no lo soy, o a los que somos de operaciones que también trabajamos con código o configuraciones, porque las configuraciones de las aplicaciones, manifestos de Kubernetes, infrastructure as code de Terraform o configuration management de Ansible, todo eso está en repositorios. Los que manejamos esas cosas, cuando hacemos funcionalidades nos toca escribir los test scenarios de ese feature que estamos implementando.
Juan (46:02)
Sí.
Douglas (46:20)
si el programador recién aplicó un fix para el login porque fallaba algo, él le toca escribir cómo probar que lo que está haciendo funciona para que el QA lo pueda testear, ¿verdad? Entonces nosotros mismos como personas técnicas...
en algún momento nos toca también escribir esos test scenarios. Entonces recordemos, los ingenieros QA escriben y se encargan de los test generales de la aplicación, pero nosotros como ingenieros nos toca escribir. Normalmente se ponen en el pull request o se ponen en el ticket, dependiendo cómo definieron el flujo, pero escribirlos y dárselos detalladamente y lo suficientemente claros para que ellos lo puedan ejecutar.
porque el QA al final lo tiene que hacer alguien más fuera de quien hizo el feature. Si yo hago el QA como yo sé cómo lo pensé, sesgado y lo pruebo. Necesito que haga QA a alguien que no tiene idea cómo es la aplicación para ver si cierto que el botón donde lo puse es intuitivo o no, ¿verdad?
Entonces, Juan, me gusta, no sé qué pensar pues, pero mí me gusta aclarar a los programadores sobre todo de que si nos toca escribir QA para los features que estamos implementando.
Juan (47:42)
si hay que definir cuál es el acceptance criteria, es el criterio de aceptación aún así creo que a veces los QA tienen como decías, como tienen un alcance un poco más grande o están pensando en teoría en más cosas que uno como developer a veces se le pasa por alto porque si tenemos que también estar pendientes de que nuestro código no
Douglas (47:47)
Mm-hmm.
Juan (48:10)
crea un problema extra, sí, es necesario poder indicarle porque al final del día a veces los QA nos parece que están solo testiendo nuestro código pero están testiendo todo y están en muchas otras cosas QA no es solamente ir y llenar un formulario y darle click, no, es más complejo que eso entonces es necesario estarles indicando, ok mis cambios deberían hacer esto y esto es lo que se espera
entonces ya con eso ellos pueden trabajar y empezar a hacer todo lo que lo que hacen
Douglas (48:47)
Sí, sí, y recordemos
que el punto de lo que estamos hablando es cómo colaborar efectivamente, sea, estamos buscando reducir la fricción, en algún momento va a ser necesario, en algún momento nos toca defender nuestro punto, pero lo que queremos es agilizar, aprendamos a trabajar efectivamente, aprendamos a colaborar de cerca con las personas, los ingenieros de QA, yo creo que no perdamos eso de vista.
Ahora, Juan, continuando con el tercer tip de qué implementar para colaborar en un proyecto de desarrollo, en un proyecto de IT, yo sugeriría la implementación de un CI-CD pipeline. Para quienes no sepan, CI-CD son iniciales de Continuous Integration.
Continuous Delivery. En español es integración continua, o sea, la integración continua de tu código. Todo este flujo que hemos estado hablando, que se ha ido definiendo, el workflow de los branches, cuando mergear, el pull request, los diferentes tests, ya sea automatizados, bueno.
No, ya sea, en un CI-City Pipeline solo los que son automatizados se pueden incluir, ¿verdad? Los tests, ya sea unit tests, smoke tests, regression tests, que para los que no saben, aunque no queremos entrar a lo técnico, un unit test es que prueba algo específico, una unidad, un smoke o un regression test, prueban funcionalidades un poco más abiertas, el smoke test prueba un poco más abierto, el regression test prueba toda la aplicación.
para resumirlo, ¿no? Entonces, pero el Continuous Integration en CI-CD hace esta parte de la integración. Corre los tests automatizados. Si todo está bien, va a hacer ya sea el merge que tiene que hacer o tiene que hacer el crear los tags o lo que sea que va a hacer con el repositorio. Y la parte del Continuous Delivery es la publicación continua.
o la entrega continua que sería ya de manera automatizada hacer el build de la aplicación, el build del paquete, que es cualquiera que sea nuestro producto y asegurarse de publicarlo. Ese es el delivery en CICD.
De nuevo, si es un npm package, si es un plugin, tema, va a ser un tag, va a crear un release en GitHub o en GitLab y lo va publicar en diferentes lugares. Si es una aplicación, la va publicar a tu hosting server, la va a mandar a tu VM o la va a mandar a Kubernetes o DockerSwarm y va a ser la publicación. Pero el tener este proceso automatizado, esa es la parte toral y central.
que hace que este flujo fluya porque no depende de que alguien manualmente vaya a estos pasos y se le vaya a olvidar alguno todo lo que es manual está sujeto a un error humano los seres humanos nos equivocamos siempre es nuestra naturaleza no lo queremos buscamos mejorar cada día pero nos equivocamos siempre entonces
Juan (52:00)
Esto
es la marca.
Douglas (52:02)
Exacto.
Entonces, eso es lo que conecta, es la parte total que hace que este flujo se dé y es donde se vuelve tan importante el primer tip que dimos que es definir el Git Workflow porque basado en eso va a empezar a generar tus tests porque puede que quiera correr los tests solo para feature branches, ¿verdad?
puede que quiera correr estos test automatizados solo en pull request porque toman mucho tiempo y para qué lo voy a correr en un solo...submití el feature branch para qué voy a correr todos los test, verdad recordemos que es poder computacional y ese test se paga, pues alguien paga por eso que corra ese test de alguna manera ya sea con serverless o con servidores entonces tenemos que ser efectivos al hacerlo pero...
Pero de manera automatizada va a generarte, va a habilitar la aplicación. Si algo falla, va a reportar errores de manera efectiva que alguien lo vea. ¿Verdad? No es que solo voy a cometear y empiece a correr el pipeline y me voy. Y si sí lo hago, el pipeline tiene que ser asegurarse de alertar a las personas necesarias dependiendo en qué paso ocurrió. Entonces, es tan importante, Juan, y yo creo que...
no es el consejo más importante porque si se fijan los que nos ven y escuchan a medida avanzamos se van uniendo, se van encajando uno con otro los consejos, ¿verdad? pero este sí es el motor que mueve de manera automatizada todo entonces me gustaría escuchar qué opinas al respecto
Juan (53:49)
Bueno, que opino es que tenés razón. Si, definitivamente el CICD es buen punto. Tal vez no es que sea lo más importante, pero es importante. sea, todas las partes que van encajando en este flujo de lo que es el ciclo de vida de la aplicación, todas estas partes son importantes. Desde cómo nos comunicamos, desde los estrategios
El CI-CD es de los que tiene mayor peso. Tomando lo que mencionaba, el ejemplo de una publicación o un despliegue en un viernes. ¿Qué es lo que te va a dar la seguridad de hacerlo? Pues tener un CI-CD bien estructurado. Que corra todos los tests que sean necesarios.
tiene un problema después de la publicación si la aplicación tiene un problema después de haberse publicado muchas empresas también tienen procesos que revierten los cambios y es automático muy difícil es muy difícil hacer un
un pipeline, un proceso que te incluya todas estas cosas y que nos proteja a este nivel. Definitivamente es muy difícil, por eso existen los puestos de trabajo específicamente para esto. Por eso es que hay personas que se especializan en esto. Pero si tu empresa lo tiene, si tu grupo de trabajo lo tiene, definitivamente nuestro sistema se vuelve mucho más robusto, más resistente.
porque no te dan nada más seguridad el hecho de hacer un pull request y ver que todos los test están en verde
y ahora si, yo como si estoy revisando un, estoy haciendo code review veo que los test pasaron pues ya ni siquiera ya no me preocupo por la sintaxis tanto, me preocupo por si inicializaron una variable que no debían ya como que me quita ese preocupación que igual lo revisamos pero ya el sistema como tal el sistema automatizado ya me está
indicando de que a nivel sintáctico la aplicación al menos corre.
Aquí de nuevo, como decía, es difícil, entonces la mayor dificultad es ¿qué test vamos a incluir? ¿Cómo lo vamos a hacer? ¿Hasta qué punto vamos a testear toda la aplicación? ¿Cuándo testiamos y cuándo no? Y a veces hay tests que pueden ser un falso positivo. A veces hay tests que el mismo test está malo. A mí me pasaba que tenía unas pruebas unitarias
Douglas (56:50)
Mm-hmm.
Juan (56:55)
que funcionaban pero en cierta hora no funcionaban específicamente en una hora no funcionaban claro el test involucraba eso involucraba procesamiento de fechas con las diferentes zonas horarias entonces cuando el servidor tenía una hora en específico fallaba entonces ahí me tocaba volver a revisar mi test volver a revisar qué está pasando así que es muy difícil ⁓
decir es que llegar a un nivel tan resiliente toma tiempo y requiere mucha dedicación de todo el no no sé yo lograr de otra forma
Douglas (57:38)
Sí, me gusta esa idea final donde decís que requiere todo el equipo porque hay una persona o un grupo encargado del CI-CD Pipeline como tal, normalmente es la gente de operaciones, es el Sysadmin o el SRE, pero mantenerlo es trabajo de todos.
cuando cambia el proceso, el build process, hay que ejecutar un nuevo comando en el build o hay que hay un nuevo tema, un nuevo plugin y dentro de ese director hay que correr un npm install, lo que sea, el programador puede perfectamente ir al build script y hacer la actualización. Y aquí es donde viene de la mano con todo, en el code review.
incluir de que se actualizó los build process de acuerdo a los cambios que hizo si llega a ser necesario. Ya sea el mismo programador o las personas de QA pueden hacer cambios a los tests automatizados dentro del pipeline para asegurarse que se mantengan actualizados. sea, no tiene que ser necesariamente, una vez que esté implementado el pipeline,
la gente de operaciones, la gente de sistemas, haciendo los cambios, mantenerlo actualizado, esta área de todos. Y puede que sí, ¿no? Puede que vos estés ocupado, puede que tengas bastante trabajo y que pongas un ticket con el de operaciones o en las maneras en que trabajas le haces saber, ayúdame cambiando el build process en el pipeline. Estos son los nuevos comandos. Hice y lo...
Juan (58:58)
estaría todos.
Douglas (59:16)
es parte de la colaboración. Pero lo que yo quiero agregar aquí, a lo que vos ya dijiste, es esa parte donde mantener un CICD pipeline óptimo, al final es trabajo de todos. Todos pueden ir a hacer cambios o como mínimo asegurarse de reportarle a la persona o equipo necesario para que los cambios se hagan sí o sí.
con el feature que estoy lanzando. Cada feature que lanzo, cada nueva publicación no puede ir live, no debería de ir live si no incluye cambios en documentación, si no incluye cambios en, si de ser necesario, cambios en los tests, cambios en el build y...
Todo eso va de la mano con el workflow, con lo que comentamos en el Pull request y todo lo que hemos hablado. Y por eso de nuevo el tema es cómo colaborar de forma efectiva al final.
todos en el equipo tenemos el mismo objetivo final y es lanzar un producto, lanzar una aplicación, lanzar un sitio web y que se mantenga corriendo arriba. No podemos lavarnos las manos o no deberíamos empezar a lavarnos las manos y esa parte, Juan, la comparto con vos.
Juan (1:00:24)
Mm-hmm.
Sí.
es que creo que tiene que ver mucho con lo que hablábamos si no me equivoco fue en el primer episodio que es la cultura DevOps recuerdo que era el primero o el y si creo que era segundo y es esto no? es tener esta mentalidad de no buscar
Douglas (1:00:46)
segundo creo
Juan (1:00:56)
culpables y cómo colaborar en el equipo, tener esta mentalidad que va un poquito más allá. No se vale el hecho de decir pues yo hice mi código y si no funciona pues que lo revise alguien más, eso no tiene que ser así.
Douglas (1:01:13)
Sí, sí, sí,
no, muy de acuerdo, muy de acuerdo Juan. Y bueno, continuando y ya para finalizar, porque aquí hay muchas cosas en realidad, entre más grande es un equipo, entre más compleja es la aplicación, realmente que hay muchas más cosas que implementar para trabajar efectivamente y colaborar efectivamente, y no las podemos mencionar todas porque no todos los escenarios son necesarios.
o tampoco nos va a llevar un episodio de tres horas aquí discutiendo cosas que no vamos a mencionar como correr test locales, por ejemplo, antes de siquiera pushear el código al repositorio, debería de correr localmente ciertos test para asegurarme de que funciona como quiero, levantar tu ambiente de desarrollo y hay...
Otras cosas más, la comunicación efectiva, ya sea por medio presencial en reuniones o por medio de mensajería, Slack Teams, lo que sea. Menciono algunos detalles ahí solo para que se sepa que esto es mucho más grande y más profundo de lo que parece y la complejidad aumenta con la complejidad de la aplicación. Pero el último tip que vamos a dar aquí, Juan.
Juan (1:02:09)
Sí.
Douglas (1:02:27)
para colaborar efectivamente y quiero recordar los tres anteriores que hemos dado, es definir la estrategia de control de versiones, la estrategia del repositorio o el Git Workflow. El segundo es definir los escenarios de QA, tener un buen QA y definir esos diferentes escenarios, esas diferentes pruebas. Y el tercero que acabamos de dar es la implementación de un CI-CD Pipeline para automatizar todo este proceso.
Juan (1:02:40)
Sí.
Douglas (1:02:55)
Y el cuarto que queremos dar hoy, cuarto y último para este episodio es la implementación de un tickering system o de una tickering system sería como la manera más básica o más simple, pero la idea es cómo manejar o administrar el proyecto y las diferentes tareas, diferentes features cuando alguien reporta que hay un error, un problema, un bug fix, se tiene que escribir de una manera...
donde no se olvide y tiene que haber un proceso, una implementación donde se le va a asignar a alguien y donde va a haber un seguimiento. Y estas cosas no se pueden olvidar. No nos puede ocurrir de que alguien reportó un error y meses después se vuelve a dar y es que, se me olvidó, es cierto, fulanito me dijo que le daba ese error. En ese tipo de cosas no puede pasar.
Aparte de que hay puestos específicos para esto, normalmente project managers o account managers dependiendo cómo funciona la empresa y su estructura, ¿verdad? Pero para manejarlo se tiene que implementar...
Un tickering system, hay herramientas especializadas como Jira, Teamwork, Linear, Trello, algunas son más simples, otras son más complejas, dependiendo que se quiere, o puede ser la misma parte de proyectos o issues que están dentro de tu repositorio, ya sea GitHub, ya sea GitLab o el que uses. Normalmente tienen secciones donde puedes crear un issue, reportar un bug o pedir una nueva funcionalidad o proyectos donde se le asigna a personas.
Juan (1:04:12)
Sí.
Douglas (1:04:33)
Y de nuevo, es algo de colaboración y si bien es cierto como en las anteriores, hay una persona encargada de definirlo. El Git Workflow normalmente lo va a definir el arquitecto de software, ¿verdad? O el senior engineer en el proyecto. Sin embargo, todos, una vez que esté implementado, todos deberíamos de colaborar. Los escenarios de QA, están los ingenieros de QA que los crean.
Juan (1:04:55)
Sí.
Douglas (1:05:00)
Pero todos deberíamos de colaborar y cada cosa nueva que yo hago debería de ir implementando con el CI-CD Pipeline. Lo mismo la gente de operaciones, el Sysadmin o los de sistemas lo crean, pero todos colaboramos. Lo mismo con la implementación del tickering system. El manejo de esto normalmente es responsabilidad del project manager o los account manager, pero todos debemos de colaborar. Si yo miro, si yo mismo recibo un feature mínimo tengo que ir al project manager y decirle que se ocupa ese nuevo feature
bug fix para asegurarme de que lo va agregar en un ticket y con la metodología que se va manejar o yo mismo irlo a crear pero una vez que esté implementado todos somos responsables yo no puedo lavarme las manos y decir porque lo mencioné una reunión ya está tenemos esta herramienta a disposición que son los ticket in system para manejar el proyecto
y asegurarnos de que todo va a estar documentado por escrito y que va a haber una manera de asignárselo a alguien, que va a haber una forma de calendarizar cuándo empezar a trabajar en ello y cuándo se estima que va a estar listo y la manera eficiente es por medio de un tickering system.
Aunque mucha gente a veces los odia, sobre todo, lo siento, la gente de los programadores o la gente de operaciones, los SRE, realmente, realmente es necesario si se quiere tener este orden. ¿Cuál ha sido tu experiencia ahí, Juan? ¿O qué pensas al respecto?
Juan (1:06:13)
Mm-hmm.
⁓ Sí.
Sí.
También estoy en el team que los odia, la verdad es que... Nada, no es broma. Con el tiempo empecé a anotar cuál es la ventaja de estos sistemas. Sí es cierto que cuando estamos en una empresa más grande sí es un poco incómodo al inicio. Y más cuando venimos tal vez de un lado, eso fue mi experiencia, venía de un lado donde los tickets eran un poco más simples.
tenemos
un sistema de tickets que no tenía tanta subdivisión como lo que es Jira Jira es un producto que es muy grande es masivo pero pero bueno ya cuando llegamos aquí y nos empezamos a acostumbrar creo que con el tiempo empezamos a ver cuál es la ventaja porque vaya yo también he utilizado otros como los más pequeños no Trello y
no recuerdo el nombre pero estos sistemas de tickets que son más simples están pesados para proyectos específicos, proyectos que tienen menos personas a veces son para nosotros mismos incluso he utilizado un sistema Planner, si no me equivoco se llama, que es de Linux y lo utilizas en Linux y esta en mi Computadora pero no es lo mismo porque Jira y estos que son más grandes
pensados para colaborar con el resto del equipo y no sólo colaborar bueno colaborar implica que el project manager pueda definir bien cuáles son las tareas y como decías no planificar el calendarizar cuando se van a trabajar en ellas es es muy importante cuando perdón es muy beneficioso cuando tenemos ya las tareas bien definidas y podemos
ya una vez que definidas pues simplemente empezamos a trabajar en ellas y listo donde estoy actualmente tenemos la ventaja que cualquiera puede crear un ticket entonces sé que hay lugares donde no están así van seteando los diferentes permisos verdad me gusta mucho donde estoy en ese aspecto porque cualquiera puede crear un ticket así que si alguien encuentra un bug
⁓
o alguien, si, más que todo con un bug pues lo puede crear y lo reporta. A veces me escriben, me dicen, hey, fíjate que encontré tal cosa y no funciona como debería en este caso en específico, Entonces simplemente les digo, ok, apóyame creando el ticket para que no se me olvide porque si no está escrito se nos va a olvidar y más cuando sos como yo que tengo muy mala memoria, entonces es mejor con un ticket
donde ya podemos ir y definir ⁓ cuál es el esfuerzo requerido hay algunos que utilizan un sistema de puntos otros por las horas pero podemos indicarle a las personas los managers esta tarea implica este trabajo implica estos cambios y se relaciona con estas otras tareas de estos otros proyectos
es pareciera tan simple, es un ticket que me indica que hacer pero por detrás nos está ayudando a colaborar de una forma mucho más grande con, ni siquiera solo con nuestro equipo más cerca pero si estamos en empresas grandes es con el resto de toda la empresa, nos ayuda a ver esto y es cierto, es un poco tedioso a veces estar logueando las horas definidas
Douglas (1:10:19)
Sí.
Juan (1:10:29)
los puntos, subdividiendo las tareas en más subtasks, sí claro es un poco tedioso pero cuando seguimos estos pasos y lo vamos siguiendo como se debe esto nos va ayudar a ⁓
a realmente comunicarnos con el resto. Una anécdota rápida, en cierto momento me vi envuelto en ciertas tareas del proyecto en el que estaba, donde empecé a programar y a hacer diferentes features sin escribir nada en ningún ticket. Por equis motivo empecé a agregar más funcionalidades, a corregir bugs y obviamente estaba trabajando.
estaba haciendo muchas cosas pero luego me preguntaron que estas haciendo porque ante los ojos de los demás no estaba haciendo nada entonces también nos sirve a nosotros los desarrolladores y bueno para todos indicar cómo estamos utilizando nuestro tiempo de nuevo es una herramienta que nos ayuda a colaborar nos ayuda a comunicar todo y es yo diría que hoy en día es indispensable
cualquier equipo mediano o grande y si bien es cierto es tedioso y a veces hay procesos que se pueden ir mejorando la verdad es que es necesario hoy por hoy es necesario en cualquier empresa que sea mediana o no digamos grande
Douglas (1:12:08)
Sí,
que Juan, nosotros las personas técnicas en sistemas, ya sea desarrolladores o las personas de operaciones...
Cualquier cosa que no sea técnica nos parece que no es necesaria. Esa es la realidad. Cualquier cosa que no sea técnica nos parece una pérdida de tiempo, pero no es cierto. Me gusta lo que estás diciendo porque no es cierto y cuando le vemos el beneficio, logramos colaborar. Suele haber mucha... una percepción errónea entre nosotros, los personas técnicos, es creer que los project managers tienen que saber lo técnico.
Juan (1:12:21)
Sí.
Douglas (1:12:44)
No es así. Creemos que el project manager debería de saber programar. Si programara fuera programador, no fuera project manager. ¿Verdad? Yo creo que desde ahí podemos partir en que nuestra idea esté equivocada. Y nos confundimos. Y a veces vale la mano con que empresas implementan mal la parte de... Aquí lo marcamos como ticketing system. Y antes de que alguien nos quiera criticar de que los tickets son una cosa.
Juan (1:12:53)
Sí.
Douglas (1:13:13)
Lo estamos agrupando como, dependiendo que tan pequeño o que tan grande, es tanto el software o herramienta como metodología a utilizar para organizar tu proyecto y las diferentes tareas y darle seguimiento a nuevas funcionalidades o a bug fixes, ¿verdad? Eso estamos resumiendo por Ticker Insystem. Pero sí, tenemos la percepción errónea de que el project manager tiene que saber estas cosas.
Juan (1:13:35)
Sí.
Douglas (1:13:42)
Y no es así, al final se trata de colaboración, de ser efectivo, de ser rápido con la colaboración. Aún en estos escenarios, Juan, porque es muy cierto, hay muchos lugares donde no todos pueden crear tickets, eso no me quita a mí la responsabilidad. Si yo descubro o sé de algo que se tiene que agregar...
me acerco al project manager o a las personas encargadas de crear los tickets. Se lo puedo mandar por correo, se lo puedo mandar por escrito, se lo puedo ir a decir verbalmente, pero asegurarme de que la persona lo cree. O sea, no me quita a la responsabilidad de que este software y metodología para manejar todo lo que ya hablamos es necesario y me vuelve responsable de mantenerlo fluido y óptimo. Entonces...
Juan (1:14:04)
correcto
Douglas (1:14:31)
No nos cerremos a esa idea, no critiquemos a los project managers. Yo sé que ahí está el chiste y los memes, verdad, de que la única habilidad para ser project manager es aprender a decir cómo vas, verdad. Entonces, no.
Juan (1:14:46)
jajaja
Douglas (1:14:50)
entendamos esa parte, por favor. Y entre más colaboramos nosotros, más efectivo es. Saquémosle provecho a los project managers. Yo siempre hice eso Saquémosle provecho a los project managers. Dígamosles realmente cuáles son nuestros impedimentos. Y pedámosles ayuda para que los vayan a conseguir. Dígamosle, hey, necesito acceso a este repositorio. Por favor, contactate con el cliente para que me de acceso. O contactate con el equipo indicado.
Y cuando les pregunten cómo vas, regresemosle la pregunta pero no con intención de discutir o de crear conflicto, sino de colaborar y regresemosle, hey, estoy pendiente con el acceso, ¿me ayudaste a conseguirlo? ¿Verdad? O necesito presupuesto para tal herramienta y probar de manera más efectiva. realmente también démosle trabajo nosotros al project manager.
Juan (1:15:14)
Sí.
Douglas (1:15:38)
para que sea fluido a la colaboración. Entonces es sumamente importante, este es un punto bien crítico, estas herramientas y estas metodologías nos sirven para mantenernos ocupados, mantenernos trabajando, darle prioridad a las cosas importantes y que todos tengamos visibilidad de qué se está haciendo y no nos ocurra lo que te ocurrió Juan, de que creían que estabas haciendo nada cuando en realidad habías trabajado mucho.
Juan (1:16:05)
Tranquilo,
Douglas (1:16:08)
bueno en realidad ese es un error y yo creo que es importante.
Juan (1:16:11)
Sí, es que
obviamente hay múltiples canales de comunicación en nuestro equipo porque en este ejemplo que te daba, obviamente mi equipo de mis compañeros de trabajo, de los programadores mejor dicho, sí veían lo que yo estaba haciendo porque ellos tienen acceso a los Git Logs y pueden ver quién está haciendo Pull Request y quién está haciendo Merge.
pero los project managers y las demás personas no tienen acceso a eso. Entonces, necesitamos entender eso, necesitamos utilizar esta vía de comunicación. Obviamente existe Slack, pero si necesitamos dejar algo, una pregunta específica para un ticket, utilizar la plataforma que estemos implementando, obviamente la más grande es Jira.
lo que nos están escuchando utilizan Jira. Entonces utilizar el sistema de comentarios donde podemos etiquetar a otras personas. ¿Por qué? Porque más adelante cuando pase el tiempo y por X motivo necesitamos regresar y buscar la información sobre X tarea, vamos a poder ver las conversaciones que surgieron, el por qué se tomaron las decisiones. De nuevo, es una herramienta muy poderosa que aunque parezca
es catedriosa hay que sacarle el jugo, así como le sacas el jugo a los project managers. Creo que es muy importante.
Douglas (1:17:43)
Exacto.
No puedo estar más de acuerdo con vos Juan y para ir cerrando este episodio solamente quiero como palabras finales, recalcar que estos cuatro tips que dimos no son los únicos, sin embargo consideramos nosotros en base a nuestra experiencia que son críticos y que si están en una empresa donde no hay nada definido
o son responsables de comenzar a definir mínimo hay que incluir estos cuatro puntos de manera estratégica y de manera efectiva. Y también quiero recordarles a las personas que están en una empresa que ya tiene esto definido, que tengamos la actitud correcta para seguirlos, para ser colaborativos y hagamos sugerencias de manera constructiva.
importante de manera constructiva en las áreas que creemos que pueden mejorar y si algo de lo que aquí hablamos alguien considera que le sería de beneficio implementarlo con su equipo en la empresa en que trabajan pues hagan la sugerencia pero al final del día mantengamos esa mentalidad constructiva. Juan, ¿con qué te gustaría cerrar este tema?
Juan (1:19:08)
Sí, me gustaría cerrar con el hecho, algo muy similar a lo tuyo, estas diferentes estrategias de cómo colaborar con nuestro equipo están ahí para mejorar el producto, para mejorar nuestra comunicación y mejorar el cómo nosotros podemos comunicar y transmitir, ya sea nuestro trabajo, nuestras incomodidades.
⁓ algo que nos está bloqueando. Entonces si bien alguna de estas tal vez no te gusta hacer code review, tal vez no te gusta escribir unit test, no te gustan los tickets, pero son necesarios. Es importante cambiar un poco nuestra mentalidad. Me gustaba mucho lo que dijiste de respetar lo que ya está implementado y acoplarnos. Hay que entender si está
⁓ ahí es por algo.
A veces creemos que está mal implementado, puede que sí, puede que no, pero en sí las estrategias que están aquí, las diferentes estrategias de Git, las diferentes estrategias que hay para manejo de tareas existen por algo. Entonces lo mejor, antes de quejarnos tanto, es tratar de acoplarnos y seguirlas, porque esto lo único que va a hacer es mejorar nuestro ambiente y también vamos a mejorar como profesores
hay que tener una mente más abierta, es algo que mencionamos muy seguido y tratar de afrontar estas cosas con una actitud más positiva.
Douglas (1:20:55)
Muy de acuerdo Juan, muy de acuerdo. Bueno, muchas gracias Juan, gracias por tu valiosa opinión y por tus consejos y esperamos que las personas que nos ven y nos escuchan...
hayan podido recibir ese valor, hayan podido irse con ideas que puedan implementar o que puedan sugerir. Les agradecemos mucho por el tiempo, les agradecemos mucho por dejarnos compartirles nuestras experiencias. Nos veremos hasta la próxima. Bye.
Juan (1:21:29)
Bye.