Wiem, że dzisiaj jest już trochę przesyt tematem portalu na W, ale chciałem zacząć trochę poważniejszą dyskusję na gorąco zanim emocje opadną, bo jutro już raczej mi się nie będzie chciało. Wiadomo, że najlepiej uczyć się na cudzych błędach dlatego proponuję pochylić się nad case study (czy może Post Mortem?) tej wczorajszej udanej aktualizacji portalu kojarzonego z rogalami i Poznaniem żeby wypunktować największe grzechy oraz zastanowić się jak można to było zrobić prawilnie. Także zapraszam do zabawy w panów z obrazka poniżej.
To może zacznę:
-
Testy UI/UX strony w wersji mobilnej. Tyle się mówi o mobile first, etc., a ten portal to przecież nie jest strona w stylu wejdź i zapomnij (typu jakaś wizytówka firmy) tylko portal, na któym właściciel chcę żeby użytkownicy spędzali czas. Sam traktowałem to jako "ten serwis do przeglądania podczas siedzenia na toalecie" i obstawiam z dużą pewnością, że to podsumowuje znaczną część użytkowników. Tymczasem ta aktualizacja to splunięcie takim użytkownikom w twarz. Można się załamać patrząc na te dwie belki u góry i dołu, przyciski w lewym dolnym rogu zasłaniające przyciski i kontent i te marginesy, które pozwalają zobczyć maksymalnie dwa jednolinijkowe komentarze w jednym momencie na moim ekranie.
-
Kto w ogóle wpadł na pomysł żeby ubić całą starą aplikacje, zmigrować bazę i postawić zupełnie nową? Ja rozumiem, ze pewnie tak wyszło dużo taniej i wygodniej bo nie trzeba ciągnąć za sobą legacy, ale to trzeba nie mieć wyobraźni żeby nie pomyśleć że taka droga w jedną stronę to trochę słaba opcja w przypadku większych błędów
-
Kilkugodzinny downtime, prawdopodobnie ze względu na migrację danych. Nikt w tych czasach już chyba tak nie robi w przypadku serwisów działających 24h/7. Nie miałem do czynienia z aż tak dużymi migracjami, najczęściej dotyczyły maksymalnie jednej tabeli ale wydaje mi się że dałoby się to zrobić, wystarczyłoby rozbić migrację na kilka kroków. Jeśli jest jakaś niekompatybilna wstecz zmiana na jednej tabeli to wystarczy zrobić migrację do nowej tabeli i dodać jakiś proces, który będzie automatycznie dodawał wszystkie nowe dane trafiające do starej tabeli również do tej nowej w nowym formacie. Później wypuszczamy apkę czytającą z nowej tablei i gitara, a starą tabelę usuwamy. Jeśli jest jakieś bardziej eleganckie rozwiązanie to chętnie poczytam.
-
Jak oni mogli wgrać starą kopię bazy? A przynajmniej tak się wydaje patrząc po tym, że stare konta zostawały przywaracane itp. Przecież po to był cały ten downtime żeby chyba migrować wszystkie dane, a nie jakiś backup. Aż ciężko mi w to uwierzyć i mam jakąś teorię spiskową, że to może jakiś inny błąd? Coś w stylu zapomnieli podmienić połączenie na produkcyjną bazę i leciały jakieś dane z UATów czy coś. Chociaż nie wiem czy takie coś nie byłoby nawet jeszcze bardziej kompromitujące.
-
Ubicie APIv2 i wszystkich aplikacji, które z niego korzystały bez żadnej komunikacji. Przecież nawet w wersji z ubiciem całego starego kodu można było zrobić jakieś ogłoszenia i ewentualnie parę miesięcy temu wystawić nowe endpointy, które początkowo wołają pod spodem nawet stare API. To nie jest prawilne wersjonowanie i pewnie byłyby problemy z kompatybilnością wstecz, ale lepsze to niż całkowite ubicie.
@M_B_A co do migracji bazy - sa rozne sposoby. Ale tu wychodzi cos o czym czesto zapominaja programisci - czy takie cudowania sa warte wysilku patrzac z punktu biznesowego. Albo inaczej, czy parugodzinny downtime jest warty kombinowania i pewnie sporej ilosci manhours i testow. IMO w przypadku wypoku - nie. Zwyczajnie taniej bylo zamknac portal na pare godzin.
Najbardziej w oczy bije sam layout, wszystko jest tak nachalnie uproszczone i zmodernizowane, okropne.
Sama kolorystyka trybu nocnego to chyba jakiś żart, ktoś to testował zanim to wypuścili?
Komentarze zlewają się z wpisami.
Ale najgorsze.
Absolutnie najgorsze to to że teraz komentarze podzielone są na strony, zdążyłem zauważyć dopiero po ponad godzinie korzystania z serwisu takie to wszystko tam przejrzyste.
@M_B_A UI nie jest robione według jakiegokolwiek standardu projektowania designu. Nie ma tam ani krztyny wygody. Każdy element krzyczy o uwagę i przez to potencjalny, obecny użytkownik - nie ma jak się skupić. Atakowany jest z każdej strony tym. Maciuś Front-Endowiec nie podumał.
@Deokario Co do podziału na strony to jeśli chodziło o wydajność i o to żeby nie ładować wszystkich komentarzy naraz to wystaraczyło po prostu dodać ładowanie kolejnych stron podczas przewijania, jak np. na 9GAGu. Wiadomo, trochę bardziej skomplikowana funkcjonalność (i przez to droższa), ale to raczej obecnie standard.
po prostu nowa wersja wykopu padła ofiarą deweloperów, którzy wszystko chcą przepisywać na raz zamiast wprowadzać zmiany małymi krokami
@mickpl Nie wiemy co tam dokładnie działo się z tyłu i jaki był rzeczywisty poziom złożoności, więc ciężko to jakoś wycenić i rozumiem twój punkt widzenia z kosztami. Ale na pewno taka stopniowa migracja pozwoliłaby w razie problemów łatwiej przywrócić poprzednią wersję bez straty danych, a tak mamy to co mamy.
@def No niby tak, ale ciężko mi w to uwierzyć bo przecież zarządcy wypoku nie siedzą w tym biznesie od dzisiaj i niejeden fakap przeżyli i powinni wyciągnąć jakieś wnioski. No a jeśli chodzi o programistę to ciężko mi sobie wyobrazić żeby ktoś z większym doświadczeniem coś takiego zaproponował. Nie wiem jak duży zespół tam teraz pracuje.
@M_B_A jeśli chodzi o UI to chyba jestem starej daty, ale nim mniej wodotrysków tym lepiej, podświetlenie po najechaniu myszą itp.
@M_B_A ktoś musiał to zaproponować, a wątpię, żeby to biznes wyszedł z propozycją kosztownego przepisania całego kodu
@def Zakładając, że nie było co ratować to przepisanie całej aplikacji mogło być kilkukrotnie tańsze
@Magiczny_Magik Tylko po czasie zobaczymy czy ta oszczędność nie była gwoździem do trumny tego serwisu. Najtaniej to w ogóle byłoby zrobić DROP DATABASE i pora na CSa. A ile można wtedy oszczędzić na serwerach
No ale ciężko przewidzieć jakie będą długofalowe konsekwencje dla biznesu i czy użytkownicy zostaną czy odpłyną i czy spółka zapikuje w dół czy się jakoś utrzyma.
@M_B_A Ja do tego syfu już na pewno nie wrócę xD Do widzenia panie Biauek
@M_B_A A ja się zapytam - co w takim przypadku apki 24/7 gdy masz jedną bazę (a niestety, trzeba założyć, że wypok tak funkcjonował, sądząc po "ilości xD" updatów przez ostatnie lata), ludzie do niej walą z postami, obrazkami etc. a ty chcesz to przenieść na nowy serwer/technologię no cokolwiek?
Tworząc nową bazę i nawet puszczając to przez skrypt, który tam dopasowuje dane do nowego schematu, wciąż masz setki czy tysiące userów na portalu walącym do starej bazy. Moim zdaniem @mickpl dobrze pisze - gasząc cały portal masz go w jasnym, określonym stanie - "NIE DZIAŁA".
Zakładając, że wdrażasz znaczącą zmianę, to przynajmniej wiesz, że nikt w trakcie nie pchnie jakiegoś grubego szajsu dojeżdżającego bazę danych czy np. nie zacznie się jakiś meczyk i mireczki nie zaczną postować 30000x na sekundę. Już pomińmy tutaj idiotyczne okno serwisowe na portalu, gdzie "północ to dopiero wieczór".
Co do reszty zgoda, choć wydaje mi się, że ten update to było właśnie przejście jak między monolitycznym Windows 98, na XP z hybrydą- i ktoś to koncertowo skopał..
@tellet Musieli zacząć okno serwisowe o północy żeby zdążyć do rana
Dla mnie to naprawdę ciekawy przypadek, no bo serwis jednak z jakąś tam wyrobioną marką i całkiem sporym ruchem, a serwisowany tak że z boku to wygląda jakby było robione przez studentów na zaliczenie. Nie kojarzę podobnej sytuacji wśród portali, które dobrze znam i z których na codzień korzystam.
@M_B_A jaj mam wrażenie, że tam ktoś tam zapomniał zrobić więcej badań tego czego ludzie używają. Skupili się na biznesowej części tego jak działa główna, mirko zrobili na odpierdol, a api to juz w ogóle wyjebane.
Co do downtime to miałem przyjemność pracować nad kilkoma aplikacjami typu legacy i w bazie często najebane tyle niekonsekwentnych patentów (m.in. po migracjach na żywo lub testowaniu na prodzie), że jeden konkretny skrypt do migracji przy wyłączonym serwisie to jedyna opcja.
Moim zdaniem @mickpl dobrze pisze - gasząc cały portal masz go w jasnym, określonym stanie - "NIE DZIAŁA".
@tellet to tez, ale chodzilo mi o prosta kalkulacje. Portal offline przez, nie wiem, 6h to powiedzmy 6000zl starty. Programista ktory spedzi miesiac pracujac nad migracjami w realtime bedzie kosztowal pewnie trzy razy tyle, albo i cztery jak sie wszystkie koszty uwzgledni.
A pewnie trzebaby uwzglednic pare wiecej osob, jakiegos testera. Wiec zwykly ekonomiczny rachunek
@mickpl wykop do tej pory nie miał realnej konkurencji, więc mając taką rynkową pozycję mogli sobie pozwolić na takie niezbyt ładne wdrożenie zmian. Nie działają stare projekty? No trudno, na pewno wkrótce ich autorzy się dopasują do nowego API. Ale takiej migracji na hejto to chyba nikt się nie spodziewał.
@M_B_A mnie zabiło to jak zrobili paginację (randomowy string zamiast numeru strony), podejrzewam dlaczego (wydajność i żeby było taniej to utrzymywać), ale nim użyje się jakiegoś rozwiązania trzeba sprawdzić jaki to ma wpływ na UX. O czytelności nowego portalu to nawet nie wspomnę, naprawdę trzeba mieć dodatkowy chromosom, aby klepnąć te wszystkie zmiany i sądzić że ludzie będą klaskać z radości.
Zaloguj się aby komentować