trochę z innej strony.
była sobie pewna strona, robiona przez pewną firmę z naszej pewnej grupy. z bliżej mi nieznanych powodów powodów strona ta trafiła do mojej firmy. tu się zaczyna. z racji tego, że używamy c#/asp, w firmie nie było programistów php (a w tymże języku napisana została strona). było dwóch jako-tako znających ten język, projekt trafił do znającego go słabiej i w dodatku odchodzącego za miesiąc z firmy pana W.
W. przez miesiąc nie zrobił prawie nic, a miał do zrobienia dość dużo - miał podzielić serwis tak, aby mógł działać w kilku "instancjach" jednocześnie, coś w rodzaju osobnych wersji dla różnych krajów. po miesiącu nadszedł termin oddania projektu i pewnego poniedziałku mieli zjechać do Warszawy dyrektorzy regionalni ze świtami z całej Polski. kilka dni wcześniej, w okolicach wtorku, okazało się, że pan W. faktycznie prawie nic nie zrobił i że mamy nielichy problem. przez miesiąc project manager nie zauważył, że postępów w projekcie praktycznie nie ma, a było to do przewidzenia, skoro projekt dostał człowiek odchodzący z firmy, któremu nie zależało na zrobieniu go. zostało kilka dni na wdrożenie w projekt drugiego programisty (Z.) oraz na wykonanie i przetestowanie zmian. fizycznie niemal niemożliwe. ale to nic. pan Z. dowiedział się w środę, że jest taki projekt, w czwartek, że jest dość ważny, w piątek trzeba było wykonać krytyczne poprawki w innym systemie i tak oto zostały dwie i pół doby do godziny "0". dopiero w piątek wieczorem kierownictwo oświadczyło Z., że projekt jest krytycznie ważny, a poniedziałkowej prezentacji nie da się odwołać (wykupione miejsca w hotelach, bilety itp). i co? ano, udało się, programista zasuwał ponoć 40h pracy bez przerwy + dwa genialne pomysły account managera (nie potrafiącego programować) + pobłażliwość (wynikła ze zdziwienia) ze strony przybyłych na prezentację, którzy byli święcie przekonani, że nie zdążymy.
to odnośnie "warstwy biznesowej" projektu. ale to nie koniec.
strona działała kosmicznie wolno. kilka-kilkanaście sekund na wygenerowanie strony. po krótkiej analizie okazało się, że z każdej strony do bazy danych leci około 200 zapytań. bardziej wnikliwa analiza wykopała takie kwiatki:
- chcesz wyświetlić konkurs o danym id? pobierz wszystkie konkursy i w pętli wyświetl ten właściwy (oczywiście bez break - a nuż autoincrement na id konkursu nie zadziała).
- pobieranie danych do wszystkich możliwych elementów stron, tak jest przecież fajniej, bo można jeden moduł ładujący dane podpiąć pod każdą stronę - a że 3/4 z tych danych jest niepotrzebne to nieważne;
- załączniki dla newsów? koniecznie dla każdego newsa wyciągane w osobnych zapytaniach, jesli na stronie 10 newsów, to 10 dodatkowych zapytań.
po odchudzeniu/wyrzuceniu/przepisaniu zapytań udało się zejść do ~25 zapytań per request przy wyłączonym cache'u. ale i tak coś długo się wykonywały, ponad 80% czasu generacji strony. rzut oka na indeksy w bazie danych (może coś się uda podkręcić?) i jedno z większych wtf mojego programistycznego życia: ani jednego indeksu. powinienem to sprawdzić na początku, ale w życiu mi do głowy nie przyszło, że w profesjonalnej skąd-inąd firmie, która wcześniej zajmowała się tworzeniem tego serwisu, mogli tego nie zrobić. godzina pracy i baza danych przyspieszyła 4-krotnie.
to nie koniec.
rozbudowana strona, odwiedzana przez kilkanaście osób na sekundę, działająca na jednym serwerze http (w dodatku iis) i napisana w php wymaga jakiegoś systemu buforowania. poprzedni programiści nie wpadli na to, buforowali jedynie niektóre zapytania (z czego część nieprawidłowo - dane w niektórych miejscach odświeżały się dopiero po restarcie serwera). buforowanie na poziomie całej strony (nie dało się zrobić na poziomie pojedyńczych elementów, bo serwis nie jest oparty o żaden framework - doh!) zmniejszyło obciążenie serwera na tyle, że z wyjątkiem sporadycznych peaków strona generowała się w akceptowalnym czasie > 1s.
warstwa "logiki" biznesowej... żal. jeden plik o rozmiarze 300kB, nawet nie klasy. podział na poszczególne kraje? kopie tego pliku ze zmienioną nazwą, zmienionymi nazwami funkcji (!) i innymi wartościami niektórych zmiennych/stałych.
została warstwa prezentacji. tabele. w nich tabele, a w nich kolejne, rekordowo chyba siódmy poziom zagnieżdżenia, już nie wiadomo czy wszystkie tabele są pozamkane i która gdzie się kończy, zwłaszcza, jeśli tabelę otwiera się w jednym pliku, a zamyka w drugim. css? no, jest, ale inline jest dużo fajniej przecież, więc i dużo częściej. do tego nazwy klas typu gren_span czy yeloow_header.
projekt spieprzony jeśli chodzi o bazę danych, warstwę biznesową i prezentacji oraz zarządzanie nim.
ale nie zapominajmy o przedstawicielu firmy, dla której powstawała ta strona. gościu z innej bajki, niemający pojęcia o tym, co to bugzilla, trac czy mantis, niepotrafiący nie tylko programować, ale nieznający nawet podstaw html (dopiero ostatnio się podszkolił), a zatem nie mający bladego pojęcia, jak to wszystko działa, do tego bardzo chaotyczny i niekonsekwentny. w efekcie kilka razy było tak, że trzeba było kilkadziesiąt minut pracy poświęcić na cofnięcie zmian robionych pół dnia.
i teraz moim zdaniem najśmieszniejsze: po miesiącu zorientował się, że nie działa system rejestracji nowych użytkowników, po sześciu tygodniach, że nie działa system dodawania komentarzy, i dopiero po półtora roku, że nie działa wysyłanie propozycji piosenek.
wstydzę się tego systemu. programistyczna prostytutka.
cdn.
ps. serwis nie ma serwera deweloperskiego ani acceptance...
// o kurczę, ale cegła wyszła...
