¿Cómo funciona el Guild de Frontend?

Antes, permíteme darte un breve resumen de lo que somos y hacemos:

Crehana es una plataforma educativa que ayuda a las personas a adquirir nuevas habilidades relacionadas a las industrias digitales. Tenemos categorías como marketing digital, Negocios, Ilustración y Dibujo, video, diseño, fotografía, animación 3d, web y muchas más.

Cuando menciono que Crehana es una plataforma educativa hago referencia a que no solo contamos con cursos, sino con toda una serie de herramientas que ayudan al estudiante a alcanzar sus metas. 

Además de los cursos, contamos con:

Metodología de aprendizaje propia: Aprendizaje basado en proyectos. Clases cortas y prácticas que se centran en la teoría, analítica y práctica. Profesores y Mentores que te acompañaran en todo el proceso.

Con el pasar del tiempo, entendimos que era necesario crear nuestra propia metodología ya que las actuales no se adaptan a lo que buscamos ¿qué buscamos? un aprendizaje rápido y práctico.

Membresías: Acceso total al catálogo con más de 500+ cursos.

Especializaciones: Un grupo de cursos seleccionados especialmente para especializarte en una habilidad específica.

Mentores y Profesores, que te acompañarán en todo el proceso de aprendizaje

Aplicaciones creadas desde cero enfocadas en mejorar la experiencia de aprendizaje: Una de ellas es nuestro VideoPlayer web, creado desde cero con el fin de agregar funcionalidades propias que ayuden al usuario a sentirse más cómodo en la reproducción de clases.

Proyectos: Tenemos una metodología de aprendizaje que se basa en aprender haciendo. Dentro del salón de clases de cada curso irás avanzando progresivamente con un proyecto final. Este proyecto será revisado por el profesor o mentor del curso el cual te brindará feedback concreto sobre como mejorarlo.

Si aún con esto no entiendes lo que hacemos, te invito a adquirir una de nuestras membresías para que experimentes por ti mismo lo que significa ser un estudiante en Crehana : )

Dicho esto, vayamos a lo que venimos: El Guild de Frontend.

*No profundizaré en cada uno de los siguientes puntos, hacerlo haría que el post sea muy largo. Si tienen alguna duda o inquietud pueden escribirme a twitter.

4 squads, 5 Guilds. 25 developers. 1 bot.

Nuestra estructura de equipo, al igual que nuestra plataforma, se ha ido interando con el pasar del tiempo con el fin de buscar la mejor manera de crear y mejorar los productos digitales que nuestros estudiantes necesitan.

Squads y Guilds son terminologías basadas en "The Spotify Squad Framework". Crehana usa una variación de este framework para que pueda adaptarse a nuestra forma de trabajo.

Squads

Equipo multidisciplinario que cuenta con mínimo 2 frontends, 2 backends, 1 product designers y 1 Product o Squad Owner. Los Squads se enfocan en partes específicas del flujo del estudiante. Además, estos son seres independientes por lo que es el mismo squad el que se encarga de llevar a cabo todos los procesos de inicio a fin: planning, design, implementation, qa, deploys, measure, etc.

Todo esto genera que este grupo de personas sean totalmente autónomos y no dependan de algún externo para poder cumplir con los retos que se proponen.

En Crehana los squads han llegado a ser piezas clave dentro del workflow. Ellos nos permiten tener la agilidad necesaria para poder iterar, mejorar y crear nuevos features y productos en poco tiempo.

Personalmente, la idea de los Squads me parece algo increíble. Esta gira en plantearles retos a las personas y confiar en que estas encontrarán, por si mismas, la mejor forma de cumplirlo.

Confianza > Control

Uno de los inconvenientes que surgen con esta estructura es la redundancia de conocimiento. Debido a la autonomía, un Squad podría haber resuelto el mismo problema que otro Squad. Como solución a esto surgen los Guilds.

Guilds

