Hej,
Nie dawno zmieniłem pracę i na start dostałem do częściowego przepisania (zaopiekowania się) legacy code... kod strasznie zły, zaniedbany ze złymi praktykami. Wstępnie mam się tym nie zajmować, ale odnoszę wrażenie, że to dobrze nie wróży. Może za bardzo panikuje, ale liczyłem na "dobrą zmianę"?. Troszkę się czuje zawiedziony.. Dodam, że to jest okres próbny w nowej pracy.
witamy w prawdziwym swiecie - matrixa - neo.
Znaczy... Masz konkretne wymagania - bo kod działa - i masz to przepisać w czymś nowym i to jest dla ciebie problem?
Programmer napisał(a):
Hej,
Nie dawno zmieniłem pracę i na start dostałem do częściowego przepisania (zaopiekowania się) legacy code... kod strasznie zły, zaniedbany ze złymi praktykami. Wstępnie mam się tym nie zajmować, ale odnoszę wrażenie, że to dobrze nie wróży. Może za bardzo panikuje, ale liczyłem na "dobrą zmianę"?. Troszkę się czuje zawiedziony.. Dodam, że to jest okres próbny w nowej pracy.
a co w tym złego?
Wiekszosc kodu to kod legacy. Znany Jarek od 20 lat siedzi w legacy i zobacz na kogo wyrosl. Legacy to szkola zycia developera :)
Legacy to szkola zycia developera :)
Oczywiście pod warunkiem, że to legacy się stopniowo rozpruje i ucywilizuje :] Inaczej będziemy mieć cierpienia młodego Wertera.
Doprowadzenie legacy do uzywalnosci to ciekawe zadanie. Gorzej jesli nic sie z tym nie robi.
wartek01 napisał(a):
Znaczy... Masz konkretne wymagania - bo kod działa - i masz to przepisać w czymś nowym i to jest dla ciebie problem?
To że kod działa nie oznacza że są jakieś konkretne wymagania - na przykład kiedyś trafiłem w takim trupku którego trzymaliśmy niczym ruscy lenina na serwis w którym obiekt był modyfikowany w logice, przy odczycie z bazy danych i przy renderowaniu widoku (regexpem zamieniali coś w jebutnym kawałku xmla, nikt nie wiedział czemu). Nawet jakbyś chciał to sensownie napisać to nie ma tego jak podzielić na funkcjonalności ani nie ma jak sensownie nazwać testów.
No i to jest konkretne wyzwanie. Jeśli uda cię się wyprostować tą część kodu to nie tylko sporo się przy tym nauczysz (na cudzych błędach), ale i będziesz miał czym zaimponować na rozmowie kwalifikacyjnej u potencjalnego kolejnego pracodawcy. Zdolność odkręcania szajsu zawsze będzie w cenie.
Oczywiście sporo zależy też od języka i charakteru projektów w których się pracuje. Java jest świetnym językiem do refaktorowania, bo są zarówno solidne narzędzia do tego jak i wieloletnie programy w Javie, które jest sens utrzymywać i rozwijać. Jeżeli jednak pracujemy nad projektem, który ma być utrzymywany przy życiu tylko do czasu zastąpienia go czymś zupełnie nowym (hmm, siedzimy np w COBOLu) to nawet nie będzie specjalnie okazji do szlifowania umiejętności.
Troszkę się czuje zawiedziony..
W mojej pierwszej pracy (w Comarchu) byłem bardzo zawiedziony. "Life is brutal" jak mawia pewne powiedzenie.
najgorzej to jest jak się przepisuje średnio-legacy bo założenia są że kod będzie super, ale potem na coraz późniejszych etapach powstaje też troszkę legacy... ;D (chodź mniejszy niż poprzedni i tylko w niektórych obszarach)
Przeczytałem pytanie i... hej, no zaraz! Chyba jedyna sytuacja, kiedy nie masz do czynienia z legacy kodem, to startowanie projektu od zera w firmie, która startuje od zera. W każdej innej firmie się z nim zetkniesz, właśnie przez to, że firma już istnieje i programiści, którzy byli przed Tobą, coś tam napisali.
Bardziej bym zwracał uwagę na inny aspekt: jest ten kod "legacy", są programiści, którzy na niego narzekają... i wszyscy mają to w poważaniu. To znaczy: kiedy przychodzi do napisania czegoś nowego, to popełniane są te same błędy, a jakakolwiek próba wprowadzenia bardziej cywilizowanych standardów kończy się... narzekaniem. Wtedy powinna się zapalić lampka ostrzegawcza, bo to oznacza, że w danym projekcie za stan kodu odpowiada podejście ludzi.
Jeśli firma wprost dała Ci zadanie częściowego przepisania kodu legacy, ze złymi praktykami, to jest to wręcz dobry znak, że chyba im jednak zależy. Sam jestem liderem zespołu, gdzie mamy trochę kodu legacy i ekipę, która jest odpowiedzialna, chce rozwijać swoje umiejętności i której zależy, by to jednak doprowadzić do ładu. I z takimi ludźmi jest to tylko kwestia czasu, aż tego dokonamy. A umiejętności do przeprowadzenia tego zadania też zdobywałem na kodzie legacy, który dostałem kiedyś pod opiekę, i który udało mi się wyprowadzić na prostą.
Zabawne jest to, że ludzie pchają się do tego zawodu kompletnie nie maja pojęcia na jakie g.... natrafią w swojej karierze.
Autorze nawet sobie nie wyobrażasz jak ja Cie rozumiem. W piątek zastanawiałam się jak przepisać sensownie 6-7 razy zagniezdzony if. Kod pisany przez juniora, w dodatku po kursach. Jak nie miałam jakis uprzedzeń odnośnie ludzi po kursach tak zaczelam miec. Mam tylko nadzieje ze po audycie nie będę tego przepisywać. Wisienka na torcie jest fakt ze chca pozyskać autora tej szmiry z powrotem. Mam tylko nadzieję ze nauczył sie chociaż zabezpieczac kod i nie robic dziur.
"Naprawiać coś co działa" to poważny błąd :-) Jak nie masz wyraźnego zadania, żeby ten kod poprawić, to nie ruszaj. To, że spotykasz się w różnych miejscach z kodem różnej jakości to normalna sprawa.
Wielu tutaj pisze, że praca z legacy jest ciekawa i wyprostowanie kiepskiego kodu to jest coś czym można się pochwalić. Zgodzę się z tym w pełni i faktycznie jest to ciekawe zadanie, ale też droga przez mękę, bo w tych najgorszych to w każdej warstwie aplikacji gdzieś jest logika, oczywiście bez testów. Tylko rozumiem autora, nic nie napisał o sobie, ale jeżeli to jest junior i to jest jego druga praca, to IMHO lepiej jest pracować z nowym kodem, z dobrymi ludźmi od których się dużo nauczy, bo jak teraz ktoś go wrzuci w legacy to może sobie nie poradzić z naprostowaniem tego.
Wszystko zależy od firmy, jej podejścia i potrzeb.
Jeśli jest to kod, który działa dobrze, ale jest słabo napisany to lepiej nie ruszać jeśli nie trzeba.
Kiepsko jest kiedy trzeba a ma się na to mało czasu, to może oznaczać że firmie nie zależy na dobrym utrzymaniu tego programu. To już polityka firmy, jej biznes.
Przepisanie całego kodu legacy to trudny i długotrwały proces, dlatego często się to robi stopniowo pod czas pracy nad innymi zmianami, które akurat dotykają tego miejsca.
Dobrą wstępną zasadą jest zasada zwana "boy scout rule" przez Roberta Martina: https://martinfowler.com/bliki/OpportunisticRefactoring.html (Martin Fowler wspomina o tej nazwie w tym artykule)
Jeśli dostajesz zdanie w dużym projekcie to najpierw musisz zdobyć trochę wiedzy do wykonania tego zadania. Ta wiedza jest potrzebna do zmian w odpowiednich klasach, by skompletować funkcjonalność. Jednak skoro już masz wiedzę na temat tych klas to ta przyda się też przy ich refaktorowaniu i dorzucaniu brakujących testów.
Byłbym ostrożny przy ocenianiu jakości kodu na początku kariery programisty komercyjnego. Jeśli ktoś ciągle szlifuje swoje umiejętności programistyczne to po kilku latach praktykowania zawodu sam uzna swój kod z początków kariery za legacy nadający się do gruntownego przeorania. Doświadczenia nie zdobywa się czytając książki czy robiąc zadania na zaliczenie (albo inne hello worldy z tutoriali). Doświadczenie zdobywa się rozwiązując zadania z którymi mamy pod górkę i musimy przez nie przebrnąć - a na takie natrafiamy w pracy.
hcubyc napisał(a):
Wielu tutaj pisze, że praca z legacy jest ciekawa i wyprostowanie kiepskiego kodu to jest coś czym można się pochwalić. Zgodzę się z tym w pełni i faktycznie jest to ciekawe zadanie, ale też droga przez mękę, bo w tych najgorszych to w każdej warstwie aplikacji gdzieś jest logika, oczywiście bez testów. Tylko rozumiem autora, nic nie napisał o sobie, ale jeżeli to jest junior i to jest jego druga praca, to IMHO lepiej jest pracować z nowym kodem, z dobrymi ludźmi od których się dużo nauczy, bo jak teraz ktoś go wrzuci w legacy to może sobie nie poradzić z naprostowaniem tego.
bo zazwyczaj praca z legacy... to pozostanie w tym legacy na wieki.
Podsumujmy:
Jeśli wszystkie te warunki są spełnione, to sytuacja jest idealna - dostałeś wspaniałą okazję, aby się wykazać. Jeśli któreś nie są spełnione, to które?
zarazek napisał(a):
Podsumujmy:
- kod jest kiepski
- wiesz co w nim jest nie tak
- potrafisz to naprawić
- dostałeś zielone światło na to zadanie
- da się to zrobić w rozsądnych ramach czasowych
Jeśli wszystkie te warunki są spełnione, to sytuacja jest idealna - dostałeś wspaniałą okazję, aby się wykazać. Jeśli któreś nie są spełnione, to które?
Mysle, ze najpredzej nie ma zielonego swiatla na to ;)
Zlej debili, niech sami lepią co porzeźbili, Może się czegoś nauczą geniusze informatyki.
Jak chcesz pracowac z kodem juz napisanym to polecam Linux kernel i opensource generalnie. To ma jakość. Kod aplikacji firm nawety miedzynarodowych korporacji to wymiot informatyczny, kierowany przez polityków firmowych.