Czy radzenie sobie ze starszym kodem pomaga ewoluować jako programista? [Zamknięte]

Jestem programistą Java z nieco ponad rokiem doświadczenia, co stawia mnie gdzieś powyżej młodszego, ale jeszcze nie wśród programistów średniego poziomu. Ostatnio zaproponowano mi długoterminowy projekt, który polega na badaniu istniejącego kodu aplikacji bankowej przez 4 miesiące, a następnie wprowadzaniu zmian w razie potrzeby. Jako niezbyt doświadczony programista szukam sposobów rozwoju i zastanawiam się, co może dać taki projekt.

Czy uważasz, że radzenie sobie z dużą i prawdopodobnie niezbyt dobrze napisaną aplikacją jest dobrą praktyką dla początkującego?

Rozwiązywanie problemów z istniejącym kodem to świetny sposób na rozwój jako programista. Jeśli kod jest zły, poznasz wpływ popełnionych błędów i być może unikniesz niektórych z nich podczas projektowania. Jeśli kod jest dobry, dowiesz się czegoś o tworzeniu aplikacji, którą można utrzymać.

Nauczysz się także radzić sobie ze złożonością prawdziwej aplikacji biznesowej. Ponieważ dotyczy to sektora bankowego, poznasz takie kwestie, jak przepisy federalne i wewnętrzne kontrole księgowe, o których być może nawet nie pomyślałeś. To są dobre rzeczy, o których należy wiedzieć, kiedy zostaniesz poproszony o zaprojektowanie czegoś innego w świecie finansów. A programowanie finansowe może być bardzo lukratywnym sektorem do pracy, więc zdobycie doświadczenia bankowego może być dla ciebie bardzo dobre.

Możesz się nawet nauczyć, że tylko dlatego, że coś zostało napisane 15 lat temu, w języku, którego wolisz nie używać, niekoniecznie jest złe. Mimo wszystko działało pomyślnie.

Jeśli, podobnie jak w przypadku większości starszych aplikacji, aplikacja nie ma testów jednostkowych, musisz naprawdę upewnić się, że zmiana nie wpłynie na coś innego, możesz dowiedzieć się, jak dodać te testy i jak sprzedawać zarządzanie, dlaczego dodawanie tych testów jest dobry pomysł.

Myślę, że to doskonała praktyka dla każdego początkującego . Uczenie się na podstawie doświadczeń innych może być bardzo skuteczne.

Prawdziwym wyzwaniem nie jest znalezienie błędów, ale dostanie się do głowy drugiego programisty i próba whyustalenia , że kod został napisany w ten sposób. Czasami dzieje się tak, ponieważ byli niechlujni, a czasem dlatego, że mieli naprawdę dobry powód. Załóżmy, że programista był co najmniej tak dobry jak Ty, ale mógł mieć większą wiedzę na temat domen.

Jest to dobra praktyka dla każdego programisty na dowolnym etapie kariery. Jeśli możesz przejrzeć i przeanalizować istniejące oprogramowanie i znaleźć sposoby na jego ulepszenie, pokażesz, że jesteś cennym programistą. Nauczysz się nie tylko, jak inni zaprojektowali i opracowali oprogramowanie, ale po drodze dowiesz się, czego nie robić, co samo w sobie jest cenną wiedzą.

Jeśli jesteś gotów na wyzwanie, weź ten projekt i popraw go.

To absolutnie ci pomoże, ale musisz być ostrożny.

Musisz upewnić się, że uczysz się ze starszego kodu. Skąd wiesz, co jest dobre, a co złe? Być może potrafisz rozpoznać zalety i wady różnych wzorców / metod, ale jeśli dopiero zaczynasz jako młodszy programista, możesz nie być w stanie.

I pozostań zbyt długo w tej pierwszej pracy, a być może nie będziesz się uczyć lub budować wystarczających umiejętności i ostatecznie utkniesz w tym miejscu.