Grupo de personas con los mismos skills, por ejemplo, el guild de frontend. Los guilds existen para poder compartir conocimiento que se va acumulando en cada Squad. Alguien del squad de Revenue podría resolver el mismo problema que alguien del squad de Activation, los Guilds crean el espacio y momento propicio para compartir este conocimiento de tal forma que no se termine reinventando la rueda.

Los Guilds también se encargan de decidir el stack tecnológico que será usado en todos los Squads.

Al tiempo de escritura de este artículo, contamos con más de 8400 archivos. Aproximadamente el 98% de estos son de Javascript/typescript y resto son archivos de configuración para webpack, babel, eslint, etc.

Crehana es un monorepo, por lo que el código del frontend y backend viven juntos. Eso significa que el tooling que usamos para compilar nuestro javascript tuvo que ser creado desde cero con el fin de que este pueda adaptarse a la estructura de un proyecto creado por Django framework.

Stack tecnológico

Como mencioné al inicio, soy más del lado Frontend, por lo que si bien mencionaré también cosas de backend y devops, me enfocaré mucho más en explicar las tools que usamos en el lado del cliente.

• Frontend: Frontend: Configuraciones personalizadas de webpack, babel, eslint, Typescript, Reactjs, apollo-client, react-hook-forms, styled-components, tailwindcss, jest, cypress y demás librerías del ecosistema Frontend. Además de todo tenemos implementado Serverless SSR, usamos Nextjs para cierta parte de nuestra aplicación web y una implementación custom para las demás páginas.
• Backend: python, aiohttp, flask, fastapi, sqlalchemy, graphql, rest, celery, rabbitmq, docker, terraform, redis, elasticsearch y más.

Webpack

Tenemos múltiples configuraciones de webpack, cada una con un propósito específico como reducir tiempos de compilación, uso de memoria ram, optimizaciones de web performance, service workers, serverless ssr, dlls, polyfills, etc.

Ahora mismo, nuestra configuración de webpack tiene más de 100 entries, por lo que al tener tantos archivos por compilar (8400) nos encontramos con dos problemas:

1. Altos tiempos de espera en la compilación
2. Alto uso de memoria al levantar webpack

Para resolver estos dos problemas tuvimos que investigar a fondo sobre cómo funciona webpack con el fin de crear una solución a medida.

Usamos webpack.dll plugin para reducir tiempos de compilación. Sin embargo, los tiempos de re-compilación seguían siendo altos. El principal problema era el tener tantos entries en nuestra configuración ¿solución a esto? crear nuestro propio "webpack cli".

Este custom cli tiene los siguientes features:

• Poder elegir si usar o no el webpack.dll plugin, hay casos dónde no lo necesitamos.
• Permitirte elegir que entries quieres que webpack use. Los developers, dependiendo del Squad en el que estén, solo modifican partes específicas de la aplicación web. En la mayoría de casos no es necesario que el developer levante el proyecto con TODOS los entries.

A futuro, queremos dejar de invertir tiempo en el mantenimiento del tooling que usamos para compilar el javascript. Si bien, en este punto nos consideramos un equipo con un fuerte conocimiento en webpack, somos conscientes que al día de hoy ya existen herramientas increíbles que se encargan de todo esto (herramientas que no existía cuando empezamos esto 5 años atrás 😢). Por ello, el 2021 tendremos el reto de migrar, de forma gradual, parte de nuestro frontend a Nextjs.

Typescript, Eslint y prettier

Los linters son parte importante del día a día. No solo porque nos advierten de forma anticipada que nuestro código tiene errores de runtime, sino también porque nos permiten estandarizar el estilo de desarrollo de todo el equipo. Sobre estos, typescript y eslint, está prettier que nos ayuda con el formateo del código.

Debo decir que, cuando nosotros lo intentamos años atrás, la configuración necesaria para que estas tecnologías se integren y funcionen sin problemas fue muy complicada de lograr. Tuvimos que usar tslint + eslint y uno que otro fork de algún plugin de eslint.

