[S.....7]

W wczorajszym wpisie opisałem wam jak wyglądała moja praca bez systemu kontroli wersji w pewnym januszexie. Tym razem, podzielę się z wami opisem bazy danych i sposobem komunikacji z nią w projekcie nad którym pracowaliśmy.

Cały projekt składał się w zasadzie z trzech części, panelu administracyjnego dostępnego przez przeglądarkę, aplikacji mobilnej będącej jednocześnie aplikacją konsumencką i uproszczonym panelem administracyjnym oraz quasi-restowego api zajmującego się komunikacją z MySql'ową bazą danych. API było trochę upośledzone (pomijając brak dokumentacji), ponieważ akceptowało tylko requesty typu GET z czego wynikło później trochę problemów.

Nie miałem szansy pracować przy aplikacji mobilnej, ale w serwisie webowym napisanym w #php występowała klasa ApiRequest (też nie udokumentowana) z szeregiem (prawie setką) funkcji (które czasami się dublowały, ponieważ, jak przypuszczam, ktoś dopisywał brakującą funkcję nie sprawdzając czy już taka istnieje) dających nam możliwość interakcji z bazą danych. Przykładowo prosty select wyglądał tak:

$apiRequest->select("products","price$10","id|name")

co przekładało się na:

SELECT id, name FROM products WHERE price = 10

Znak '$' oznaczał '='.
W tym przypadku nie widziałem nic niepokojącego, ot taka konwencja. Problemy zaczęły się kiedy okazało się, że projektant klasy ApiRequest uznał, że znak '@' będzie idealny do zastąpienia sql'owego 'LIKE'.
Miałem za zadanie zrobić formularz do odzyskiwania hasła sprawdzając wcześniej czy podany email jest w bazie. Możecie sobie wyobrazić co się działo.

$apiRequest->select("users","email$[e-mail]","*")

dawało

SELECT * FROM users WHERE email = przykladowy.email LIKE gmail.com

Spytałem programisty co z tym robimy. Stwierdził, że nie ma sensu przerabiać klasy, bo "@" jest już użyta zbyt często, a on nawet nie wie gdzie. Miałem obcinać mail o domenę oraz @ i sprawdzać czy w bazie jest email, podobny do tego co pozostało.

W jeszcze ciekawszy sposób rozwiązano projekt same bazy danych. W bazie były promocje oraz produkty, promocja mogła obejmować wiele produktów, a jeden produkt mógł być obecny w wielu promocjach, klasyczna relacja many-to-many. Tutaj zamiast stworzyć jakąś pośredniczącą tabelę, zdecydowano się w tabeli promocje dać kolumnę typu varchar przechowującą łańcuch id'ków wszystkich produktów objętych promocją, oddzielonych przecinkami lub średnikami (nikt nie widział od czego to zależało). Poznanie produktów objętych daną promocją nie było w zasadzie trudne. Wyciągało się ten łańcuch id'ków i dzieliło według średnika (lub przecinka), a potem wyciągało dany produkt pojedynczo z bazy po id. Problemy pojawiły się kiedy okazało się, że dany produkt jest objęty daną promocją w pewnej ilości np. 1000 sztuk. Dana promocja miała teraz kolumny: amounts w postaci '100;200;300;' oraz product_ids '4;2;3;'. Przyjmijmy, że ktoś zakupił 20 sztuk produktu o id 3. Najpierw należy poznać miejsce id produktu w łańcuchu, następnie wyciągnąć cały amounts, wyciąć wartość będącą na tym samym miejscu co id, pomniejszyć ją o odpowiednią ilość, połączyć string z powrotem, a na koniec zaktualizować promocję.

Wspominałem wcześniej, że API jest upośledzone, ponieważ akceptuje tylko requesty typu GET. Osobiście nie miałem z tym żadnych problemów, ale kolega student walczył z pewnym formularzem, który był bardzo obszerny, a jego dane po prostu nie mieściły się w gecie. Modyfikacja API nie wchodziła w grę, więc postanowił, że podzieli dane i wyśle tyloma requestami iloma zajdzie potrzeba.

Na razie tyle.
Od teraz każdy kolejny wpis będzie się ukazywał pod #januszeit

[mariecziek]

@Shreder67:

[qwelukasz]

@mariecziek: #pdk

[imper69]

@Shreder67: dobrze sie zapowiada, czekam na wiecej xD

[Benzen]

@Shreder67: Zalinkuj stronę, muszę to zobaczyć xD

[hajs86]

@Shreder67: Tak się zastanawiam kim są ludzie którzy tam pracują. Z tego co piszesz to wynika że nie mają żadnego doświadczenia w budowaniu tego typu systemów. Widać że przed implementacją nie ma żadnej fazy projektowania tylko robienie na hurra i jakoś to będzie. Nikomu nie przeszkadza taki stan rzeczy? Biznes nie widzi żadnego problemu w tym co się dzieje? Wiesz może ile tam zarabia dev który już tam dłużej pracuje?

[S.....7]

@hajs86: Z tego co wiem firma jest świeża, max rok na rynku, a to jest ich pierwszy duży projekt. Szef miał jakieś doświadczenie w IT, ale nie znam szczegółów. Faza projektowania i developmentu przeplatały się. Np szef na podstawie oczekiwań klienta razem z programistą ogarniali kolejną funkcjonalność, a następnie cały team brał się za kodowanie. Kiedy funkcjonalność była gotowa, następował ponowny kontakt z klientem, co dalej itp, a cały proces zaczynał