Maintenance vs Development

0

Witam,
Co jest trudniejsze: utrzymywanie starych projektów i systemów typu legacy czy tworzenie nowego softu? Jakich umiejętności wymaga maintenance a jakich development. Czego robi się więcej (komercyjnie).

0

Joel Spolsky powiedział kiedyś, że kod łatwiej się pisze niż czyta. Miał świętą rację.

Komercyjnie to najwięcej jest utrzymania.

0

Zdecydowanie maintenance, bo w starych projektach nawarstwia sie duzo kawalkow kodu, ktorych sie NIE DOTYKA. Ewentualnie obchodzi sie szerokim lukiem, zeby tylko nie zaczelo smierdziec ;) Pozniej zaczynaja sie hacki na hacki i juz jest bardzo zle. Choc sytuacja moze byc tez odwrotna - zle zaprojektowany nowy system jest gorszy od dzialajacego x lat starego. Ale z mojej praktyki raczej te starsze byly ciezsze. Zwykle nowy projekt, ktory piszemy sobie od zera jest mila odskocznia od zesztywnialego kolosa, do ktorego pewnie nie ma dokumentacji.

0

Dokumentacji... U mnie w firmie jedyna dokumentacja ma na imię Krzysztof.
A maintentance to w zasadzie niekończący się refactoring.

0

Nie wiem, czy to śmieszne, czy smutne, jak bardzo jesteśmy zgodni -- w tej chwili 10/10 głosów jest na Maintenance. I to prawda.

Z drugiej strony nie wiem, czy trudniejsza jest praca ze starym kodem, czy napisanie nowego, który byłby naprawdę dobry i w przyszłości nie sprawiałby nikomu problemu? Jak często zdarza się Wam napisać złożony kod, z którym nawet po wielu latach lubicie pracować i nie musicie go ciągle refaktorować? (Najlepiej jeszcze, by pozytywną opinię o tym kodzie potwierdził ktoś, kto nie uczestniczył w jego tworzeniu te kilka lat temu i kto nie jest Waszym podwładnym :P).

0

Ale w zasadzie co można nazwać maintenancem?
Dopisywanie kodu do istniejącego projektu czy fiksowanie bugów i refaktoryzację?

0

i to i to...

0

Moim zdaniem projektowanie i pisanie nowego kodu (bazując na starym) jest trudniejsze od maintenance'u (który głównie sprowadza się do fiksowania bugów). Na maintenance można wrzucić kogoś zielonego w programowaniu i ten ktoś będzie po trochu poznawał projekt. W końcu będzie w stanie sam naprawiać faulty a jeżeli ma zdolności analityczne to pewnie będzie w tym całkiem niezły.
Designem i programowaniem powinny zajmować się osoby bardziej doświadczone z nie mniejszymi umiejętnościami analitycznymi. Kod, który łatwo się utrzymuje w przyszłości, który jest czytelny i dobrze zaprojektowany nie jest łatwo napisać.
Niestety nowy kod często piszą laicy a potem bardziej doświadczonym przypada rzeźbienie w gównie :/

0

@rnd, zapraszam do mnie ;) w większości maintenance. Osoba zielona nie poradzi sobie z tym za chiny ludowe, bo trzeba mieć dużo wiedzy dotyczącej zasad funkcjonowania różnych elementów języka, by w ogóle mówić o zrozumieniu kodu. Niestety Javo-COBOL :)

Pisanie kodu jest łatwe lekkie i przyjemne. Mając trochę obycia i wiedzy można w zasadzie skupić się na elegancji rozwiązań i nie patrzyć na ograniczenia. Utrzymanie wbija nas w przyciasny i zazwyczaj niemodny garnitur starego kodu. W dodatku musimy w tym kubraczku skakać, tańczyć i bóg wie co wyczyniać by klient nie odszedł.

0

Koziołek - ja tam jestem na maintenancie od 8 miesięcy i wiem jak to wygląda. Ale nadal twierdze, że developowanie dobrego kodu (a nie tylko działającego) jest trudniejsze.
A projekt w którym pracuje ma tak elegancko spieporzony design, że śmiga w nim 700 wątków (!) oczywiście synchronizacja jest szczątkowa. 90% bugów jest związana ze współbieżnością (coś tam gdzieś tam się nadpisuje zazwyczaj). Geniusz-projektant, który dawno już nie pracuje, wymyślił żeby synchronizować wątki tylko wtedy kiedy pojawi się jakiś bug związany z brakiem synchronizacji :D (ponoć to ze względu na wydajność).
Gdyby tylko ktoś bardziej doświadczony projektował tą aplikacje i ktoś bardziej doświadczony ją pisał na pewno nie było by takiego bajzlu a i maintenance byłby znacznie prostszy.

Mając trochę obycia i wiedzy można w zasadzie skupić się na elegancji rozwiązań i nie patrzyć na ograniczenia.