En los últimos dos años el ecosistema ha ido madurando y con ello las integraciones entre estos 3 es mucho más fácil el día de hoy.

https://github.com/typescript-eslint/typescript-eslint

Testing

Usamos Jest para los tests unitarios, funcionales y de integration. Cypress para los End-To-End.

Cada Squad tiene su propia métrica de code-coverage debido a que manejan diferentes secciones de Crehana. Esta varía dependiendo de la complejidad e importancia de la sección. Por ejemplo, el Squad de Revenue, que se encarga de nuestro Checkout, tiene la meta de alcanzar un code-coverage de casi 80%, mientras que el Squad de Activation de 50%. Los porcentajes de codecoveraga por squad se definen teniendo en cuenta el costo de los bugs según la sección o Squad. Un bug en nuestros procesos de payments en Checkout cuesta mucho más que un bug visual de cualquier otra página.

Para definir el costo de un bug no solo se toma en cuenta el "dinero", sino también la mala ux que este pueda causar.

Debido a que cada Squad maneja sus propios tests, tuvimos que crear un pequeño CLI para ejecutar jest solo sobre los archivos y entries de webpack que le pertenecen a un squad en específico.

Además de los test con Jest, también tenemos tests E2E creados con Cypress. Estos corren de forma diría entre las 8:00 am y 9:00 am. Los tests E2E se usan para verificar que flujos completos se cumplen sin error alguno, por ejemplo: activación de una compra, compra de un curso, compra de una membresía, compras con diferentes pasarelas de pago, etc.

Por cierto, Mr Robot es el bot en slack que nos ayuda a estar al tanto del status de nuestros tests:

Generators y estructura de las aplicaciones Frontend

La estructura de cada aplicación (a.k.a webpack entry) está definida de la siguiente forma.

Tenemos un documento en notion en donde se describe el porqué de esta estructura. Este doc no solo describe los entries, sino también la estructura de los componentes y los utilitarios que se reutilizan y/o comparten en todo Crehana.

Para facilitar la creación de estos esqueletos de carpetas y archivos, creamos un pequeño CLI con plop que te permite elegir el generator a usar.

Framework y librerías internas

Empezamos usando MaterialUI, pero con el pasar del tiempo nos fue necesario crear nuestro propio Framework de UI "crehana-ui".

Los diseños que el Guild de Frontend recibe por parte de los UI designers son increíbles, no hay duda de ello. Sin embargo, con el pasar del tiempo notamos que personalizar material-ui para lograr la UI que queremos nos consumía mucho tiempo, y en algunos casos, generaba limitantes de maquetación. Esto forzaba a los UI Designers a modificar sus diseños para que estos se adapten a los componentes de material-ui.

Cuando la primera versión del Design System del equipo de Producto fue desplegado, vimos una oportunidad para crear nuestro propio Framework de UI: crehana-ui.

crehana-ui nos ayuda a agilizar el desarrollo de nuevos productos ya que este refleja a totalidad nuestro Design System. Alcanzar el pixel perfect ya no nos era imposible.

MaterialUI no es malo es solo que, al igual que todas las tecnologías que existen en el ecosistema javascript, este no aplica a todos los proyectos.

Web Performance

El que nuestras página core carguen y funcionen lo más rápido posible es prioridad 1 para nosotros.

Para asegurar el alto performance en Crehana, nosotros tenemos definido el Performance Budget necesario para alcanzar nuestras metas mensuales y trimestrales.

El Performance Budge define los límites para las diferentes métricas que tenemos.

Por ejemplo:

• First Contentful Paint ≤ 2.5s
• Total Blocking Time ≤ 300ms
• Page size ≤ 1.2 mb
• etc

Dependiendo del Squad, manejamos entre 10 a 12 métricas de performance. Estas incluyen las 6 web vitals.

