Número 24
7 de setembro de 2022
|
No mundo da programación, a cousa máis pedestre que podes facer é unha aplicación CRUD. Ese nome, que vén das iniciais de “Create, Remove, Update, Delete”, refírese ás catro operacións que se poden realizar nos rexistros dunha base de datos: crealos, borralos, modificalos e borralos.
Moitísimas aplicacións son CRUD. Unha aplicación de xestión de clientes é un exemplo moi claro de aplicación CRUD, pero tamén o é un blog, unha axenda de contactos, o catálogo dunha tenda online e, incluso, o mesmo Facebook.
A estas alturas, un podería pensar que a programación de aplicacións CRUD xa tiña que estar totalmente solucionada e non debería gardar segredos para ninguén, non? Estamos tan afeitos a ver aplicacións CRUD, que a estas alturas xa nin pensamos en que poida haber nada complicado nelas. Son catro funcións, que dificultade pode haber? Tanto desprezo lle ten tanta xente ás aplicacións CRUD, que ninguén nos aprende a facelas correctamente e, polo tanto, todos cometemos os mesmos erros.
Mentres subía as escaleiras, pensou: “Eu son un enxeñeiro informático do ano 2022! Operar esta máquina de vapor tan primitiva non debería darme ningún problema…”
O erro do que vos vou falar hoxe é non evitar as modificacións simultáneas nun rexistro.
Rosa e Pepe son os propietarios dunha librería e, por fin, recibiron novos exemplares do libro “As mellores Follas” do afamado autor Jacobo Tarrío, que non duran nin cinco minutos nos andeis. Por un fallo de coordinación, os dous corren a actualizar a súa páxina web: mentres Rosa marca a caixa de “dispoñible para a venda”, Pepe modifica a descrición para celebrar que XA CHEGOU A NOVENA EDICIÓN, e os dous premen o botón de “actualizar” ao mesmo tempo.
Nesta historia totalmente verídica, Rosa e Pepe experimentan o que chamamos unha “carreira de datos” ou, en inglés, “data race”. Os dous cambios están a competir contra o outro, e o que chega segundo desfai o que fixo o primeiro cambio. Por exemplo, o cambio de Rosa chega primeiro, que marca a caixa de “dispoñible”; porén, no cambio de Pepe, esa caixa está sen marcar, e así queda gravado o cambio. Despois dese contratempo, os clientes non poden mercar o libro e Pepe e Rosa fican sorprendidos cando, despois de pasar dúas horas, aínda non venderon ningún libro.
Para evitar este problema é necesario detectar os cambios simultáneos no mesmo rexistro. Unha boa maneira de facelo é como o fai a Wikipedia. Nela, cada artigo ten unha “data de última modificación” que se actualiza cada vez que alguén o modifica. Cando alguén preme o botón de “actualizar”, Wikipedia comproba se a versión actual do artigo é a mesma que o usuario estivo a editar e, se non, amosa unha mensaxe de erro. Cun deseño similar, Rosa e Pepe poderían ter evitado o seu problema e non terían sufrido economicamente por mor dunha aplicación CRUD mal deseñada.
Levamos décadas facendo aplicacións CRUD, pero moitas das que se fan hoxe en día sofren este problema porque a maioría dos programadores nunca repararon en que tamén é necesario aprender a facelas correctamente. A próxima vez que teñades un proxecto “simple”, non vos confiedes.
A ilustración desta Folla procede de “Appletons’ cyclopædia of applied mechanics”.
Anterior: “Malos de manter” | Índice | Seguinte: “Conxuncións nas funcións” |
Coding Sheet has an English version of this article: “Deceptive simplicity”. |
1 comentario