Praca z zastanym kodem

Naście lat temu klient złożył zapotrzebowanie na aplikację.
Zrobiona, wdrożona, działa, ciągle używana. Czasem jakiś moduł trzeba dopisać, czasem jedną linijkę zmienić.

Technologia już leciwa, nowi nie chcę tego robić a ci którzy muszą krzywo na to patrzą.
Klient nie widzi potrzeby zapłacenia za to samo drugi raz bo i po co.

W jaki sposób podchodzicie do takich problemów (jeżeli takie macie)?
Utrzymujecie taki kod, staracie się przekonać jednak klienta do zmiany (jak to argumentujecie), na koszt własnej firmy postanawiacie zrobić nową wersję systemu ?
Może jakieś inne rozwiązania / podejścia ?

Jak tylko jeden klient tego używa to nie warto ruszać. Poprawiać i tyle. Przy jakiejś większej zmianie warto z nim o tym pogadać, żeby to przepisać. Może się to okazać wielką porażką jak klient dostanie nowe niby lepsze narzędzie, ale nie będzie stabilne (stare pewnie już działa stabilnie). Można też zakończyć wsparcie produktu (jak się nie opłaca) i wówczas klient może rozważy zakup nowego.

1. Dlatego powinno się cały czas "utrzymywać" kod, podbijać wersje bibliotek, refaktorować etc, wtedy nie ma problemu że coś jest "zastane"
2. Możecie powiedzieć klientowi ze nie da się zrobić ficzera X bo stara technologia na to nie pozwala, albo wyceniać nowe rzeczy "drożej" niż realnie są i w tym dodatkowym czasie np. implementować od nowa cały moduł.
3. Częstą praktyką są adaptery -> nie ruszacie starego kodu, tylko robicie nad nim adapter który rozszerza możliwości. To wymaga jednak sensownej architektury z jakimiś modułami czy serwisami.

Shalom napisał(a):

1. Dlatego powinno się cały czas "utrzymywać" kod, podbijać wersje bibliotek, refaktorować etc, wtedy nie ma problemu że coś jest "zastane"

Zgadzam się. Refaktorowany Visual Basic nie zachęca. Aczkolwiek są też takie projekty w C#. Jednak jeżeli te projekty nie stanowią Twojej codziennej pracy to trudno o takie utrzymanie. Tym bardziej jeżeli takie utrzymanie dostajesz w spadku.

2. Możecie powiedzieć klientowi ze nie da się zrobić ficzera X bo stara technologia na to nie pozwala, albo wyceniać nowe rzeczy "drożej" niż realnie są i w tym dodatkowym czasie np. implementować od nowa cały moduł.

W ostatnim czasie takie coś się udało! +1

3. Częstą praktyką są adaptery -> nie ruszacie starego kodu, tylko robicie nad nim adapter który rozszerza możliwości. To wymaga jednak sensownej architektury z jakimiś modułami czy serwisami.

Dzięki. Zastanowię się nad tym.

Shalom napisał(a):

1. Dlatego powinno się cały czas "utrzymywać" kod, podbijać wersje bibliotek, refaktorować etc, wtedy nie ma problemu że coś jest "zastane"

Tak się da, jak produkt żyje i jest w miarę regularnie rozwiajny - jak jest jedno zgłoszenie na 5 lat to takie rzeczy są mało opłacalne.

nie można zakończyć wsparcia bo klient płaci.

Można. Pytanie tylko jakie są kary i warunki w umowie. Jeżeli wsparcie się nie opłaca, bo umowa jest niekorzystna, a ludzie chcą ekstra kasy za grzebanie w kupie to po prostu trzeba zbankrutować. Czasem warto.

A tak z ciekawości ile ten klient płaci za support? Płaci stale co miesiąc czy tylko gdy czegoś chce? Jeśli płaci co miesiąc to ta kasa chyba powinna iść w części na utrzymanie projektu przy życiu, update na bieżąco. Jak przez 10 lat się brało kasę za nic to potem dług jest chyba po stronie producenta oprogramowania - potem się okazuje że nagle się nie da podnieść wersji żadnej biblioteki ani kompilatora do nowszej wersji bo wszystko jest zupełnie niekompatybilne