Dziedzictwo może znaczyć wszystko, ale na podstawie „niezbyt dobrze napisanego” komentarza zakładam, że Dziedzictwo oznacza „złe” lub przynajmniej „nieaktualne” technologie i wzorce. Jeśli starszy kod jest dobry, nie wstrzymuj się i naucz się jego każdego wiersza.

Nie sądzę, aby były wystarczająco jasne ostrzeżenia przed pracą i projektami, które zmieniają twoją karierę i powodują, że utknąłeś w bezwartościowych dziurach w tym wątku.

Alert analogii sportowych: Czy uważasz, że zwolennik linii w NFL uczy się więcej i zyskuje na wartości, grając w drużynie z najgorszymi osiągnięciami lub najlepszymi? Moja odpowiedź: nie tylko są bardziej wartościowi, grając dla najlepszych drużyn, ale prawdopodobnie wybrali najlepsze praktyki i wiedzę oraz uniknęli praktyk i postaw kończących karierę.

Istnieje wiele okropnych kodów anty-wzorcowych, które faktycznie działają dla firmy i wypłacają wiele pensji dla programistów. Proponuję, aby programista, który nie widział wystarczająco dużo kodu wykonanego „we właściwy sposób”, może pomylić kod anty-wzorcowy z uzasadnionym rozwiązaniem problemu. Firma może powiedzieć, że to rozwiązanie działa, ale nie jest to takie, którego chcesz w CV, ani takie, którym możesz pochwalić się innym programistom. Ma to również znaczenie tylko wtedy, gdy twoja osobista ścieżka rozwoju obejmuje zdobycie szacunku wśród inżynierów, a nie tylko tymczasowe zwiększenie dochodu w jakiejkolwiek firmie, dla której pracujesz (Brzmi źle, ale ostatecznie najlepsza inżynieria absolutnie robi najwięcej pieniędzy IMO) .

Niestety, zanim ujawni się dług technologiczny, może upłynąć dużo czasu i dużo czasu. Dług technologiczny jest zwykle rozpoznawany dokładnie wtedy, gdy jest już za późno. Ktokolwiek próbował wcześniej powstrzymać dług technologiczny lub anty-wzorce, mógł zostać odsunięty na bok z powodu postrzeganego dodatkowego kosztu lub braku zrozumienia efektu skalowalności. Naszym obowiązkiem jako inżynierów jest natychmiastowe ujawnienie długu technologicznego. Projekty bez doświadczonych inżynierów są w pewnym momencie zagrożone uderzeniem w ścianę z cegieł, właściwie wszystkie projekty nawet z utalentowanymi twórcami. Większość firm uważa, że ​​„w pewnym momencie” jest dużo czasu, aby to naprawić później. To sprawia, że ​​wybór pracy dla przyszłych deweloperów jest bardzo skomplikowaną sprawą. Wskazuje także na zupełnie inne cele i sposób myślenia programistów i firm oraz na to, jak skomplikowane jest wypełnienie luki.

Celem inżynierów jest „uwzględnienie” prawdziwej pracy naukowej i rozważenie projektu, podczas gdy celem biznesu jest „wykluczenie” niepotrzebnych kosztów i czasu. Ponieważ inżynierowie często nie wiedzą, jaki jest poziom wysiłku i czasu, dopóki stan końcowy nie zostanie faktycznie osiągnięty, tworzenie oprogramowania przebiega jak każdy dobry dramat z postaciami zwinnymi, scrumowymi i kanban odgrywającymi główne role.

Jednym wyjściem może być trzymanie się z dala od złego kodu, dopóki nie zobaczysz wystarczającej ilości dobrego kodu, aby nie zostać „zepsutym”. Uwielbiam powiedzenie, że starsi programiści tworzą proste rozwiązania skomplikowanych problemów. Podobnie mądrzy, młodsi programiści średniego poziomu tworzą kompleksowe rozwiązania prostych i złożonych problemów.

