El problema de la concurrencia

Los desarrolladores de software llevan desde los años 70 editando los mismos archivos al mismo tiempo. Dos personas modifican la misma función. Una las publica primero. La otra se encuentra con un conflicto de fusión. Este problema se resolvió de tal manera que todos los desarrolladores actuales utilizan la solución sin siquiera darse cuenta: el control de versiones. Prepara tus cambios. Confírmalos cuando estén listos. Si otra persona ha modificado lo mismo, el sistema lo señala y tú resuelves el conflicto antes de que nada se publique.

Los datos de campo presentan el mismo problema. Dos equipos editan elementos en la misma zona. Uno está bajo tierra, sin conexión. El otro se encuentra al otro lado de la ciudad, con una señal móvil irregular. Ambos vuelven a conectarse y envían sus cambios. Si el sistema no detecta la superposición, el trabajo de un equipo sobrescribe silenciosamente el del otro. Si el sistema bloquea los registros para evitar conflictos, nadie puede trabajar sin conexión. Estas son las mismas disyuntivas a las que se enfrentaban los equipos de software antes del control de versiones, y la mayor parte del software de campo sigue estancado ahí.

Cómo lo gestionan la mayoría de los programas de gestión de campo

Hay tres enfoques habituales, y cada uno tiene su coste.

La última escritura prevalece. Es la opción más sencilla y peligrosa. Ambos usuarios editan. Ambos envían los cambios. El segundo envío sobrescribe el primero sin previo aviso. El trabajo del primer usuario se pierde. Este enfoque es inquietantemente habitual en el software de campo diseñado inicialmente para un solo usuario y al que posteriormente se le ha añadido la compatibilidad con múltiples usuarios. Funciona hasta que deja de hacerlo, y cuando falla, el fallo pasa desapercibido.

Bloqueo de registros. El sistema bloquea un elemento cuando alguien lo abre para editarlo. Nadie más puede editarlo hasta que se libere el bloqueo. Esto evita conflictos al impedir la concurrencia, lo que a su vez impide por completo el trabajo sin conexión. Si un trabajador de campo bloquea un elemento y luego entra en un túnel del metro durante cuatro horas, ese elemento queda bloqueado para todo el equipo. El bloqueo de registros sacrifica la integridad de los datos a cambio de una parálisis operativa.

Evitar conflictos mediante la delimitación de territorios. Asigna a cada equipo una zona geográfica y confía en que se mantendrán dentro de ella. Esto funciona si las zonas nunca se solapan, los límites se respetan siempre y ningún elemento se extiende más allá de un límite. En la práctica, las zonas se solapan en cada intersección, límite y corredor de infraestructura compartida. El enfoque funciona en teoría, pero falla en los límites —que es precisamente donde se desarrolla la mayor parte del trabajo interesante.

El modelo de control de versiones

Nuestro enfoque se inspira directamente en la forma de trabajar de los equipos de desarrollo de software. Los conceptos se corresponden uno a uno.

La edición es local. Cuando un trabajador de campo edita un elemento —mueve un punto, modifica la forma de una línea, actualiza propiedades—, el cambio se guarda en su navegador. No es visible para nadie más. Esto equivale a editar un archivo en tu rama local. El trabajador puede deshacer, rehacer y seguir editando sin afectar al conjunto de datos compartido. Una insignia de cambios sin confirmar indica cuántas ediciones están pendientes, del mismo modo que un desarrollador realiza un seguimiento de los cambios no incorporados.

Enviar es confirmar. Cuando el trabajador está listo, hace clic en «Enviar». Todos los cambios pendientes se envían al servidor como una única versión: un conjunto coherente de cambios con una marca de tiempo y la identidad de quien los envía. Esto es una confirmación. Es atómica: o se aplican todos los cambios o ninguno.

La revisión del administrador es una revisión del código. Para los trabajadores de campo que no son administradores, al hacer clic en «Enviar» no se publica directamente. Se crea una versión marcada para su revisión. Un administrador abre la cola de revisión, consulta las diferencias —qué ha cambiado, dónde y cómo se compara con el estado actual— y la aprueba o la rechaza. Esto es una solicitud de incorporación de cambios. El conjunto de datos compartido no cambia hasta que alguien con autoridad lo autorice.

La detección de conflictos consiste en la comprobación de fusiones. Cuando se envía una versión, el servidor comprueba si alguien más ha editado los mismos elementos o la misma zona geográfica desde la última sincronización del usuario que ha enviado los cambios. Si hay solapamientos, se señala el conflicto. Ambas versiones son visibles —los cambios del usuario que ha enviado los cambios aparecen en azul y los del otro usuario en naranja— y el equipo resuelve el conflicto de forma explícita. No hay sobrescrituras silenciosas. No hay pérdida de datos.

