Kiedy Twój schemat bazy danych nie nadąża za rzeczywistością

Bądźmy szczerzy: większość programistów przeszła przez koszmar sytuacji, gdy schemat bazy danych nie jest w stanie pomieścić nowych wymagań. Okazuje się, że paleodonkolodzy przeżywają dokładnie ten sam koszmar — i to od ponad stu lat.

Najnowsze badania z Monash University wskazują na problem, przy którym każdy architekt oprogramowania poczuje ciarki na plecach: system nazewnictwa i klasyfikacji naszych przodków został zaprojektowany z myślą o świecie zdecydowanie mniejszej liczby danych. Dzisiaj napływają nowe odkrycia skamieniałości, a stary drzewko taksonomiczne ugina się pod ich ciężarem.

Problem klasyfikacji, o którym nikt nie mówi

Oto sedno sprawy: gdy myślimy o ewolucji człowieka, większość z nas wyobraża sobie czytelny, liniowy postęp. Homo habilis przechodzi w Homo erectus, a ten w Homo sapiens. Proste. Czyste. I błędne.

Rzeczywistość jest znacznie bardziej chaotyczna — to rozległa sieć spokrewnionych gatunków, wiele z nich nakłada się w czasie i przestrzeni, niektóre się krzyżowały, inne po prostu wymierały. Brzmi znajomo? Zamień „gatunki" na „mikrousługi", a „przestrzeń" na „regiony chmurowe" — i właśnie opisałeś system rozproszony.

Konwencje nazewnictwa odziedziczone po paleontologach z początku XX zakładały, że ewolucja podąża czystymi ścieżkami rozgałęzień. Ale każde nowe odkrycie — każdy nowy punkt danych — pokazuje, że nasi przodkowie nieustannie się rozgałęziali, zbiegali, a czasem cofaли. To mniej przypomina drzewo binarne, a bardziej grafową bazę danych.

Co programiści mogą zapożyczyć od starożytnej taksonomii

Tutaj robi się ciekawie dla naszej branży. Wyzwania stojące przed taksonomistami ewolucyjnymi odzwierciedlają problemy, z którymi mierzymy się przy budowie współczesnych systemów:

Koszmary z wersjonowaniem: Tak samo jak „Homo erectus" oznacza różne rzeczy w zależności od tego, którego eksperta zapytasz, Twój endpoint REST /v1/users może oznaczać co innego dla różnych zespołów za pół roku.

Dryf schematu: Gdy nowe skamieniałości podważają istniejące klasyfikacje, naukowcy muszą retrospektywnie decydować, czy poszerzać definicje, tworzyć podkategorie, czy uznać, że oryginalne kategorie były zasadniczo błędne. Brzmi jak Twój stary kod legacy?

Problem „jest-a": Czy Homo naledi to bezpośredni przodek współczesnych ludzi, boczna gałąź, czy coś zupełnie innego? Odpowiedź może brzmieć „wszystko naraz". Dokładnie tego problemu doświadczamy, próbując modelować złożone relacje w hierarchiach obiektowych.

Budowanie systemów, które akceptują niejednoznaczność

Badania z Monash sugerują, że naukowcy zajmujący się ewolucją potrzebują nowych ram — takich, które uznają niepewność zamiast wciskać dane w sztywne kategorie. To zaskakująco przypomina to, czego nauczyliśmy się w architekturze oprogramowania o budowie elastycznych, adaptacyjnych systemów.

Pomyśl: zamiast sztywnych drzew taksonomicznych — co, jeśli używalibyśmy przedziałów ufności i rozkładów prawdopodobieństwa? Co, jeśli „Homo erectus" nie byłby klasyfikacją binarną, ale zbiorem rozmytym z różnymi stopniami przynależności?

To właśnie odkrył świat technologii, przechodząc od sztywnych metodologii Waterfall do Agile, od monolityów do mikrousług, od synchronicznych do sterowanych zdarzeniami architektur. Nie próbujemy już wtłoczyć rzeczywistości w nasze kategorie — budujemy systemy, które mogą pomieścić chaos rzeczywistości.

Konkluzja

Oto niewygodna prawda, z którą mierzą się zarówno biologia ewolucyjna, jak i tworzenie oprogramowania: nasze kategorie to ludzkie konstrukty i zawsze są tymczasowe. Zapis kopalny nie przejmuje się naszymi konwencjami nazewnictwa, a użytkownicy nie przejmują się naszym schematem bazy danych.

Naukowcy domagający się zaktualizowanych systemów klasyfikacji nie są pedantami — rozumieją, że nasze ramy kształtują to, co widzimy i jakie pytania możemy zadawać. Lepsza taksonomia to nie tylko kwestia dokładności; to kwestia umożliwiania nowych odkryć.

Dla programistów lekcja jest podobna. Za każdym razem, gdy ustalasz model danych, obstawiasz, że obecne rozumienie się utrzyma. Czasem tak. Czasem kończysz z problemem Homo erectus.

Może najlepsze systemy — zarówno taksonomie ewolucyjne, jak i architektury oprogramowania — to te zaprojektowane z myślą o graceful evolution. Bo jedyną stałą w obu dziedzinach jest zmiana.

Skamieniałości wciąż napływają. Kod wciąż się wydaje. A taksonomie wciąż potrzebują aktualizacji.

Jakie wyzwania związane z architekturą systemów aktualnie rozwiązujesz w swoich projektach? Czasem najciekawsze rozwiązania przychodzą z obserwacji, jak inne dziedziny radzą sobie z podobnymi problemami.