Curso empresarial de Node.js en HexSchool
Algunas reflexiones y pensamientos después de completar el curso empresarial de Node.js en HexSchool (un bootcamp de programación en Taiwán).
¿Por qué elegí este curso? ¿Qué problema resuelve?
Es un curso bastante caro, y considerando la naturaleza de HexSchool (por razones comerciales, no pueden rechazar a nadie que se inscriba), el contenido del curso inevitablemente se diseña en un nivel más básico.
Viendo estas condiciones, inscribirse no parece la mejor inversión. Pero en la práctica, hay algunos aspectos que vale la pena considerar:
Trabajo en equipo
Desde el inicio del curso hay que trabajar en equipos. Dado que la mayoría de los inscritos vienen del frontend y casi nadie tiene experiencia real en backend, es una buena oportunidad para practicar la comunicación y coordinación en el desarrollo backend.
Visto desde otro ángulo, los compañeros con los que colaboras pueden convertirse en contactos profesionales para el futuro, una forma de construir tu red de conexiones.
Costo hundido
Como mencioné, es un curso caro. Incluso si eres tan perezoso como yo, si no quieres perder esa inversión, te ves obligado a dedicar tiempo después del trabajo para seguir el ritmo del proyecto y cumplir con los deadlines. Esto garantiza que no pierdas tu dinero y, de paso, te ayuda a ser más disciplinado.
Nuevas perspectivas
Todo el proyecto se desarrolla de principio a fin: desde la concepción del diseño hasta el desarrollo completo. Aunque objetivamente el contenido es bastante básico, permite que todos los miembros experimenten el flujo completo de PM, UI/UX, frontend y backend, lo cual aporta nuevas perspectivas para el trabajo futuro.
Contenido del curso
En cuanto al contenido, aparte de las operaciones básicas de MongoDB y la implementación de API con Node.js, lo más valioso en mi opinión son las integraciones con servicios de terceros, como login con terceros y pasarelas de pago. Esta parte es bastante mecánica y requiere tiempo para leer la documentación del proveedor, así que tener un instructor que te guíe ahorra mucho tiempo.
Además, parte del diseño del curso todavía usa MVC como ejemplo, por lo que el equipo necesita hacer la separación frontend-backend por su cuenta durante el proyecto, lo cual también requiere reflexión.
Algunas secciones del curso fueron impartidas por instructores externos en formato de livestream, lo que puede generar cierta discrepancia. Por ejemplo, el contenido sobre testing unitario estaba orientado al frontend, así que si querías practicar testing unitario en backend, tenías que resolverlo por tu cuenta como equipo.
Desarrollo del proyecto (opinión muy subjetiva)
El proyecto práctico es, en mi opinión, la parte más valiosa de este curso. Y lo más importante de todo es la colaboración y planificación interna del equipo.
Sé honesto antes de formar grupos
Antes de armar los equipos, hay una autoevaluación de habilidades. Si hay áreas que no dominas, sé honesto. Si la diferencia de nivel dentro del equipo es demasiado grande, surgen conflictos serios que pueden paralizar el proyecto.
Deja tiempo de margen en el desarrollo
Como la mayoría viene del frontend al mundo del backend, hay muchos detalles que antes no te tocaban y que van a ralentizar el desarrollo. Por ejemplo, después de integrar la pasarela de pago, inevitablemente hay que manejar órdenes, y las órdenes implican cuestiones de timestamps de transacciones.
Para un desarrollador frontend, estas cosas no eran algo que tuvieras que considerar antes. Al fin y al cabo, tu trabajo era consumir APIs y mostrar listas. Pero en el backend, todo esto hay que tenerlo en cuenta.
El objetivo es lanzar el proyecto
Por favor considera seriamente estos puntos:
- Los miembros del equipo tienen trabajos de tiempo completo y solo pueden dedicar tiempo limitado (no puedes predecir si tendrán urgencias o horas extra en sus trabajos)
- Los deadlines son muy ajustados, el tiempo real de desarrollo es limitado
- La mayoría no tiene experiencia en backend, así que inevitablemente van a perder tiempo resolviendo problemas inesperados
Así que el objetivo de la primera fase debe ser crear un producto funcional, no uno perfecto. No te pongas a pensar en arquitectura, optimización o testing en esta etapa, eso viene después.
Si buscas la perfección, además de atascarte en el desarrollo, lo peor es que puedes provocar una ruptura en el equipo (conflictos potenciales de todo tipo, especialmente cuando no sabes si tus compañeros están bajo presión laboral). Una vez que el equipo se fractura, el proyecto tiene un 94.87% de probabilidades de fracasar. Hacer primero algo feo pero funcional puede motivar enormemente la confianza del equipo.
Es especialmente importante evitar la expansión infinita de tecnologías. En el frontend, no debería pasar que se usen React y Vue al mismo tiempo. Aunque alguien del equipo domine un framework, eso no significa que los demás puedan aprenderlo rápido y usarlo para desarrollar.
Expansión y optimización
Cuando el proyecto completa la funcionalidad del primer rol, normalmente se puede considerar que la primera fase ha terminado. Además de poder respirar un poco, ya puedes empezar a pensar en otras funcionalidades, incluyendo tecnologías que quieras probar u optimizaciones de experiencia de usuario.
En nuestro caso, fuimos incorporando gradualmente websocket para mensajería en tiempo real, PWA, animaciones, un sistema de check-in, y así enriquecimos bastante el contenido del sitio.
Conclusión
Para terminar, aquí dejo las URLs de deploy y los repos de nuestro proyecto (frontend y backend admin). Siéntanse libres de echar un vistazo.
Frontend (Client)
Backend (Admin)
<!-- test account & password -->
account : admin
password : 12345678
Enlaces relacionados
Sobre cómo me convertí en coach del curso empresarial de Node.js 2023