Czy macie może wskazówki odnośnie pracy z cudzym/obcym kodem, pierwszy kontakt z nieznanym Wam projektem, kawałkiem kodu itp.
Czasem może i nawet jest to zły kod.
Macie jakieś wskazówki odnośnie pracy z cudzym kodem?
0
0
Używać debugera :) W pracy rzadko kiedy pracujesz tylko i wyłącznie na swoim kodzie.
2
Macie jakieś wskazówki odnośnie pracy z cudzym kodem?
Ale co z tym kodem robisz: rozwijasz czy naprawiasz bugi?
Zdefiniuj "pracę z kodem".
To drugie (poprawki) jest mało ambitne ale łatwiejsze, bo ani nie trzeba kodu specjalnie rozumieć (w sensie "globalnym"), ani nie trzeba płakać nad tym, jak lipny to kod jest (działa - nie ruszać).
0
Czy macie może wskazówki odnośnie pracy z cudzym/obcym kodem, pierwszy kontakt z nieznanym Wam projektem, kawałkiem kodu itp.
Czasem może i nawet jest to zły kod.Macie jakieś wskazówki odnośnie pracy z cudzym kodem?
Dużo pytać innych pracowników. Refaktoryzować. Poszukać narzędzi do analizy kodu (nie wiem w czym programujesz, ale jeśli w jakiejś Javie, C# czy C++ to ci zazdroszczę o tyle, że w tych językach chyba najłatwiej o narzędzia do konkretnej analizy), ew. stworzyć własne skrypty wyciągające pewne informacje z plików (choćby zależności między modułami).
1
może także pomóc pisanie testów tworzonego oprogramowania - unit test
0
Tak jak @Azarien wspomniał: debugger :D bo jak wiadomo dokumentacja to rzecz która powinna być zawsze - czyli nie ma jej nigdy ^^ Intellij + jego evaluate expression i praca z istniejącym kodem jest o wiele przyjemniejsze.
0
Azarien napisał(a):
Macie jakieś wskazówki odnośnie pracy z cudzym kodem?
Ale co z tym kodem robisz: rozwijasz czy naprawiasz bugi?
Zdefiniuj "pracę z kodem".To drugie (poprawki) jest mało ambitne ale łatwiejsze, bo ani nie trzeba kodu specjalnie rozumieć (w sensie "globalnym"), ani nie trzeba płakać nad tym, jak lipny to kod jest (działa - nie ruszać).
W zasadzie wszystko, rozwinąć, poprawić, dopisać testy. Dokumentacji jeszcze nie uświadczyłem... ale od niedawna pracuje. Najgorzej jesli trzeba znac dzialanie calosci.
Ostatnio cos poprawialem, na poczatku sie wywalalo, konsola malo mi podpowiedziala, ale zaczalem szukac jakis constraints w appce i w koncu znalazlem.
Pozniej to appka ma testy popisane, do tego co zmienilem dopisalem swoj case... zapuszczam wszystkie testy, dzialaja... włączam appke na localhost... nie dziala.
Pewnie za malo obszerne testy...
0
Bardzo duży system napisany w Perlu, wszystko zależne od wszystkiego, zależności poukrywane, brak testów jednostkowych testy funkcjonalne trwające cały dzień. Każde wdrożenie na produkcję nawet najmniejszej poprawki to garść włosów mniej na głowie. Co zrobić trzeba sobie jakoś dawać radę :).
0
Co prawda nie siedziałem nigdy w Perlu, natomiast widziałem podobne szambo w pythonie, DELPHI, czy też C++. Refaktor wielu tys. linii kodu jeśli nie milionów jest po prostu nieopłacalny (który szef na to pójdzie??) więc musisz jakoś poruszać się w tym bagnie. Zastanawiam się też czy tego typu zabiegi nie są przypadkiem nawet celowo robione przez programistów...
2
Ja bym powiedział, że refaktoring jest trudny, ale jeśli system ma działać dłużej jest opłacalny. Należy robić go etapami, aby nie zaburzać za bardzo rozwoju całości i by był używalny dla końcowego użyszkodnika.
0
kaczus napisał(a):
Ja bym powiedział, że refaktoring jest trudny, ale jeśli system ma działać dłużej jest opłacalny. Należy robić go etapami, aby nie zaburzać za bardzo rozwoju całości i by był używalny dla końcowego użyszkodnika.
Problem polega na tym, że rozgryzienie tego co się dzieje w kodzie może zająć naprawdę sporo czasu a w najgorszych przypadkach jest to wręcz niemożliwe. I tu jest kwestia skalkulowania, bo jest przecież opcja że rozważasz decyzję przepisać to całkowicie od nowa. Nie ma większych problemów jak to jest dla przykładu jakaś mała aplikacja desktopowa czy tam webowa, to tu mógłbym powiedzieć że opłaca się bardziej niż próba poprawiania czegoś a już tym bardziej późniejsza rozbudowa.
1
stosunkowo czesto musze naprawic cos w systemie ktorego nie znam.
staram sie wtedy wydzielic jak najmniejszy logiczny fragment nad ktorym bede pracowac, nastepnie robie jego gruntowny refaktoring i pare unit testow, robiac git commita przy kazdym 'logicznym' kroku. sprawdzam czy dziala, w razie potrzeby cofam sie w historii.
swoja droga - mysle przepisanie od nowa dzialajacego, duzego projektu jest jedna z glupszych decyzji jakie mozna podjac, chyba ze robi sie to hobbystycznie.
0
katelx napisał(a):
swoja droga - mysle przepisanie od nowa dzialajacego, duzego projektu jest jedna z glupszych decyzji jakie mozna podjac, chyba ze robi sie to hobbystycznie.
No dobra, weźmy taką sytuację. Próbujesz rozgryzać jakiś duży projekt, w którym to jest np. pomieszanie polskich nazw z angielskimi, nie wiadomo jak ponazywane metody i zmienne, ogólnie kod dość skomplikowany, dużo zależności itd. Przecież to jest normalnie tragedia. Co wtedy zrobisz? Jak dużo czasu minie zanim dojdziesz za co odpowiada konkretna część?
Jasne że szefostwo nie zdecyduje się na tak drastyczne (i niestety kosztowne) kroki jak przepisanie projektu od nowa. Jeszcze do zrozumienia jest to jeśli kod jest napisany w miarę należycie i dobrze zorganizowany, wówczas stosunkowo łatwo dojść co i gdzie się dzieje. Ale i na to potrzeba ileś tam czasu.
1
w takim wypadku trzeba krok po kroku eliminowac zaleznosci i poprawiac jakosc kodu.
6
@fasadin, pozwole sobie odpowiedziec w poscie a nie komentarzu :)
jesli system to jest cos co przezylo pare teamow programistow (i architektow...), ma mase zaleznosci z innymi systemami, jest uzywane 'wszedzie' i przynosi firmie zyski. to nie ma szans zeby przepisanie dalo jakikolwiek pozytywny efekt, poza szczesciem programistow, przynajmniej poki nikt nie zacznie tego nowego systemu uzywac i narzekac ze stary byl lepszy.
nie ma projektu z ktorym pracuje, ktorego nie chcialabym przepisac ale zdaje sobie sprawe ze to jest tak ze na poczatku bawisz sie swietnie, architektura jest taka ze serce rosnie, wydajnosc 10x lepsza a interfejs mniej szary.
potem jednak uzytkownicy zaczynaja grzebac i pare rzeczy trzeba zmienic bo
a) w starym zawsze brakowalo mi ...
b) w starym bardzo lubilem ... a tu tego nie ma
c) skoro juz to robisz to moze ...
d) trzeba to zintegrowac z ...
e) fajnie to idzie, zatrudnijmy jeszcze 50 ludzi co nie maja o niczym pojecia zeby to rozwijali
f) zatrudnijmy architektow i analitykow :)
i w pewnym momencie konczy sie na podobnym bagnie jak wczesniej.
1
drorat1 napisał(a):
No dobra, weźmy taką sytuację. Próbujesz rozgryzać jakiś duży projekt, w którym to jest np. pomieszanie polskich nazw z angielskimi, nie wiadomo jak ponazywane metody i zmienne, ogólnie kod dość skomplikowany, dużo zależności itd. Przecież to jest normalnie tragedia. Co wtedy zrobisz? Jak dużo czasu minie zanim dojdziesz za co odpowiada konkretna część?
W takiej sytuacji dokonałbym następujących kroków:
- Zapytałbym zespołu, czy mają kilka minut, aby pogadać o projekcie.
- Stwierdziłbym, że mieszanie nazw polskich z angielskimi jest słabe i podał argumenty.
- Dążyłbym do tego, aby wszyscy zgodzili się na stosowanie tylko angielskiego nazewnictwa.
- Wspólnie ustalilibyśmy, że od teraz używamy tylko angielskiego nazewnictwa. W miarę możliwości zapisałbym tę zasadę w projektowej wiki.
- Podczas pracy z kodem wszyscy byliby zobligowani do tego, aby stopniowo zmieniać nazwy z polskich na angielskie zgodnie z Boy Scout Rule.
- Gdy ktoś nie zastosuje się do reguł, jest mu zwracana uwaga podczas Code Review i ta osoba powinna poprawić fragment, nad którym pracuje.
Praca z cudzym kodem lub bardziej fachowo mówiąc kodem odziedziczonym (legacy code), to normalna sprawa.
Elementy, które wg mnie mogą ułatwić pracę z takim kodem:
- Git, Git Flow i praca na osobnych branchach.
- Rozmowa z osobami, które dłużej są w projekcie i zadawanie pytań.
- Pair programming.
- Debugger.
- Unit testy - używanie istniejących, jeśli są i pisanie nowych w szczególności, gdy naprawiamy błąd, aby uniknąć regresji.
- Korzystanie z dokumentacji, jeśli jest oraz aktualizacja i uzupełnianie dokumentacji, jeśli jest taka potrzeba.
- Poprawianie kodu i refaktoring w miarę możliwości, jeśli zauważymy, że coś może być zrobione lepiej.
- Jeśli widzimy możliwość wprowadzenia większych zmian, to rozmawiamy z zespołem, robimy ustalenia i wprowadzamy zmiany.
- Automatyzacja wszystkiego, co da się zautomatyzować.
0
Zły kod to pojęcie względne... Ostatnimi czasy pracuję nad kodem który był pisany przeszło 10 lat temu, potem rozwijany z powierzchowną dokumentacją oraz niewielką ilością testów. Generalnie koszmar. Aktualnie utrzymujemy go bo nie mamy wyjścia ale trwają rozmowy żeby rozpocząć powoli przepisywać część systemu z wykorzystaniem nowszych technologii i przede wszystkim z dodatkiem dokładnych testów oraz dokumentacji...
Jeśli już muszę pracować to zależy od zadania jakie mam do wykonania... Na pewno jak ktoś wcześniej pisał wydzielam fragmenty kodu nad którymi będę pracował. Później powolny proces edycji + bardzo częste debugowanie.
Zanim jednak w ogóle przystąpię do edycji staram się wyciągnąć jak najwięcej informacji od pracowników z dłuższym doświadczeniem którzy częściowo pisali ten kod...
A najlepsze są w tym wszystkim fragmenty kodu które są tak ch...we że aż chce się je w całości usunąć albo poprawić... Ale ten strach kiedy widzi się że klasa była pisana np. w 2007 r i może się wszystko schrzanić powoli uspokaja emocje i po prostu zamyka się ten plik ;)