5.4Trabajo en equipo: GDS (gestor de fuentes)
Lo esencial en 30 segundos
- El GDS almacena las fuentes en un repositorio compartido: cada desarrollador extrae un elemento para modificarlo y luego lo reintegra, con un historial completo.
- El GDS es útil incluso en solitario: vuelta atrás, copia de seguridad adicional y trazabilidad de las decisiones, mucho más allá de simples copias fechadas.
- El equipo sigue reglas: reintegrar a menudo, comentar, probar, respetar convenciones y comunicar antes de cualquier modificación del análisis.
Mini-caso hilado — Yacine organiza el trabajo de su equipo con el GDS
Yacine desarrolla la aplicación de una pyme de venta de material eléctrico en Orán. Samir trabaja en el portal web y Nadia en la aplicación móvil: los tres comparten el mismo análisis y los mismos procedimientos de negocio. Yacine pone el proyecto bajo GDS y crea un repositorio común. Cada uno extrae los elementos sobre los que trabaja, los prueba y luego los reintegra con un comentario preciso. Al mediodía, Samir y Yacine han modificado el mismo procedimiento de cálculo de descuento: el GDS muestra el historial y permite fusionar sin sobrescribir el trabajo del otro. Antes de tocar el archivo Article, Yacine avisa al equipo, porque una modificación del análisis afecta a todos. También guarda una copia del repositorio, convertido en el activo más valioso del proyecto.
Caso autónomo de esta sección: reaparece en el curso, el esquema, el código y el reto 48 h de la sección 5.4.
1. El repositorio y el ciclo
El GDS (Gestor de Fuentes) está integrado en el taller WinDev. Los elementos del proyecto se almacenan en un repositorio compartido. Cada desarrollador extrae los elementos sobre los que trabaja, lo que los toma a su cargo, y luego los reintegra una vez modificados y probados. Este ciclo evita que dos personas sobrescriban mutuamente su trabajo. El GDS conserva el historial completo: quién modificó qué, cuándo y con qué comentario. Así se puede comprender una decisión antigua o volver a una versión anterior. Es muy superior a copias de carpetas llamadas «proyecto_final_OK».
2. Útil incluso en solitario
El GDS no está reservado a los equipos. Incluso solo, Yacine gana una vuelta atrás tras una maniobra errónea, una copia de seguridad distinta de su carpeta de trabajo y una trazabilidad de sus decisiones. Se atreve a experimentar una reescritura o una optimización porque sabe que puede volver atrás. Las copias fechadas, en cambio, no dicen ni quién hizo qué ni por qué, y acaban siendo imposibles de desenredar. El GDS también impone una disciplina útil: reintegrar por etapas coherentes y comentar lo que se ha hecho.
3. Las reglas de equipo
En equipo, la herramienta no basta: hacen falta reglas respetadas. Reintegrar a menudo (idealmente cada día) para no bloquear a los colegas. Comentar útilmente cada reintegración: «corrección del cálculo de descuento grandes cuentas» en lugar de «cambios». Probar antes de reintegrar para no romper el proyecto común. Definir convenciones comunes de nomenclatura y estilo. Y sobre todo comunicar antes de modificar el análisis, porque el modelo de datos es compartido y afecta a todos. Por último, guardar una copia del repositorio: ahora concentra lo esencial del proyecto.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Una reintegración comentada
Yacine corrige el descuento grandes cuentas y documenta su cambio:
// Calcul de la remise accordée à un client
// GDS : réintégration commentée — seuil grands comptes corrigé
PROCEDURE CalculeRemiseClient(nCA est un réel) : réel
SI nCA >= 500000 ALORS
RENVOYER 5
FIN
RENVOYER 0Resultado: el historial explica el porqué del umbral, no solo el diff.
Reflejo: comentar la reintegración con el negocio y el impacto, no «cambios».
Vocabulario de la sección
- GDS
- Gestor de Fuentes integrado en WinDev: repositorio compartido, extracción/reintegración e historial.
Ejemplo sencillo: Yacine pone el proyecto de gestión bajo GDS con Samir y Nadia.
Lo que no es: intercambiar carpetas por USB sin historial.
Reflejo: GDS = fuentes versionadas y compartidas.
- Repositorio
- Depósito central de los elementos del proyecto, distinto de la carpeta de trabajo de cada desarrollador.
Ejemplo sencillo: El repositorio contiene el análisis y los procedimientos comunes.
Lo que no es: trabajar cada uno sobre una copia aislada del proyecto.
Reflejo: el repositorio es el activo que hay que salvaguardar.
- Extracción / reintegración
- Ciclo de trabajo: tomar a cargo un elemento para modificarlo y luego devolverlo al repositorio.
Ejemplo sencillo: Nadia extrae el procedimiento de existencias, lo prueba y lo reintegra.
Lo que no es: mantener un elemento extraído durante semanas.
Reflejo: reintegrar a menudo para no bloquear.
- Historial
- Conservación de quién modificó qué y cuándo, con los comentarios y la posibilidad de volver atrás.
Ejemplo sencillo: Yacine recupera la versión de ayer tras una maniobra errónea.
Lo que no es: confiar en copias llamadas proyecto_final_OK.
Reflejo: el historial explica y repara.
- Rama
- Línea de desarrollo paralela que permite aislar una evolución antes de fusionarla.
Ejemplo sencillo: Yacine prepara una reescritura de las existencias en una rama dedicada.
Lo que no es: desarrollar una reescritura arriesgada directamente en la línea común.
Reflejo: una rama aísla y luego se fusiona.
En la práctica — En la práctica — Trabajar con el GDS
- Ponga el proyecto bajo GDS y cree el repositorio, aunque trabaje solo, para el historial y la vuelta atrás.
- Adopte el ciclo: extraer el elemento que hay que modificar, trabajar, probar y luego reintegrar rápidamente comentando lo que se ha hecho y por qué.
- En equipo, defina convenciones comunes (nomenclatura, estilo, organización) y comunique antes de cualquier modificación del análisis.
- Guarde una copia del propio repositorio: se ha convertido en el activo más valioso del proyecto.
Guion paso a paso — probar antes de reintegrar (10 min)
Yacine verifica los casos críticos del descuento antes de devolver el procedimiento al repositorio.
Una prueba rápida de los casos de negocio evita romper el proyecto común; después se reintegra con un comentario preciso.
Plantilla para copiar y pegar — mi comentario de reintegración
// Réintégration GDS — Yacine — 12/03
// Élément : PROCEDURE CalculeRemiseClient
// Modification : seuil grands comptes porté à 500 000 DZD
// Tests : remise 5 % à 600 000, 0 % à 100 000 → OK
// Impact analyse : aucun
// Règle : réintégrer souvent, commenter, tester, prévenirTrabajo en solitario
Yacine utiliza el GDS solo para volver atrás tras una reescritura arriesgada.
Equipo web y móvil
Samir y Nadia extraen cada uno sus elementos y reintegran sin sobrescribir al otro.
Modificación del análisis
Yacine avisa al equipo antes de cambiar el archivo Article.
Rama de prueba
Yacine aísla una nueva versión de las existencias en una rama antes de fusionarla.
✓ Buenas prácticas
- Reintegrar a menudo y liberar los elementos no utilizados.
- Comentar y probar cada reintegración.
- Comunicar antes de cualquier modificación del análisis.
✗ Errores frecuentes
- Mantener un elemento extraído durante semanas.
- Escribir «cambios» como comentario de reintegración.
- Modificar el análisis sin avisar al equipo.
Puntos clave
- El GDS almacena las fuentes en un repositorio compartido, con extracción y reintegración.
- El historial indica quién, qué, cuándo y permite volver atrás.
- El GDS es útil incluso en solitario: vuelta atrás, copia de seguridad, trazabilidad.
- En equipo: reintegrar a menudo, comentar, probar, convenciones comunes y comunicación sobre el análisis.
Reto 48 h — aplícalo mañana
Como Yacine, ponga un proyecto bajo GDS y realice un ciclo completo: extraer un procedimiento, modificarlo, probarlo y luego reintegrarlo con un comentario que explique el negocio y el impacto. Después provoque una maniobra errónea y vuelva a la versión anterior desde el historial. Guarde una copia del repositorio.
- Puedo explicar el papel del repositorio y el ciclo extraer/reintegrar.
- Sé por qué el GDS es útil incluso en solitario.
- Conozco las reglas de equipo: comentar, probar, comunicar sobre el análisis.
Preguntas frecuentes
¿Es útil el GDS cuando se desarrolla en solitario?
Sí, claramente. Incluso sin equipo, aporta el historial y la vuelta atrás tras una maniobra errónea, una copia de seguridad adicional distinta de la carpeta de trabajo y la trazabilidad de las decisiones. También permite experimentar con tranquilidad: uno se atreve con una reescritura porque sabe que puede volver atrás. Las copias de carpetas fechadas no dicen ni quién, ni qué, ni por qué, y uno se olvida de hacerlas en los momentos críticos. Para Yacine, el GDS es útil, pues, antes incluso de la llegada de Samir y Nadia.
¿Qué reglas adoptar para trabajar en equipo en un proyecto WinDev?
Reglas simples pero respetadas: reintegrar a menudo, idealmente cada día o en cada etapa coherente; extraer solo lo que se necesita; comentar útilmente cada reintegración; probar antes de devolver un elemento al repositorio; recuperar con regularidad las modificaciones de los demás. En el código, definir convenciones comunes de nomenclatura y estilo, y evitar poner el negocio en los botones. En la comunicación, avisar antes de cualquier modificación del análisis, porque afecta a todo el equipo. Por último, guardar una copia del propio repositorio.
¿Para qué sirve el GDS incluso cuando Yacine desarrolla solo?