Llevo unas semanas de prácticas y lo primero que he aprendido es que el salto entre clase y empresa no está donde te imaginas. No es que te pidan tecnologías más difíciles: es que en clase entregas proyectos que empiezas tú y nadie más va a tocar, y en una empresa entras a un proyecto a medio construir, escrito por otros, con reglas que ya existían antes de que tú llegaras.
Este post no es una lista de consejos motivacionales. Es lo que me he encontrado de verdad y lo que me habría gustado que alguien me contara antes de empezar la FCT.
La primera semana casi no programas
Esto descoloca. Llegas con ganas de escribir código y te pasas los primeros días levantando el entorno y leyendo el proyecto: clonar el repositorio, configurar la base de datos, hacer que arranque en tu máquina y entender cómo está organizado todo.
Y es tiempo bien invertido. Un proyecto real tiene una estructura que en clase no llegas a ver, sencillamente porque tus prácticas son demasiado pequeñas para necesitarla. Antes de tocar nada tienes que saber dónde vive cada cosa.
Consejo concreto: si el proyecto usa migraciones de base de datos (Flyway, Liquibase o similar), dedícale un rato a entenderlas antes que nada. Es la diferencia entre que la base de datos se te levante sola y pasarte una mañana sin saber por qué te falta una tabla.
Cómo es una tarea real por dentro
Mi primera tarea de verdad fue montar el backend para dar de alta albaranes. Dicho así suena a ejercicio de clase: un formulario que guarda datos. En la práctica significó tocar toda la cadena:
- DTOs para definir qué datos entran y salen, que no son los mismos que tienen las entidades por dentro.
- Mappers para convertir entre esos DTOs y las entidades, sin que la capa web se entere de cómo es la base de datos.
- Repository para el acceso a datos.
- Service con la lógica de negocio y las validaciones de verdad.
- Endpoints exponiendo la funcionalidad, con sus códigos de respuesta.
En clase, cuando haces un CRUD, es normal que el controlador hable directamente con la entidad y ya está. Funciona y apruebas. En un proyecto que va a mantener otra gente durante años, esa separación por capas es lo que hace que puedas cambiar la base de datos sin reescribir la API.
La segunda parte de la tarea fue lo que más me enseñó: después del alta por formulario, había que permitir cargar albaranes masivamente desde un Excel. Y la clave era reutilizar exactamente el mismo proceso de validación y guardado, no escribir un camino paralelo. Ahí es donde entiendes de golpe por qué la lógica va en el service y no en el controlador: si la hubiera metido en el endpoint del formulario, habría tenido que duplicarla entera.
El Git de empresa no se parece al de clase
Esto es lo que más me ha costado y en lo que más floja va la formación. En clase la mayoría trabajamos con main y poco más. Aquí el flujo es:
- Sacas una rama nueva a partir de
develop, nunca demain. - Trabajas ahí y vas subiendo commits.
- Abres un pull request que tienen que aprobar dos revisores antes de entrar.
- Te dejan comentarios, corriges, y vuelven a revisar.
Y un detalle que no había vivido nunca: cuando tu rama está esperando revisión y necesitas seguir avanzando en algo que depende de ella, sacas la siguiente rama a partir de la tuya, no de develop. Encadenas trabajo sobre código que todavía no está aprobado. Eso en clase no pasa jamás.
Si vas a empezar prácticas pronto, dedica un fin de semana a practicar ramas, conflictos y rebase en un repo de prueba. No llegues a aprenderlo con el código de la empresa delante.
Revisar el código de otros enseña más que escribir el tuyo
No me esperaba esto. Además de que me revisen a mí, yo reviso los pull requests de mis compañeros. Al principio intimida bastante: ¿quién soy yo, el de prácticas, para comentar el código de alguien con más experiencia?
Pero leer cómo resuelve otra persona un problema parecido al tuyo es la forma más rápida de aprender los criterios del equipo: cómo nombran las cosas, hasta dónde llega cada capa, qué se valida y dónde. En un par de semanas de revisar PRs coges más contexto que leyendo la documentación del proyecto entero.
Y sobre recibir comentarios en tu propio código: al principio escuece, sobre todo cuando te marcan diez cosas en algo que tú dabas por terminado. No es personal. Es literalmente el mecanismo por el que el proyecto no se degrada.
Tocar backend y frontend es lo mejor que te puede pasar
Después del backend me tocó implementar la pantalla correspondiente: el formulario, el service que llama a la API y el store que guarda el estado. Es decir, consumir desde el frontend justamente los endpoints que yo mismo había escrito.
Eso cambia cómo diseñas una API. Cuando eres tú quien la consume después, te das cuenta enseguida de que ciertas decisiones que parecían cómodas desde atrás son incomodísimas desde delante: respuestas con datos de menos que te obligan a hacer una segunda llamada, errores que no dicen qué campo ha fallado, formatos de fecha distintos en dos sitios.
Si en tus prácticas te dan a elegir, pide tocar las dos partes aunque una se te dé peor. Es lo que más te va a hacer crecer.
Lo que no te cuentan de un proyecto en construcción
En clase trabajas con datos que te has inventado tú y que siempre son coherentes. En un proyecto que todavía se está construyendo, la base de datos puede estar llena de datos de prueba a medias: registros incompletos, relaciones que aún no existen, cosas que alguien metió para probar otra cosa hace un mes.
Eso significa que a veces algo te falla y no es tu código: son los datos. Aprender a distinguir «esto está mal programado» de «esto está mal en la base de datos» es una habilidad en sí misma, y se tarda un rato en cogerle el punto.
Cómo preguntar sin quemar a nadie
El consejo clásico es «pregunta sin miedo», y es verdad a medias. Nadie espera que sepas el proyecto, pero interrumpir a alguien cada quince minutos sí desgasta. Lo que a mí me funciona es fijarme un límite: si llevo más de media hora atascado en lo mismo sin avanzar nada, pregunto.
Y al preguntar, contar qué he probado ya. No es por quedar bien: es que la mitad de las veces, mientras ordenas lo que has intentado para explicarlo, te das cuenta tú solo de por dónde va el fallo.
Lo que me llevo hasta ahora
Que el ciclo te enseña a programar, pero no a trabajar en un equipo que programa. La arquitectura por capas, el flujo de ramas y revisiones, leer código ajeno y diseñar pensando en quien va a consumir lo que haces: eso solo se aprende dentro.
Si estás a punto de empezar tus FCT, lleva repasado Git de verdad y ve con la idea de que las primeras semanas vas a leer más de lo que vas a escribir. Es normal, y es justo lo que toca.
Si te interesa el lado de sistemas, tengo también una guía para montar un servidor Linux casero donde puedes practicar despliegue antes de que te toque hacerlo en serio.
