[a.....a]

Ja jako już doświadczony # programista25k mogę powiedzieć, że na początku drogi zawodowej (jakieś 5 lat expa) brałem udział w projekcie typu "big rewrite". I skończyło się bardzo podobnie: zajęło w ciul więcej czasu niż było planowane, a użytkownicy końcowi aplikacji byli zawiedzeni, bo stara aplikacja była lepsza. Każdy kto brał udział w takim projekcie wie, że to błąd i trzeba bało wybrać inne podejście (czyli tych rad z książek typu working with legacy code to się trzeba słuchać xD). Nie wiem kto w wykopie podjął taką decyzję, ale doświadczeniem nie błyszczał... Natomiast zawsze uważałem, że infrastrukturalnie (wydajnościowo) to wykop naprawdę daje radę jak na taki ruch który obsługuje.

#programowanie #wykop #nowywykop #wykop20

[ponton]

@alina-muhammadowa-krawczykowa: to wiadomo już od ponad 20 lat ( ͡° ͜ʖ ͡°)

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[a__s]

trzeba bało wybrać inne podejście

@alina-muhammadowa-krawczykowa: Rozważaliśmy różne warianty i scenariusze, ale niezmienne było to, że kod wymagał przepisania. Jakiekolwiek przebudowy nie dawały zauważalnych efektów. Obecnie chcemy skupić się na wdrożeniu usprawnień, których oczekujecie. Później, wspólnie z Wami, zaplanujemy nowe funkcjonalności :-)

[jalop]

@alina-muhammadowa-krawczykowa
proszę Cię, 10k czy nawet 30k online userow, to bardzo mało.

[SynGromu]

@a__s: odblokuj mnie z czarnej to będę Ci na bieżąco podsyłał znalezione błędy.

[juniordev]

@alina-muhammadowa-krawczykowa:

Natomiast zawsze uważałem, że infrastrukturalnie (wydajnościowo) to wykop naprawdę daje radę jak na taki ruch który obsługuje

No ale niektóre rzeczy nie działały. Tagi i puste gorące to efekt słabego designu który nie pozwalał, zapewne, na poprawna implementację tych ficzerów

[veranoo]

@a__s: Może najpierw było przepisać backend a frontu nie tykać. Jak już byście zrobili backend to zrobić opcje na przełączenie nowy frontend i zbierać od ludzi feedback i przede wszystkim nie ubijać starego api xD

W projekcie którym pracowałem (coś podobnego do Booking-u) robiliśmy testy AB nawet małych rzeczy które zmienialiśmy żeby nie spadła konwersja.

[Krolik]

@alina-muhammadowa-krawczykowa: @a__s @ponton ten art Joela to cherry picking przypadków pod wybraną tezę. A ja Wam powiem że widziałem parę rewrite'ów, które się udały, a jeden taki na 0,5 mln linii kodu i to z Javy do C++ (ScyllaDB), gdzie końcowy rezultat jest bardziej stabilny i wydajniejszy niż oryginał. Rewrite zwykle się udaje jeśli ekipa robiąca go to inna ekipa, która ma lepsze skille niż ekipa robiąca oryginał. Nie udaje się

[a.....a]

@Krolik: Kwestia tego co uważasz, że jest "udane". Mój projekt do tej pory pewnie działa, jest lepszy technologicznie. Można uznać, że jest udany bo działa. Wykop też będzie działał, będą go usprawniać, w pare miesięcy się to uda. Ale z perspektywy ponad 3 lat czasu i poniesionych kosztów zespołu w tym czasie zachodzi pytanie, czy nie byłoby optymalniej wybrać inne podejście - taniej i szybciej i łatwiej. Moje doświadczenie jest takie,

[a.....a]

@jalop: Wydaje mi się, że szczytowy ruch na wykopie może być zdecydowanie większy. Oczywiście nie teraz ( ͡° ͜ʖ ͡°)

[datester]

@a__s: sorry, ale pojęcia o swojej pracy to wy nie macie w ogóle. To co robicie to totalna i żenująca amatorszczyzna. Za co wy te dopłatę wzięliście? XDDDDDDDDDDDD

[Krolik]

@alina-muhammadowa-krawczykowa: to zależy od tego jak bardzo gówniany był oryginalny produkt. Jak tylko trochę, to lepiej poprawiać przyrostowo. Jak bardzo, to znacznie szybciej i taniej jest przepisać na nowo, bo nie jesteś związany ograniczeniami starego produktu. W kiepskim kodzie jak ruszysz jedną rzecz to się psuje kilka innych. Dlatego przepisanie tylko 1/10 serwisu to nie jest 1/10 pracy potrzebnej na przepisanie całości tylko znacznie więcej i przyrostowe poprawianie zwyczajnie jest nieekonomiczne.