Zależy jakie aplikacje piszesz.
Aplikacje na urządzenia wbudowane czy chociażby komórki posiadają ograniczenia ze względu na pamięć oraz moc procesora. Programowanie niskopoziomowe też narzuca różne ograniczenia. Tyle, że te ograniczenia zazwyczaj mają sens i z czegoś wynikają (np. z architektury sprzętu) a ograniczenia w maintenance wynikają tylko z głupoty programistów i zwalonego designu.

Osoba zielona nie poradzi sobie z tym za chiny ludowe, bo trzeba mieć dużo wiedzy dotyczącej zasad funkcjonowania różnych elementów języka, by w ogóle mówić o zrozumieniu kodu

Jak nie znasz jakiejś konstrukcji czy słówka kluczowego w kodzie to sobie doczytasz na googlu co to jest.
Jak nie znasz zasad dobrego designu to ich po prostu nie zastosujesz przez co jakoś kodu spada.

Poza tym odróżnił bym dopisywanie funkcjonalności do istniejącego kodu od pisania projektu od 0 i od naprawiania bugów.
W hierarchi 'trudności' uporządkował bym to tak:
dopisywanie funkcjonalności do istniejącego kodu > naprawiania bugów > pisania projektu od 0

Przy czym pisanie kodu od 0 chyba komercyjnie praktycznie nie występuje.

0
rnd napisał(a)

Jak nie znasz jakiejś konstrukcji słówka kluczowego w kodzie to sobie doczytasz na googlu co to jest.

Manual ma "tylko" trzy regały. W dodatku całość jest przeniesiona tak by emulować zachowanie COBOLa na określonym komputerze.

rnd napisał(a)

Aplikacje /.../ a ograniczenia w maintenance wynikają tylko z głupoty programistów i zwalonego designu.

Tu się nie zgodzę. Pierwszym ograniczeniem maintenance jest konieczność zachowania spójności poszczególnych elementów. Drugim jest ograniczona ilość narzędzi które można wykorzystać. Trzecim jest przestarzałość. Mówisz, że winna jest głupota programistów. Jednak popatrz na program tak jak oni go widzieli. Z uwzględnieniem narzędzi oraz wiedzy jaką dysponowali. Prowadzę obecnie utrzymanie systemu, który powstał zanim GoF wydał swoją książkę o wzorcach. Założenia systemu do głębokie lata 80te w dodatku przy zupełnie innym systemie prawnym (program to odmiana systemu z Holandii), zatem różnice są dość bolesne. Patrząc na całość mam wrażenie, że pisał to ktoś mocno zjarany. Z drugiej strony mam świadomość, że w tamtych czasach nikomu nie śniło się o dysku 100TB więc zamiast XMLa stosował pliki tekstowe o określonej długości linii i całość była kodowana w EBCDICu.
Obecnie na podstawie tamtego softu piszemy trochę narzędzi do prowadzenia statystyk i nadzoru. Wykorzystujemy współczesne metodyki i zasady. Kod jest znacząco lepszy (co potwierdzają firmowe dziatki), ale jak za 5 czy 10 lat przyjdzie ktoś na nasze miejsce, mając nową wiedzę to będzie klną "jacy to my byliśmy durni, przecież dziś pisze się inaczej". No właśnie "dziś", a nie "wtedy". Maintenance poza umiejętnościami technicznymi wymaga umiejętności archeologicznych i dość dużej wyobraźni.

0

OK faktycznie w Twoim projekcie zwalony kod może wynikać z tego, że powstał w zamierzchłych czasach. Ale czy trzeba mieć więcej wyobraźni niż w przypadku projektowaniu czegoś nowego? Nie wydaje mi się. Nie było wzorców projektowych więc po prostu więcej było machania łopatą niż finezji. IMHO zrozumienie czyjegoś programu to taki brute force - im więcej czasu spędzisz tym bardziej będziesz rozumiał aż w końcu zrozumiesz jak nie w całości to w większości. No chyba że są jakieś wyrafinowane algorytmy.

0

Takie jeszcze małe pytanie:
Co jest łatwiejsze:

  • zrozumieć algorytm na podstawie jego implementacji
  • czy samemu wymyślić algorytm
    ;P
0

Przeczytać dokumentację. Jak takowej soft nie posiada to autora powinno się powiesić (o ile algo nie jest jakieś oczywiste).

0

Ale czy obczajenie algorytmu bez dokumentacji jest naprawde takie trudne? IMHO raczej pracochłonne niż trudne.
Do wymyślenia (porządnego) algorytmu raczej trzeba czegoś więcej.

0

To weź kilka genialnych algorytmów i struktur danych, tych mało znanych a bardzo mocno skomplikowanych - spróbuj tak po prostu zrozumieć dlaczego ten nielogiczny i pozornie bezsensowny hax działa. Zdecydowanie wolę wymyślać algorytmy.

0

To weź kilka genialnych algorytmów i struktur danych, tych mało znanych a bardzo mocno skomplikowanych - spróbuj tak po prostu zrozumieć dlaczego ten nielogiczny i pozornie bezsensowny hax działa. Zdecydowanie wolę wymyślać algorytmy.

Ja też wolę wymyślać algorytmy ale wcale nie dlatego, że są prostsze.

1 użytkowników online, w tym zalogowanych: 0, gości: 1