Innym problemem może być to, że musisz pracować nad dobrym ORAZ złym kodem w różnych punktach, aby uzyskać zrozumienie. Jeśli tego nie zrobiłeś, to idź na całość i przygotuj się na oduczenie wszystkiego, gdy znajdziesz lepszy system. Myślę, że jest to prawdopodobnie bardziej powszechna trajektoria dla większości programistów.

W tym roku jestem stronniczy, ponieważ mam wrażenie, że wspinam się na niezwykle skomplikowaną górę „tajnego sosu”. Chociaż zwiększę moją zdolność do rozszyfrowywania niektórych z najgorszych wzorów, jakie kiedykolwiek widziałem, jest to tak „niestandardowe” i „jednorazowe”, że nie wierzę, że moja walka zwiększy moją zbywalność lub umiejętności przydatne w mojej przyszłości.

Aby zachować zdrowie psychiczne, po prostu chodzę w stałym tempie i akceptuję każdy blok drogowy jako normę dla kursu. Po przejrzeniu moich rocznych celów z moim szefem, które obejmują wykopanie tej dziury, myślę, że może to być wspinaczka ofiarna. Mógłbym przetrwać ten proces ze złymi recenzjami i odczuwaną powolnością. To realistyczne i przejmujące ostrzeżenie dla tych, którzy zastanawiają się, jaką pracę podjąć.

Uwaga: Ten post będzie istniał znacznie dłużej niż moje opinie, więc weź go z odrobiną soli. Jutro mogę pokochać starszy kod! (Wątpię).

Bardzo zależy to od tego, jak zdefiniujesz „dziedzictwo” w tym kontekście. Pozwól, że dam ci przykład z C i C ++. Wielu programistów C ++ nazywa używanie złych ciągów C w aplikacjach C ++, inni nie wymagają miksowania, podczas gdy inni z kolei twierdzą, że używanie jakichkolwiek bitów kodu C jest proste i zupełnie bezcelowe, ponieważ są one stare, tj. „ starszy kod. Niektórzy idą dalej i unikają używania wcześniejszych wersji niż C ++ X (zamień „X” na odpowiednią liczbę) standardowe idiomy, styl - czyli składnia, ponieważ jest to „starszy” styl.

Pomijając problemy z wydajnością strumieni i łańcuchów C ++ oraz kilka osobliwości STL, z pewnością dobrą praktyką jest sprawdzenie, co znajduje się w tak ukochanej dyrektywie preprocesora #include <string.h>. Jeśli zastosujemy ścieżkę do realizacji i znaleźć się na maszynie UNIX / Linux na /usr/include/string.h(i dostać libc źródła implementacji, na przykład, od gnu.org ) i czytać strcmp.club strlen.club strtok.c, założę będziesz słyszeć „Jaki piękny świat „wprowadzanie.

Jest jednak zastrzeżenie do tej prozy - mianowicie przestarzałe klasy i metody. W Javie całkiem sporo starszych rzeczy jest nadal dostępnych z najnowszego środowiska, ale jeśli dobrze pamiętam, nie wszystko. Z sektora IB, z własnego doświadczenia wynika, że ​​nie całe oprogramowanie jest napisane przez dobrych programistów. Wielu absolwentów miało praktycznie zerową ekspozycję na programowanie w świecie rzeczywistym, zanim zaczęli pracę na stanowisku analityka / programisty. Ale nie uogólniaj tego stwierdzenia. Znam wielu ludzi, którzy używają Java i C # w rdzeniu środowisk o wysokiej przepustowości i niskim opóźnieniu. Nie zgadzam się z nimi, ale cóż, to na szczęście ich sprawa. Gdyby jednak zrobili prawdziwy HFT, zostaliby zepchnięci daleko w tyle. Ale znowu, łatwo wywnioskować z tego zdania założenie (aw wielu przypadkach fakt), że kod Java jest wysoce optymalizowany. A jeśli potrafisz celować w optymalizacji, jeśli to konieczne, nie tylko naprawiając to czy tamto, stałbyś się bezcenny jako twórca. Bardzo satysfakcjonujące jest uświadomienie sobie, ile włożyłeś w to. Wybrałbym to.