Czy ciągłe tworzenie i usuwanie tabel jest oznaką architektonicznej wady?

Niedawno rozmawiałem z programistą, który wspomniał, że podczas tworzenia programu rutynowo regularnie tworzą i usuwają tabele i kolumny, pracując nad nowymi funkcjami i uzasadniając rzeczy, mówiąc, że jest to normalne, gdy używa się zwinnego procesu programistycznego.

Ponieważ większość mojego tła wywodzi się ze środowiska programowania kaskadowego, zastanawiam się, czy jest to właściwie uważane za właściwe w przypadku zwinnego programowania, czy też może to być oznaką podstawowego problemu, zarówno z architekturą programu, jak i z postępem zwinnego procesu.

Każdego dnia staje mi się coraz bardziej widoczne, że „zwinny” staje się synonimem źle przemyślanego, chaotycznego, pośpiesznego i siedzącego na spodniach. I żadna z tych rzeczy nie jest zgodna z podejściem zwinnym, jak rozumiem.

Posiadanie skutecznego i powtarzalnego procesu Agile nie jest łatwe i nie sądzę, że z natury zmniejsza całkowite nakłady pracy, nawet jeśli może to prowadzić do lepszych produktów.

Jeśli powiedzieli, że nie mają czasu na „refaktoryzację” bazy danych, prawdopodobnie również nie mają czasu na konfigurowanie wersji i migracji bazy danych. Prawdopodobnie nie poświęcili czasu na stworzenie pakietu testów funkcjonalnych. Wszystkie te rzeczy są tym, o czym myślę, gdy myślę o solidnym procesie Agile, który zmierza do sukcesu.

W końcu Agile to tylko słowo. To, co robisz na co dzień, określa, czy odniesiesz sukces, czy nie.

Chociaż nie jest niczym niezwykłym tworzenie i upuszczanie tabel podczas ewolucji projektu, może być konieczne pewne czyszczenie, aby upewnić się, że baza danych naprawdę używa wszystkich tych tabel.

Tak, w Agile chodzi o refaktoryzację, ale jeśli teraz mówią, że system jest zbyt duży, aby refaktoryzować, przestali robić Agile i teraz są tylko programowaniem Cowboy. Zespół programistów nie lubi nazywać się tak, ale to właśnie robią. Jazda na strzelnicy strzelająca do wszystkiego, co się rusza.

DBA pomoże, tylko upewnij się, że masz DBA, który rozumie zarówno programowanie, jak i programowanie zwinne. Twój zespół programistów musi zostać uwięziony, a nie wtrącony do więzienia.

Ogólnie rzecz biorąc, tworzenie nowych tabel i dodawanie nowych kolumn jest bardzo normalne w procesie, w którym programowanie i administrowanie bazą danych nie są ściśle oddzielone. Nowa funkcja może tworzyć nowe dane, które muszą gdzieś iść. Spróbuj zbyt surowo, aby tego uniknąć, a skończysz na modelu z wewnętrzną platformą .

Dobrze napisane oprogramowanie prawie nie zauważa tych nowych obiektów bazy danych, więc nic się nie psuje tylko z powodu nowej kolumny w tabeli.

Z drugiej strony regularne upuszczanie kolumn, a nawet tabel jest podejrzane. Nowa funkcja nigdy nie wymaga usuwania stołu, więc może to oznaczać, że ludzie pracują całkowicie bez planu.

Jeśli twoja baza danych może być łatwo wersjonowana i migrowana, a masz testy, aby udowodnić, że zmienianie rzeczy nie psuje rzeczy, prawdopodobnie masz dość sprawny proces.

W świetle komentarzy - generalnie do ich skutku, grupa kowbojów usprawiedliwiających się zwinnością - krzyczy. Szybki. I opublikuj wszystko, co możesz, na thedailywtf.com, abyśmy wszyscy mogli cieszyć się twoim przerażeniem.

Podobnie jak większość odpowiedzi tutaj na StackExchange, odpowiedź powinna brzmieć „to zależy”. W zwinnym opracowywaniu wymagania i specyfikacje są wykrywane podczas wdrażania.

Jednak przy zwinnym rozwoju, gdy model relacyjny jest odpowiednio znormalizowany, dodanie nowych atrybutów do relacji rzadko powinno być koniecznością, nowe byty powinny zasadniczo odnosić się do starszych, biorąc pod uwagę odpowiedni model.

Większość programistów nie normalizuje swoich baz danych z powodu ograniczeń czasowych, lenistwa, niekompetencji lub złożoności zapytań. Renormalizacja wymaga transferu istniejących danych, modyfikacji DAO itp. Itp., Co generuje czynnik ryzyka.

Aby odpowiedzieć na twoje pytanie, nie, to nie jest normalne w procesie Agile.

To, co może wydawać się wynikać z podejścia Agile, wynika z jego krótkiego cyklu projektowania / opracowywania / testowania, a nacisk Agile na lekkie rozwiązania, które spełniają znane wymagania, ale są dobrze skonstruowane, aby móc sprostać nowym wymaganiom dzięki minimalna zmiana. Biorąc pod uwagę te dwie rzeczy, możesz powiedzieć, że programista, nie wiedząc, co może przyjść później, ale wiedząc, że jego zmiana nie powinna wpłynąć na DB w sposób, którego nie można cofnąć, po prostu wprowadza niezbędne zmiany w schemacie w „najlżejszy” możliwy sposób, a następnie co pewien czas kilka zestawów „lekkich” zmian zostanie przekształconych w coś bardziej trwałego i stabilnego.