Chyba niepotrzebnie użyłem argumentu "klient płaci". Nie jest to istotne, należy utrzymywać i czasem rozwijać takie systemy.
Przecież to nie jest tak, że wszyscy tworzymy przez całą karierę zawodową jeden soft i stale go rozwijamy. Często należy stworzyć systemy, dostarczyć je do klienta a następnie jedynie utrzymywać. Następnie tworzy się kolejne aplikacje dla tych samych lub innych klientów (wiem że różna jest specyfika pracy, ale taka jak przytoczyłem również istnieje). Wówczas ciężko o bieżącą aktualizację takich systemów.
Nie ma problemu z aplikacjami, które są stale rozwijane. Problem jest taki, że dziś tworzymy aplikację, za rok ją wdrożymy, przez kolejne 5 lat będziemy robić drobną zmianę raz lub dwa w roku a następnie kod staje się przestarzały bo zmieniają się technologie, biblioteki, praktyki. Nie zajmujemy się na co dzień takim kodem bo są przecież inne projekty, które należy realizować. Dodatkowo może być tak, że dostajemy do utrzymania taki system i faktem jest to, że on istnieje i należy go utrzymać i wprowadzać zlecone, raz na jakiś czas, zmiany przez klienta.

niepotrzebnie użyłem argumentu "klient płaci". Nie jest to istotne

To jest bardzo istotne, wręcz kluczowe.

Sprawa jest prosta - jeśli program ma wielu użytkowników, albo chociaż jednego, ale dobrze płacącego, to warto go utrzymywać nawet jakby był napisany w Basicu ;)

A jeśli klient nie płaci/projekt jest na minusie, to trzeba to zaorać i to jak najszybciej.
Jak ktoś chce pisać dla radości pisania to się zapisuje do jakiegoś projektu OpenSource i tam pisze sa free. Firma ma na programie zarabiać i to jest podstawowy powód, dla którego firma oraz aplikacja istnieją.

przez kolejne 5 lat będziemy robić drobną zmianę raz lub dwa w roku a następnie kod staje się przestarzały bo zmieniają się technologie, biblioteki, praktyki

Ok, ale nadal można do takiego kodu wprowadzać zmiany. Nie jest to ani przyjemne, ani łatwe - niemniej, jeśli klient płaci, to powinno się to zrobić.

To o czym piszesz to raczej kwestia wyczucia momentu, w którym osoby zarządzające projektem powinny podjąć decyzję - czy aktualizujemy, czy zostawiamy jako legacy. Ale żeby taką decyzję podjąć, trzeba wiedzieć ilu userów mamy, ile oni płacą (czy opłaty abonamentowe, czy raczej za wykonane prace/aktualizacje/modyfikacje) - mając te dane da się ocenić, na ile takie przedsięwzięcie jest opłacalne. Bo równie dobrze może się okazać, że program sobie żyje własnym życiem, modyfikacje są bardzo rzadkie i poświęcenie setek czy tysięcy godzin na przerabianie całości to kasa i czas wywalone w błoto. Lepiej po prostu, jak będzie potrzeba, wykonać modyfikację, która by normalnie trwała 10 h w czasie 40h (bo legacy i stary fyf). Na tym konkretnym zleceniu jesteśmy 30h w plecy, ale całościowo to mamy zaoszczędzone kilkaset godzin, za które nikt by nie zapłacił.

cerrato napisał(a):

niepotrzebnie użyłem argumentu "klient płaci". Nie jest to istotne

To jest bardzo istotne, wręcz kluczowe.

Chciałem napisać, że nie jest to istotne dla tej dyskusji aby nie skupiać się na finansach a na głównym problemie.

