Lazpe EditorialProceso de desarrollo y estudio de caso
Motivo
Lazpe Editorial es una simulación de una prueba técnica de una empresa real, fue hecha con el objetivo de practicar mis habilidades de testing. Midudev creó esta iniciativa para que desarrolladores web pudieran ensayar las pruebas técnicas que se hacen en los procesos de contratación.
Aproveché que estaba aprendiendo testing, y con la prueba técnica podía pulir mis habilidades y encontrar áreas de mejora, así que decidí participar en el proceso.
Objetivos
- Mostrar una lista de libros en la UI
- Poder guardar los libros en una lista de lectura
- Tener una opción para filtrar por género y cantidad de páginas
- Lista extra para guardar libros ya leídos
- Administrar libros con Drag And Drop
- Tener tener sincronización entre pestañas en tiempo real
- Sincronización de estado (estado global)
- Persistencia de datos
- Permitir al usuario generar sus propias listas.
- Testing
Enlaces
Requisitos, limitaciones y obstáculos
- Cualquier framework o biblioteca podía utilizarse
- Límite de 7 días para la entrega
- Código reutilizable y tolerante a cambios de framework en el futuro
- Componentes limpios y separados de la lógica
Herramientas Usadas
Decisiones
Algunas de las decisiones de desarrollo más importantes, tienen que ver con el diseño de la página y las herramientas que se acoplaban mejor a sus necesidades.
Qué quería lograr
La aplicación no necesitaba rutas dinámicas, tampoco hacía tantas peticiones para atraer contenido, solamente una para los libros. Por lo tanto, si usaba Next.js no estaría utilizando todo su potencial y estaría incrementando el tamaño del paquete de la aplicación de forma innecesaria, por esa razón usé React puro con las herramientas de Vite.
En cuanto al estado global, por las acciones que tenía que hacer con los libros (agregar a la lista, eliminar, mover) y los lugares en los que tenían que reflejarse los cambios (las listas, notificación, en el botón, en la portada), haber utilizado el hook de React useContext, habría generado demasiados renderizados ineficientes en la aplicación, haciéndola más lenta. Zustand, un administrador de estado global ligero y muy fácil de utilizar, fue la mejor opción. Además, también ofrece una forma de sincronizarse con localStorage con dos líneas de código extra, así que ya estaba solucionando dos problemas con una sola decisión.
La razón del diseño
Cuando Midudev publica los requisitos de la prueba técnica, ofrece un ejemplo de una posible estructura de la aplicación, para que pudiéramos ver cuál era la idea principal y a qué nos teníamos que apegar.
Aunque no está nada mal y cumple el objetivo perfectamente, sabía que el diseño y la estética podía jugar un rol fundamental para darle más puntos a mi prueba técnica (cabe recalcar que no iba a haber algún tipo de calificación o competencia, solamente quería hacerla lo mejor posible).
Representar objetos digitales de la forma en la que estos existen en la vida real, hace que la experiencia sea más intuitiva, no todos tenemos intuición tecnológica, pero todos nos relacionamos con el mundo y sus dimensiones, así que me gusto la idea de mostrarlos en un solo grid y que estuvieran encimados, da la impresión de que estaban en un estante real.
Testing
Aunque la razón principal por la que quise participar en la iniciativa era mejorar mis habilidades en las pruebas del código, tanto de pruebas unitarias como de E2E y pruebas de integración, curiosamente cuando entregué la prueba técnica solamente había hecho un test, si es que así podía considerarse porque no estaba haciendo ninguna aserción, solamente me aseguraba que un componente se renderizara.
Sin darme cuenta, había pasado más tiempo diseñando la aplicación y desarrollándola, incluso me pasé del límite de tiempo, y cuando la entregué, no tenía tests decentes.
Ahora los tiene, porque los agregué después, pero no debí desenfocarme de ese objetivo principal.
La calidad del código
Una de las cosas que más me enorgullece de este proyecto, es la calidad del código. Desde que empecé el proyecto, no quería cometer los errores que había tenido en proyectos pasados.
Estas son algunas de las cosas a destacar en cuanto a las buenas prácticas y la calidad del código:
- Organización de archivos agrupados en carpetas según su responsabilidad
- Uso de custom hooks para separar la lógica de los componentes y hacer esa lógica reutilizable
- Prevenir futuros cambios en la API
- Código legible y de baja complejidad
- Empleo de estructuras de datos para tener centralizado el contenido
- Componetización para encapsular funcionalidades, escalar la aplicación fácilmente, fomentar la reutilización y los tests
- Uso de formateador de código y de convenciones del lenguaje.
Opinión de la comunidad
Este ha sido uno de mis proyectos favoritos, y una de las razones es que a la comunidad les gustó mucho, hubo personas que amablemente comentaron la Pull Request con palabras increíbles y otras le dieron una estrella en github.
Incluso tuve la suerte de que Midudev revisara el proyecto en directo, puedes echarle un vistazo y ver cuál fue su opinión, y ya estando aquí, quiero darle las gracias por impulsar la comunidad de programación en español y ayudar a qué todos subamos de nivel, gracias Midudev. 💛
Reacción a Lazpe Editorial - Minuto 1:00