El historial de versiones es el registro de confirmaciones. Se conserva cada versión confirmada: quién la envió, cuándo, qué se modificó y quién la aprobó. Las versiones se comprimen con el paso del tiempo, pero nunca se eliminan. Puedes reconstruir el estado de cualquier función en cualquier momento de su historial. El registro de versiones es el registro de auditoría, el mecanismo de deshacer y la memoria institucional, todo en uno.

Cómo se aplica esto en la práctica

Hay dos equipos trabajando en la misma red de fibra óptica. El equipo A se encuentra sobre el terreno modificando el trazado de los cables en la sección norte. El equipo B está trabajando bajo tierra modificando los puntos de empalme en la sección central. Ambos equipos están desconectados.

El equipo A termina y vuelve a conectarse. Envían su versión. El servidor la acepta —sin conflictos, ya que nadie más ha modificado esas funciones desde la última sincronización del equipo A—. El administrador revisa las diferencias, confirma que los cambios en el trazado del cableado son adecuados y los aprueba. Los cambios se implementan.

El equipo B aparece una hora más tarde y envía su trabajo. El servidor detecta que dos de sus modificaciones en los puntos de empalme se solapan con elementos que el equipo A ya había modificado. Aparece una advertencia de conflicto. El equipo B abre la vista de conflictos y ve ambas versiones: sus modificaciones en azul y el estado confirmado del equipo A en naranja. Ajustan sus puntos de empalme para tener en cuenta los cambios en el trazado de los cables realizados por el equipo A, vuelven a enviar el trabajo y el administrador aprueba la versión resuelta.

Datos perdidos en total: cero. Tiempo total dedicado a la conciliación manual: unos minutos. Funciones sobrescritas sin previo aviso: cero.

Compárese esto con las alternativas. Con el método «la última escritura prevalece», la propuesta del equipo B habría sobrescrito silenciosamente los cambios en el trazado del cable realizados por el equipo A. Con el bloqueo de registros, uno de los equipos no habría podido editar mientras el otro trabajaba bajo tierra. Con la evitación basada en territorios, el tramo solapado habría sido una pesadilla de coordinación que habría tenido que gestionarse mediante llamadas telefónicas y hojas de cálculo.

«Offline primero», no «Offline tolerado»

Un error común es pensar que el soporte sin conexión implica una degradación gradual del servicio cuando se interrumpe la red. Esa visión da por sentado que estar conectado es lo normal y que estar desconectado es una excepción que hay que gestionar. En las operaciones sobre el terreno, ocurre justo lo contrario. La conectividad es intermitente por defecto: sótanos, túneles, zonas rurales, obras de construcción sin cobertura. Un sistema que considere la desconexión como una excepción pasará la mayor parte del tiempo en modo de excepción.

El control de versiones invierte este proceso. El estado predeterminado es trabajar sin conexión. Cada modificación es local hasta que decidas enviarla. La red solo es necesaria para dos cosas: enviar tus cambios al servidor y descargar las últimas modificaciones de los demás. Entre esos dos momentos, trabajas de forma independiente con plena capacidad de edición. Cuando se restablece la conexión, se realiza la sincronización, y el sistema se encarga del resto.

Por eso funciona este modelo. No se diseñó para gestionar el modo sin conexión como un caso especial. Se diseñó partiendo de la premisa de que los usuarios suelen estar sin conexión y se conectan de vez en cuando, que es exactamente como funciona el trabajo de campo.

Resumen

La gestión de datos sobre el terreno adolece del mismo problema de concurrencia que el desarrollo de software resolvió hace décadas: varias personas editan lo mismo, a menudo sin conexión, con el riesgo de que se produzcan sobrescrituras silenciosas.
El principio de «la última escritura prevalece» provoca pérdidas silenciosas de datos. El bloqueo de registros impide trabajar sin conexión. La prevención basada en territorios falla en cada límite y solapamiento.
El modelo de control de versiones —borradores locales, confirmaciones atómicas, revisión administrativa, detección de conflictos, historial permanente— se traslada directamente del desarrollo de software a las operaciones de campo.
Las ediciones de campo se almacenan localmente hasta que el trabajador las envía. Los envíos de usuarios no administradores pasan por una cola de revisión. Los conflictos se detectan en el servidor y se muestran para su resolución explícita: sin sobrescrituras silenciosas, sin pérdida de datos.
Cada versión confirmada se conserva con el nombre del remitente, la marca de tiempo y el nombre del aprobador. El historial de versiones se comprime, pero nunca se elimina. El estado de cualquier elemento se puede reconstruir en cualquier momento.
El modo sin conexión es el estado de trabajo predeterminado, no una excepción que deba gestionarse. El sistema asume que los usuarios suelen estar desconectados y se sincronizan ocasionalmente, lo que se ajusta a cómo funciona realmente el trabajo de campo.