Sprawa jest prosta - jeśli program ma wielu użytkowników, albo chociaż jednego, ale dobrze płacącego, to warto go utrzymywać nawet jakby był napisany w Basicu ;)

Dlatego go utrzymujemy :)

Ok, ale nadal można do takiego kodu wprowadzać zmiany. Nie jest to ani przyjemne, ani łatwe - niemniej, jeśli klient płaci, to powinno się to zrobić.

Dlatego stworzyłem ten wątek - żeby dowiedzieć się jak podchodzą inni to problemów wynikających z takich sytuacji.

Dziękuję za odpowiedź.

Chciałem napisać, że nie jest to istotne dla tej dyskusji aby nie skupiać się na finansach a na głównym problemie.
[...]
Dlatego stworzyłem ten wątek - żeby dowiedzieć się jak podchodzą inni to problemów wynikających z takich sytuacji.

No ale to. co można w takiej sytuacji polecić zależy od tego, co napisałem w poprzednim poście - czyli od tego, na ile apka jest dochodowa. Inna będzie porada w sytuacji jednego usera płacącego 5 stówek rocznie, inna jeśli jest jeden, ale płaci 10k/rok, a jeszcze inna jeśli masz 300 userów po 1k miesięcznie każdy.

Wydaje mi się, że nie ma sensu takie luźne gadanie w oderwaniu od realiów, a głównym kryterium oceny sensowności i możliwych opcji to podejście od strony finansowej.

Odpowiedź może być tylko jedna. Trzeba znaleźć szambonurka. Człowieka który odrzucił ideały pisania nowego, clean code'u i za pieniądze zrobi wszystko (byle było legalne)

gosc_z_pytaniem napisał(a):

Naście lat temu klient złożył zapotrzebowanie na aplikację.

Zrobiona, wdrożona, działa, ciągle używana. Czasem jakiś moduł trzeba dopisać, czasem jedną linijkę zmienić.

Jak ciągle używana, to pewnie nie za darmo.

Technologia już leciwa, nowi nie chcę tego robić a ci którzy muszą krzywo na to patrzą.
Klient nie widzi potrzeby zapłacenia za to samo drugi raz bo i po co.

A czemu by miał widzieć potrzebę. Klienta dokładnie wali, czy ma system zrobiony we frameworku z aktualnej, czy zeszłorocznej kolekcji.

W jaki sposób podchodzicie do takich problemów (jeżeli takie macie)?
Utrzymujecie taki kod, staracie się przekonać jednak klienta do zmiany (jak to argumentujecie), na koszt własnej firmy postanawiacie zrobić nową wersję systemu ?
Może jakieś inne rozwiązania / podejścia ?

Zrobiliście system za bańkę, zrobienie go jeszcze raz w "nowej technologii" nie dostarczy klientowi żadnej wartości, firma nie ma żadnego interesu w przepisaniu tego. Jak działa, to nie dotykać, czasami poprawić buga, dopisać modulik. Jak trochę działa, to pokrywać testami, refaktoryzować, podbijać biblioteki. Jeżeli nie działa, to dopiero można się zacząć zastanawiać, czy uwalić projekt, czy pisać od nowa.
Zaskakująco często widzę wśród programistów przekonanie, że to co piszą, to cel sam w sobie. Jak piszecie/macie jakiś system, to jedynym momentem w którym klient będzie chciał rozmawać na temat "zróbmy nowe" jest ten, w którym ktoś mu powie "nie da się". Problem w tym, że od czasu jak został napisany ten cud techniki, konkurencja nie spała i w większości przypadków, klient będzie wolał kupić gotowca od konkurencji, niż od firmy, która mu odmawia wykonania jakiejś usługi.

Pytanie czy jest to problem ze starą technologią czy z tym, że projekt jest ciulowo zrobiony. Mi osobiście lepiej się pracuje w starym sensownmym codebasie niz nowoczesnym ale napisanym bez ładu i składu.

Czasami tylko te stare bardzo ciężko sie debuguj czytaj stara wersja GWT z dość skomplikowanym buildem :v.