Powiedziawszy to, nie pracowałem jeszcze z programistą, który podpisał się pod teorią i metodologią Agile, a także pomyślałem, że rutynowe tworzenie i usuwanie tabel w schemacie jest konieczne z jakiegokolwiek powodu. Zwinne nie oznacza doskakiwania ani wkręcania. Jeśli otrzymasz historię, która wymaga dodania nowego pola danych należącego do określonego rekordu, dodajesz to pole do tabeli. Jeśli ta zmiana coś psuje, to zastanawiasz się, dlaczego i dokonujesz innych zmian, które mogą być konieczne (mogę myśleć o bardzo niewielu rzeczach, które mogłyby się zepsuć, dodając kolumnę do sprawdzanego DB; jeśli zepsuje się z tego rodzaju zmianą, ty mają większe problemy). Refaktoryzacja jest zwykle ograniczona do kodu; zmiana schematu jest zwykle bardziej zaangażowanym procesem niż zmiana kodu, więc kiedy zmiany schematu muszą nastąpić, zwykle są wykonywane z większą ostrożnością, i przynajmniej trochę uwagi poświęconej znajomości przyszłego kierunku projektu. Konieczność przebudowy części lub całości bazy danych wskazuje na fundamentalny błąd projektu; bycie zwinnym nie oznacza, że ​​nie ma „ogólnego planu” podstawowych zasad architektury i projektowania, których należy przestrzegać, jednocześnie budując program i strukturę danych.

Teraz w Agile są przypadki, w których to, co „wiesz” teraz, będzie sprzeczne z tym, czego nauczysz się później. Załóżmy, że masz wymóg, aby twój system miał adres dla każdej osoby. Ponieważ jest to relacja 1: 1, a dane będą potrzebne w większości przypadków, wystarczy dodać pola Adres do tabeli Osoby. Tydzień później otrzymasz wymaganie, aby Osoba mogła mieć więcej niż jeden adres. Teraz jest to relacja 1: N i aby odpowiednio go modelować, musisz cofnąć poprzednie zmiany, dzieląc pola na nową tablicę adresów. To nie jest rutyna, szczególnie wśród starszych programistów. Doświadczony programista zobaczy, że osoba ma adres, uzna je za odrębne koncepcyjnie i utworzy tabelę osób i tablicę adresów, łącząc osobę z adresem z referencją FK do adresu ID. Schemat taki jak ten jest łatwiejszy do zmiany w przypadku zmiany charakteru relacji; bez tworzenia lub usuwania całych „szerokich” tabel danych relację między osobą a adresem można dość łatwo zmodyfikować z 1: 1 na 1: N na N: N.

Podczas pracy pod Agile nie skupia się tak bardzo na projektowaniu, więc nie uważam tego za ogromny problem, z pewnością w przypadku pierwszego wydania.

Trudno jest komentować system, który ma 700 tabel, których nie widziałem, może potrzebować wszystkich, ale może się zdarzyć, że baza danych nie będzie wystarczająco dobrze zarządzana.

Nawet w przypadku zwinności w przypadku dużego systemu dość często zdarza się, że ktoś / zespół jest odpowiedzialny za schemat.

Jeśli często wprowadzają takie zmiany - szczególnie upuszczając tabele i kolumny w aplikacjach na żywo - wydaje się to oznaką braku doświadczenia. Nie ma to nic wspólnego z jakimkolwiek procesem, który, jak twierdzą, postępuje. „Zwinne” nie jest usprawiedliwieniem, aby nie usiąść i nie pomyśleć o danych, które musisz przechowywać, i ich relacjach, zanim zaczniesz wymyślać kod. Jeśli stwierdzą, że zmieniają więcej niż 10-20% początkowej struktury, to dla mnie wskaźnik oznacza, że ​​albo nie zastanawiają się nad tym, albo nie mają dużego doświadczenia w analizie wymagań i projektowaniu baz danych, więc po prostu stają się zbyt na początku wiele z tego źle.

Choć brzmi to tak, jakby Twój zespół był po prostu kodowaniem kowbojskim, tak naprawdę nie powinno być nic złego w refaktoryzacji kodu LUB baz danych. To nie strata pracy - dostosowuje się do nowo poznanej rzeczywistości.

Sugerowałbym, że zespół potrzebuje piaskownicy do wypróbowania zmian, przeprowadzenia testów, odesłania ich do użytkowników i zdecydowania, czy mają sens. W tym momencie integracja zmian, które mają sens - z odpowiednimi testami regresji - w twoim schemacie powinna być w porządku.

Zwinność polega na kodowaniu, bazy danych nie są kodem. Zmiana bazy danych powinna być traktowana jak przebudowa domu. Ludzie jakoś uwierzyli, że zwinne środki działają teraz, planują później, co jest całkowicie nieprawdziwe. Nawet przy zwinnych metodach należy poświęcić czas na planowanie, szczególnie na coś tak ważnego jak projektowanie baz danych.

Moja ostatnia praca była w takim zespole. Podczas korzystania ze zwinnego procesu zmieniają się wymagania. Czasami zmiany oznaczają, że istniejący byt potrzebuje nowego atrybutu, co powoduje powstanie nowej kolumny w istniejącej tabeli lub wymagany jest zupełnie nowy byt, co powoduje powstanie nowej tabeli z relacjami do istniejących tabel. Tego rodzaju zmiany pochodzą z terytorium i nie można ich zignorować tylko dlatego, że nie chcesz dotykać schematu. Sukces zależy od utrzymania integralności danych podczas migracji z jednej wersji bazy danych do następnej i odpowiedniego testowania jednostkowego.

Staraj się nie wprowadzać niepotrzebnych zmian w schemacie. Na przykład, jeśli funkcja wymaga utworzenia nowej tabeli, upewnij się, że jesteś zadowolony z definicji tej tabeli, zanim ją zarejestrujesz i uruchomisz w środowisku testowym. Konieczność cofnięcia zmiany w schemacie bazy danych po migracji danych może być bolesna.