El squad de Platform es el responsable de mantener un minímo de 50 de Lighthouse score en nuestras páginas core. Este Squad tiene personas de backend, frontend, infraestructura y devops.

Code review

No hay ni un solo día en donde no hagamos releases a production por lo que debemos asegurar que estos cambios sean lo más seguros posibles. Para lograrlo, todos los Pull Requests creados cumplen con el siguiente checklist:

• [ ] Product review: Aprobación del equipo de Producto.
• [ ] Web Performance: El PR no tiene impacto negativo en nuestras métricas de web performance.
• [ ] Documentation: Los cambios han sido documentados
• [ ] Testing: Se agregaron o modificaron tests relacionados a los cambios hechos.
• [ ] SEO: El score de SEO se mantiene o se ha incrementado.
• [ ] Linters: El PR no contiene errores de eslint y typescript.
• [ ] Readability: El PR cumple con nuestras guías y estándares de desarrollo.
• [ ] i18n: El PR tiene las traducciones necesarias para los idiomas que Crehana soporta.

Además de asegurar el cumplimiento del checklist, los code-reviewers también brindan feedback sobre cómo se puede mejorar los cambios hechos en el Pull Request.

Estándares y Guías de desarrollo

En este último año hemos empezado a documentar muchas de nuestros procesos de desarrollo. Usamos notion para ello.

Es muy importante para nosotros tener documentado la estructura y estilo de desarrollo que todos en el equipo debemos seguir. La idea es usar las reglas como una guía inicial para escribir código, pero al mismo tiempo poder romperlas cuando se crea necesario.

Flexibility over standardization

Una "regla" es agregada a nuestra guía de desarrollo cuando vemos que varios developers de los Guilds y Squads coinciden con ella en el día a día.

Falla rápido, aprende rápido

Aún con todo lo que hemos implementado al día de hoy, seguimos aprendiendo con los fallos del día a día. Es importante entender que las estrategias de iteración en productos digitales no solo se aplica a productos, sino también a la forma en como manejamos los procesos de trabajo en los equipos.

Los bugs nunca se irán por muy bueno que sea el code-review o los tests. Lo único que podemos hacer nosotros como ingenieros es crear las herramientas necesarias para reducirlos al mínimo.

Lo genial del equipo es que siempre estamos en constante discusión sobre cómo debemos mejorar lo que tenemos actualmente.

El feedback constante, directo y preciso nos permite mejorar con el pasar del tiempo y, al mismo tiempo, ir reparando los desperfectos que se presentan en el día a día.

Tenemos muchos planes ambiciosos que queremos cumplir este 2021. La agilidad que obtenemos con esta estructura de Squads, Guilds y Teams hace que tengamos que pensar no solamente en el producto, sino también en la optimización y mejora de procesos de desarrollo. Parte de mi trabajo se basa en ello, hacer que los desarrolladores se sientan lo más cómodos posibles haciendo lo que mejor saben, crear productos y soluciones digitales.

Este es un mega resumen del roadmap Frontend para el 2021:

• Developer experience: Estamos apuntando a tener muchas más guías de desarrollo, CLI's, generators y más tooling que ayude a agilizar nuestros proceso de desarrollo.
• Migración de nuestras páginas principales a Nextjs, pensamos en migrar más de 50 entries de nuestra configuración de webpack.
• Web performance: 90 puntos de score en lighthouse en nuestras páginas principales. Como mencioné arriba, optimizar aplicaciones tan grandes como Crehana es algo complicado. Sin embargo, luego de mucha investigación y varios experimentos, hemos descubierto oportunidades de mejora que trabajaremos en el Q1 y Q2 del 2021.
• Testing: Incrementar nuestro code-coverage a 60...

Y muchas, muchas cosas más...

Tenemos muchos planes para este 2021, todos de ellos enfocados en mejorar el DX y la agilidad del desarrollo ¿tienes lo que se necesita para ser parte del equipo de Frontend?