Witam.
Po wczorajszym dniu w pracy zastanawiam się czy nie zmienić roboty. Skłania mnie do tego totalnie zwalony projekt, w którym biorę udział. Projekt jest już pisany ponad 20 lat, 90% ludzi, którzy go pisali dawno temu odeszła z firmy. Dokumentacja systemu jest szczątkowa, komentarzy w kodzie brak, Moduł nad którym pracuje to 3/4 kodu to jakieś haki, robione tak, żeby to w ogóle działało. Pisanie czegoś nowego to jak poruszanie się po polu minowym. Do tego dochodzą różne ograniczenia - np z pewnych powodów nie mogę korzystać z powszechnie dostępnych bibliotek czy frameworków.
I tak mnie zastanawia, czy w każdy duży projekt jest tak totalnie zlamerzony czy tylko źle trafiłem?
Bo jeśli źle trafiłem to poważnie zastanowie się nad zmianą pracy.
Szczerze : jeśli odpowiadają ci warunki finansowe i atmosfera w firmie, to nie warto zmieniać pracy tylko z uwagi na "warunki techniczne". Nigdy nie będzie tak jakbyś chciał w 100% (oczywiste jest, że jeżeli 20 programistów pisze coś, każdy stosuje inne techniki, inne nazewnictwo, inne formatowanie...). Nigdy więc projekt nie będzie w 100% taki jakbyś chciał.
Hm... ciekawy projekt. W czym piszecie?
Co do problemu, jeżeli pasują ci ludzie i kasa to nie warto odchodzić. Jeżeli jednak, jak piszesz, jest duzy opór materii kierowniczej w kwestii udoskonalania produktu, to warto się zastanowić czy nie pójść w diabły.
ps. Projekt mnie ciekawi bo sam ma na koncie kilka ciekawych migracji z różnych starych zabawek.
Mam tak samo. Czasami tez mam ochote wstac zza tego biurka i po prostu se pojsc w diably ale zwykle konczy sie to tak ze ze wentyluje sie rzucajac miesem w moich 'wspolpracownikow' z Bangalore i kierownika. Ogolnie atmosfera w pracy mi pasuje (po poprzedniej pracy czuje sie tu jak na wczasach), kasa tez pasuje a sekretarki sa fajne ;). Z drugiej jednak strony ciagle przegladam oferty pracy i jesli znajde cos nowego/ciekawego/dobrze platnego to nie zawacham sie powiedziec adieu.
Napisz nowy od zera po swojemu :D
Wbrew pozorom czasem taki kompletny rewrite ma sens.
Ja miałem kiedyś tak, że dostałem w spadku taki projekt pisany przez szefa firmy i jednego studenta. Ogólnie był niezła masakra, po 2 kolejnych próbach poprawienia kodu, żeby wreszcie działał stabilnie w końcu siadłem i w 2 tygodnie przepisałem to od zera mówiąc wcześniej kierownictwu, że robię tylko drobny refactoring i poprawki, i że oczywiście cały wartościowy kod przeniosę do nowej wersji. No i nie przeniosłem ani linijki... :D
Hehe, u mnie tez po czesci jest podobnie. Miesiac temu system do ktorego pisze rozszerzenia obchodzil swoje 30sto lecie... i na dzisiejsze standardy jest to jedno wielkie mega G.
Co najwazniejsze w takim przypadku... nie stresowac sie i nie robic zbednych nadgodzin, nawet gdy wiekszosci nie rozumiesz. Tez mialem ochote rzucic takie cos w cholere (mimo dobrych warunkow finansowych) ale dostalem taką oto złotą rade:
O ile dobrze placa, to nie wazne jakie gowno im robisz... to i tak pozostanie ich gownem na długo po tym jak Cie tam juz nie bedzie, a do tego czasu nachapaj sie tyle ile sie da :)
Dodane
Krolik: niestety to sie sprawdza przy projektach rocznych / dwu rocznych... sa pewne systemy tak duze, ze np ten moj to grupa programistow by przepisywala z pare lat. By zilustrowac obraz tego: sama baza danych - kilkaset tabel, kazda po kilkadziesiat kolumn kazda...
Raczej czeste, zazwyczaj projekt nad ktorym pracowalem byl w spadku. Albo na poczatku mial byc tymczasowo (wiec po co projekt :) ) jednak potem sie rozwijal i dolepialo sie do niego czesci. Z przepisaniem to najlepsze rozwiazanie ale zawsze powstaje pytanie kto za to zaplaci. Wiec podstawowym wyznacznikiem jest dziala. Ale istotnie czlowiek czasami traci chec robienia czegokolwiek (przez co sam czasami generuje G.) no ale takie zycie ... tyczy sie to chyba wszytskich dziedzin (kompromis czas/pieniadze/jakosc).
Krolik - moduł przy którym jest pracuje ma 100k linnijek kodu a takich modułów jest w cholere i jeszcze trochę. Do tego różne warstwy są pisane w różnych językach: od asma po Javę aż do języka specjalnie stworzonego dla tego serwisu. Tak więc przepisanie tego jest praktycznie niemożliwe.
Koziołek - niestety nie mogę mówić co to za projekt, bo w Polsce tego typu soft pisze tylko jedna firma.
Ja biore udzial w 5-letnim projekcie, tez stara technologia i tez mocno namieszane. Za to kierownictwo otwarte na wszelkie sensowne proby robienia czegos lepiej, chocby mialo to dotyczyc tylko nowych rzeczy. Ja sie odnajduje w poszukiwaniu sposobow ulepszenia, bo i wyzwanie wieksze niz naklepanie/wyklikanie kodu w jakims frameworku czy RAD :) To moze byc cokolwiek - unit testy, inna metodologia rozwiazywania bledow, automatyzacja niektorych procesow tworzenia/sprawdzania, itp. Byle w efekcie otrzymywac lepszy kod czy tez narzedzie gwarantujace, ze kod bedzie jasniejszy czy bedzie mial mniej bledow.
//edit
W sumie to sa 2 niezaprzeczalne plusy (dla niektorych to minusy) takiego projektu:
- nietrywialnosc prawie kazdego rozwiazania - rozszerza horyzonty i pozwala patrzec inaczej na znane problemy nierozwiazywalne podrecznikowymi sposobami
- zdecydowany brak nudy :D
Pracowałem też z takimi gównianymi projektami, rozwijanymi XX lat przez XX programistów, gdzie wprowadzenie zmiany w kodzie można było porównać (jak już ktoś trafnie zauważył) do chodzenia po polu minowym. Powiem szczerze, że żałuję każdej godziny spędzonej nad tymi projektami. To była droga przez mękę, a zamiast rozwoju było uczenie się przestarzałych technologii, nieużywanych już nigdzie narzędzi i niewydajnych metod pracy.
Nie życzę nikomu pracy w takich warunkach. Na szczęście są też normalne firmy, gdzie liczy się jakość kodu oraz pracuje się z wykorzystaniem co raz to nowszych technologii i narzędzi.
AdamPL napisał(a)
zamiast rozwoju było uczenie się przestarzałych technologii, nieużywanych już nigdzie narzędzi i niewydajnych metod pracy.
Ja robie to w druga strone, staram sie reformowac, ulepszac, czasami mowie stanowcze NIE itd itp. Jest to zauwazane przez przelozonych i wspolpracownikow i owocuje.
EgonOlsen napisał(a)
Jest to zauwazane przez przelozonych i wspolpracownikow i owocuje.
byle nie zwolnieniem ;)
Pracowałem też z takimi gównianymi projektami, rozwijanymi XX lat przez XX programistów, gdzie wprowadzenie zmiany w kodzie można było porównać (jak już ktoś trafnie zauważył) do chodzenia po polu minowym. Powiem szczerze, że żałuję każdej godziny spędzonej nad tymi projektami. To była droga przez mękę, a zamiast rozwoju było uczenie się przestarzałych technologii, nieużywanych już nigdzie narzędzi i niewydajnych metod pracy.
Mam podobne wrażenie jak AdamPL: wątpie żeby siedzenie w starej technologii czegoś uczyło. Nowe technologie rozwiązują stare problemy więc czego tak naprawde miało by to uczyć?
Gdyby nie to że atmosfera jest fajna w pracy i zarobki są ok to w ogóle bym się nie zastanawiał tylko zmieniał pracę.
AdamPL napisał(a)
To była droga przez mękę, a zamiast rozwoju było uczenie się przestarzałych technologii, nieużywanych już nigdzie narzędzi i niewydajnych metod pracy.
Nie życzę nikomu pracy w takich warunkach. Na szczęście są też normalne firmy, gdzie liczy się jakość kodu oraz pracuje się z wykorzystaniem co raz to nowszych technologii i narzędzi.
Wybacz, ale bzdura jednym slowem. Przestarzale technologie kiedys nie byly przestarzale i dalej sa dobre. Te dzisiaj dobre za X lat tez beda przestarzale i nagle przestana byc dobre? IMO sztuka bycia programista to sztuka dostosowania sie do warunkow. Nie da sie czegos zrobic, zeby zachowac jakosc? To wymysl cos, zeby sie dalo.
W takich projektach jakosc kodu wychodzi wlasnie najlepiej. Nietrudno jest dbac o jakosc jak projekt ma 3 miesiace i powstalo raptem 100 klas. O jakosci tego projektu swiadczy fakt, ze po 10 latach nadal dziala i nadal da sie go czytac. Nie da sie czytac i poprawiac, bo ktos skopal? Popraw, a wplyniesz na poprawe jakosci. Marudzeniem i malkontenctwem na pewno sie tego nie zrobi.
Zmiana technologii co chwile, 'bo wyszla nowa super ekstra sliczna' nie jest takie latwe, jak masz tysiace uzytkownikow, ktorzy musza cos doinstalowac, bo ta technologia tego wymaga. Bo musisz zagwarantowac, ze nowa wersja w pelni pokrywa stara. Bo musisz zadbac, zeby w okresie przejscia dzialaly obydwie. Bo musisz przez jakich okres rozwijac obydwie wersje (a to tylko jedno przejscie). Bo ktos jeszcze musi za to zaplacic, a chetnych zwykle brak. I cala gadka o nowych, swietnych technologiach juz nie jest taka latwa.
Ostatnio jakiś koleś mnie przekonywał, że Clipper jest świetnym narzędziem i można w nim robić taaaaaaakie rzeczy... Mnie niestety nie przekonał ;)
No to sie dogadalismy. Ja wiem, ze .NET jest lepsze od MFC (na tym ostatnio pracuje). Ale co ma zrobic firma, jesli chce rozwijac produkt, ale koszty przejscia sa za wysokie? Nic, musi sobie dzialac dalej. A jak programisci beda tylko narzekac i czekac na cuda i liczyc, ze wszystko sie samo zrobi, to tez daleko nie zajda.
wątpie żeby siedzenie w starej technologii czegoś uczyło. Nowe technologie rozwiązują stare problemy więc czego tak naprawde miało by to uczyć?
Myślenia uczy. Uczy jak sobie radzić w mniej typowych sytuacjach. Jak sobie poradzisz w 'egzotycznych' warunkach to wszędzie sobie poradzisz.
IMO pracując nad "spadkowym" projektem, można dostrzec też plusy. Krok po kroku tam gdzie to możliwe warto stosować rozwiązania rozszerzalne/uniwersalne/mające jakiś wspólny mianownik. Po pewnym okresie (nie od razu), okazuje się że pewna zmiana która do tej pory była bardzo gówniana (pole minowe) jest bardzo prosta. Innymi słowy procentuje wkład poczyniony kiedyś kiedyś tam. Z biegiem czasu można większą część projektu wyprowadzić na prostą. Oczywiście nie zawsze, ale można próbować. Wiadomo że przy większych rzeczach proces jest trudniejszy/powolniejszy - ale wyzwania w pracy dają pewną satysfakcję.
b