Czy moje negatywne doświadczenia z praktyk reprezentują rzeczywisty świat? [Zamknięte]

Jestem ciekawy, czy moje obecne doświadczenia jako stażysty są reprezentatywne dla rzeczywistej branży.

Jako tło przeszedłem przez większą część dwóch kierunków komputerowych i matematyki na dużym uniwersytecie; Pokonałem wszystkie klasy i uwielbiałem wszystkie, więc chciałbym myśleć, że nie jestem okropny w programowaniu. Otrzymałem staż w jednej z największych firm programistycznych i w połowie byłem zszokowany wyjątkowo niską jakością kodu. Komentarze nie istnieją, to wszystko kod spaghetti, a wszystko, co może być złe, jest jeszcze gorsze. Zrobiłem mnóstwo korepetycji / TAing, więc jestem bardzo przyzwyczajony do czytania złego kodu, ale najważniejsze produkty branżowe, które widziałem, przebiły to wszystko. Pracuję 10-12 godzin dziennie i nigdy nie czuję, że nigdzie się dostaję, ponieważ „ niekończące się godziny prób znalezienia nieudokumentowanego API lub ustalenia zachowania jakiejś innej części (całkowicie nieudokumentowanego) produktu. Do tej pory codziennie nienawidziłem pracy i desperacko chcę wiedzieć, czy to właśnie czeka mnie do końca życia.

Czy zwróciłem uwagę na staże (absurdalnie duże wypłaty sugerują, że nie jest to pozycja niskiej jakości), czy też taki jest prawdziwy świat?

Nie bez powodu nazywają to Real World ™.

99% tego, co napotkasz w prawdziwym świecie korporacyjnym, będzie uważane za gówno i nie bez powodu to wyjaśnię. 1%, który nie jest uważany za badziewia, w końcu stanie się badziewiem.

# 1 Napisz kod, # 2 ????, # 3 Zysk!

Po pierwsze, istnieją firmy, które przynoszą zysk, nie istnieją, aby generować góry o idealnie teoretycznie czystym, zaprojektowanym i nieskazitelnym kodeksie akademickim, mieszczącym się w złotych repozytoriach doskonałości. Nawet blisko, nawet tych zajmujących się sprzedażą kodu źródłowego, który produkują.

W świecie biznesu kod jest środkiem do celu . Jeśli jakiś kod rozwiązuje problem biznesowy i zarabia więcej niż kosztuje jego utworzenie i utrzymanie, jest to pożądane dla firmy. Zatrudnianie Ciebie do pisania kodu to tylko jeden ze sposobów uzyskania kodu przez firmę.

Teoria 0 - Ćwicz ∞

Idealna konserwacja powinna być większym problemem, ale zwykle nie jest, ponieważ w krótkim okresie nie wygrywa finansowo. W dłuższej perspektywie oprogramowanie zwykle ma stosunkowo krótki cykl życia, zwłaszcza aplikacje internetowe, szybko się dezaktualizują i częściej zapisują.

Wewnętrzne aplikacje biznesowe to te, które są postrzegane jako niekończące się projekty zombie z wielu powodów opartych na pędu. Projekty te są w rzeczywistości sukcesami, które kontynuują, ponieważ nadal przynoszą firmie zysk.

Teoretycznie nie ma różnicy między teorią a praktyką. W praktyce jest. - Yogi Berra

Teoretycznie idealnie zaprojektowane absolutnie czyste, nieskazitelne bazy kodu ze 100% pokryciem kodu powinny zaoszczędzić pieniądze firmom, w praktyce nie jest nawet bliskie dostarczenia rzeczy zbliżonej do prawidłowego zwrotu z inwestycji.

Fizyka cyklu życia oprogramowania

W świecie oprogramowania działa również bardzo potężna siła entropii. Jest to czarna dziura nieuchronności, która skazuje wszystkie programy na degenerację w Wielką Kulę Błota .

Im dalej zaczniesz od BBM, tym lepiej, ale każdy system oprogramowania w końcu się tam dostanie, mając wystarczająco dużo czasu. To, jak szybko zbliżysz się do 100% entropii, zależy od tego, od czego zaczynasz i jak szybko nakładasz zadłużenie techniczne oraz jak wysokie są na nim odsetki.

Systemy oprogramowania degenerują się i gniją z powodu konserwacji, a nie z powodu jej braku. System działający od lat bez zmian kodu z definicji spełnia wszystkie jego wymagania i cele i odnosi sukces.

To systemy wymagają ciągłej zmiany, ponieważ zaczęły się bliżej maksymalnej entropii, są to systemy, które są ciągle szturchane i szturchane, a konserwacja przyspiesza negatywną zmianę.

Good Enough to Good Enough

Systemy z krótkim cyklem życia, takie jak strony internetowe, które ciągle się zmieniają, nie korzystają z drogiego, dużego projektu z góry 100% pokrycia kodu w testach jednostkowych, ponieważ czas amortyzacji jest zbyt krótki, aby odzyskać koszty.

Systemy o długim cyklu życia, takie jak wspomniana wyżej wewnętrzna linia aplikacji biznesowych, również nie korzystają z ogromnych inwestycji w 100% testy jednostek pokrycia kodu, ponieważ tempo zmian w trakcie trwania projektu zbliża się do stałej bliskiej zeru w moda nieliniowa.

Dlatego plany wycofania z eksploatacji są ważniejsze, a systemy zastępcze powinny być planowane tak, jak coś jest wypuszczane na rynek, a nie po tym, jak minęło kilka lat i jest nieobsługiwane, więc nowy system musi zostać wdrożony.

O ile mi wiadomo, nie uczą o BBM, nigdy nie spotkałem niedawnego absolwenta CS, który wiedziałby, co to jest, a tym bardziej dlaczego tak się dzieje.

Właśnie dlatego Good Enough jest Good Enough , nic więcej nie jest.

Oprogramowanie Slumlords

Nie bez powodu są lordowie slumsów, którzy czerpią zyski z zaniedbanych szantowych budynków. Zarób więcej niż wydają na stopniowe utrzymanie zaniedbanej nieruchomości. Jeśli tego nie zrobią, zburzą budynek i zastąpią go. Ale nie robią tego, ponieważ koszty przyrostowe są znacznie mniejsze niż remont lub wymiana całego budynku. Są też klienci (najemcy), którzy są skłonni zapłacić za zaniedbaną nieruchomość.

Żaden właściciel budynku, pan slumsów, czy nie, nie wyda pieniędzy na nieruchomość tylko z powodu akademickiego pojęcia doskonałości, która nie przekłada się na znaczny zysk w stosunku do związanych z tym kosztów.

Żaden klient nie zapłaci za uaktualnienia systemu oprogramowania, który działa dla niego akceptowalnie. Żadna firma nie wyda pieniędzy na samo pisanie i ponowne pisanie kodu, bez żadnego wymiernego znacznego zysku.

Microsoft jest najbardziej dominującym i odnoszącym sukcesy lenistwem oprogramowania. System Windows zaczął otrzymywać podstawowe podstawowe zapisy dopiero od niedawna. I nadal nie usunęli całego starszego kodu z jądra. Nie ma to dla nich sensu biznesowego, ludzie są bardziej niż gotowi zaakceptować niski poziom oczekiwań, jaki postawili w ciągu ostatniej dekady.

Rokowanie

Jest to wzór od ponad 20 lat, gdy zajmuję się programowaniem. To się wkrótce nie zmieni. To nie tak ludzie chcą, żeby wyszedł z jakiegoś systemu wierzeń, to rzeczywistość sił zewnętrznych działających na biznes. Biznes napędza podejmowanie decyzji, zyski nie są złe, płacą twoją pensję, krótkoterminowa lub długoterminowa wizja jest nieistotna, jest to branża krótkoterminowa z ciągłą zmianą z definicji. Każdy, kto spiera się na tyle dobrze, by osiągnąć zysk , nie rozumie biznesu.

Spędziłem 15 lat na konsultacjach i bardzo szybko nauczyłem się, że wystarczy, że wszystko inne kosztuje mnie pieniądze. Tak, chciałem, żeby wszystko było idealnie, ale jeśli nie sprzedajesz bazy kodu, co stanowi 99,99999% czasu, gdy sprzedajesz rozwiązanie , cały ten prefekt czysty, uporządkowany elegancki kod jest tracony i po prostu tracisz czas, za który nigdy nie otrzymasz zwrotu .

Postęp i nadzieja

Metodologie zwinne są dobrym krokiem we właściwym kierunku, przynajmniej filozoficznie. Zajmują się chaosem i ciągłymi zmianami jako obywatele pierwszej klasy i akceptują to. Odrzucają praktyki dogmatyczne, uznając, że metodologie i praktyki powinny ulec zmianie, a także wymagania i technologie.

Akceptują entropię, którą wprowadza brak czasu lub zmieniające się wymagania, zmieniający się personel i żywotność oprogramowania z koncepcją długu technicznego.

Ale Agile nie jest panaceum, nie zmieni podstawowych praw fizyki, a podstawy kodu będą gnić niezależnie od tego. Od zarządu zależy, czy poradzisz sobie ze zgnilizną, zanim całkowicie wymknie się ona spod kontroli i stanie się niemożliwe do opanowania.

Zwinne, gdy wykonane poprawnie, pomaga zarządzać entropią, spowalnia ją, śledzi, mierzy i radzi sobie z nią w zaplanowany sposób. To nie zatrzyma!

Decyzja o karierze

Jeśli jest to dla ciebie prawdziwy problem filozoficzny, prawdopodobnie powinieneś rozważyć inne wybory zawodowe, ponieważ sposób, w jaki działa praca, ma uzasadnioną wartość biznesową. Projekty Open Source nie mają lepszych osiągnięć, aw wielu przypadkach kod jest nawet gorszy niż większość kodu firmowego, jaki widziałem.

Jestem ciekawy, czy moje obecne doświadczenia jako stażysty są reprezentatywne dla rzeczywistej branży.

Nie, nie jest. Jest reprezentatywny dla twojego poziomu kariery i doświadczenia. To część uczenia się o tym, jak działają firmy z perspektywy wewnętrznej kontroli jakości.

Jako tło przeszedłem przez większą część dwóch kierunków komputerowych i matematyki na dużym uniwersytecie; Pokonałem wszystkie klasy i uwielbiałem wszystkie, więc chciałbym myśleć, że nie jestem okropny w programowaniu. Otrzymałem staż w jednej z największych firm programistycznych i w połowie byłem zszokowany wyjątkowo niską jakością kodu.

Twoje umiejętności, doświadczenie, wykształcenie nie mają wpływu na jakość pracy wykonywanej przez innych. Po prostu dlatego, że nie masz uprawnień do zmiany tych praktyk. Nie ma znaczenia, czy byłeś dobry czy zły na uniwersytecie. Nie zmienia to sposobu, w jaki obecnie działa firma, dla której pracujesz. Chociaż jest świetnie, masz całe to tło. To naprawdę dla własnej korzyści, a nie dla nich. Dlatego ważne jest, aby studiować to, co kochasz.

Otrzymałem staż w jednej z największych firm programistycznych i w połowie byłem zszokowany wyjątkowo niską jakością kodu. Komentarze nie istnieją, to wszystko kod spaghetti, a wszystko, co może być złe, jest jeszcze gorsze. Zrobiłem mnóstwo korepetycji / TAing, więc jestem bardzo przyzwyczajony do czytania złego kodu, ale najważniejsze produkty branżowe, które widziałem, przebiły to wszystko.

Nauczyłem się podczas wielu lat programowania, że ​​istnieje różnica między „jakością kodu” a „akceptowalnym kodem”. Prawda jest taka, że ​​albo ktoś z autorytetem znajdzie kod źródłowy w akceptowalnym stanie, albo uzna go za niedopuszczalny, ale konieczny. Chociaż byłoby miło, gdybyśmy wszyscy mogli posprzątać projekty, w które się angażujemy. Często przeznaczanie zasobów na wykonywanie tej pracy nie leży w interesie firmy ani w budżecie. Można argumentować logicznie, dopóki następnego dnia nie wstanie słońce, dlaczego warto to naprawić, ale kiedy kierownictwo zdecyduje, że obecny stan jest „akceptowalny”, niewiele można zrobić. Wszystko to jest bezpośrednio związane z tym, kto prowadzi rzeczy. Albo cenią sobie dobrą jakość wewnętrzną, albo nie. Wyraźnie to cenisz i dlatego niepokoi Cię ten obecny stan.

Przykłady tego typu problemów znajdziesz w każdej branży zależnej od wewnętrznej kontroli jakości. Począwszy od rozwoju oprogramowania po produkcję. Musisz nauczyć się postrzegać to nie jako problem, ale po prostu jako obecny stan ich kodu źródłowego. Tak to jest, potrzeba X liczby minut, aby znaleźć coś, zajmuje X liczby minut, aby coś naprawić.

Firma albo nie przejmuje się tym dodatkowym czasem, albo uważa, że ​​jest to do przyjęcia.

Pracuję 10-12 godzin dziennie i nigdy nie czuję, że nigdzie się nie dostaję, ponieważ to niekończące się godziny próbowania znalezienia nieudokumentowanego API lub określenia zachowania jakiejś innej części (całkowicie nieudokumentowanego) produktu. Do tej pory codziennie nienawidziłem pracy i desperacko chcę wiedzieć, czy to właśnie czeka mnie do końca życia.

Dlaczego można było spędzać długie godziny na studiach, ale teraz nie jest dopuszczalne, aby studiować kod źródłowy? Jestem pewien, że powodem, dla którego pracodawca cię zatrudnił, było przekonanie, że możesz sobie z tym poradzić.

Pozwól, że dam ci radę. Dobrzy programiści wiedzą, kiedy poprosić o pomoc swoich towarzyszy. Nie myśl, że odpowiedzi są zawsze w kodzie. Zaoszczędziłem godziny czasu, po prostu zadając ludziom kilka pytań. Wygląda na to, że potrzebujesz szybkiej pomocy.

Po drugie, nie znamy warunków pracy. Długie godziny pracy są faktem w wielu branżach. Musisz rozwiązać samodzielnie, ale mogę ci powiedzieć. Nienawiść do pracy nigdy nie jest dobrym znakiem. Powinieneś sobie poradzić z tym uczuciem i dotrzeć do jego źródła. Przykro mi, że uważasz to doświadczenie za negatywne.

Czy zwróciłem uwagę na staże (absurdalnie duże wypłaty sugerują, że nie jest to pozycja niskiej jakości), czy też taki jest prawdziwy świat?

W szkole radziłeś sobie bardzo dobrze, ale teraz masz staż i nie radzisz sobie tak dobrze. Wygląda na to, że jesteś już w prawdziwym świecie. To część życia. Pytanie brzmi: co zamierzasz z tym zrobić? Że mój przyjaciel jest jedyną rzeczą, która ma znaczenie. Nie możemy ci powiedzieć, co masz robić. Musisz podjąć decyzję.

Mogę powiedzieć, że brzmi to tak, jakby twoje doświadczenia w twoim wieku były znacznie lepsze niż wszelkie możliwości, jakie miałem. Życie dla mnie w latach 90. było walką o zapłacenie czynszu i znalezienie mojej kolejnej umowy. Uważaj się za szczęściarza.

Po 25 latach i różnych firmach i branżach mogę powiedzieć:
Tak, to dość powszechne.
To dlatego inżynierowie są zwykle wynagradzani dość dobrze, muszą być dobrzy w radzeniu sobie z bałaganiarskimi podge i wciąż być w stanie wprowadzać zmiany, opierając się jednocześnie palącemu pragnieniu przeforsowania całej tej cholernej rzeczy i dowiedzenia się, co to do cholery powinno być robić. Wrzuciłem tam dla ciebie emocje - to normalne, że tak się czujesz w związku z napotkanym kodem!

Kod, który widzisz, często przechodził niekończące się iteracje przez różnych programistów z różnymi podejściami i standardami oraz różnymi konwencjami nazewnictwa itp. Itp.

Jednak dzieje się tak, że presja $ jest zawsze włączona. Zawsze kusi opisanie, w jaki sposób i dlaczego lepszy kod jest jedynym sposobem na dłuższą metę, ale w wielu pracach zegar tyka na krótkoterminowe rozwiązanie szybkiej naprawy. Zniszczenie standardów w projekcie zajmuje tylko 1 inżynierowi. Potrzeba bardzo dobrego menedżera, który wie, jak temu zapobiec i obronić właściwe podejście (gdy jest to rozsądnie możliwe), aby naprawdę sobie z tym poradzić.

Jedno jest pewne, termin „dobry kod” jest zbyt subiektywny, aby był użyteczny. Oczywiście nie jest to subiektywne, możesz wymienić konkretne powody / elementy. Jednak inne osoby wymieniają różne pozycje i priorytety, niektóre nawet nie techniczne, które ich zdaniem są ważne, a zatem są subiektywne.

Podobnie jak Drekka, zaczyna to brzmieć przygnębiająco, więc postaram się zmienić nieco bardziej pozytywnie, ponieważ z pewnością to prawda, że:

• Istnieją organizacje, często te z największych elementów technicznych, które są robienie właściwych rzeczy.
• Nowsza firma ... i kod ... sprzątaczka to ma tendencję do być. spaghetti rośnie z czasem i ludźmi.
• Niektórzy ludzie robią TDD i BDD, inni nie. Zasięg jest ogromny.
• Obecnie, po około 10 latach, zmienia się cała baza technologiczna, więc ci, którzy pozostają w branży, mogą mieć równie trudny czas, jak nowicjusze.

Wreszcie, jak zauważa Anthony Blake, zawsze istnieją 3 czynniki - czas, koszt i jakość.
Podoba mi się powiązane wyrażenie: „wybierz 2” !

Jest na ten temat wiele opinii, ponieważ doświadczenia każdego są inne.

Moim zdaniem około połowa programistów, z którymi się spotykam, ma dobre intencje, ale przeciętne umiejętności. Na górze jest mała grupa błyskotliwych ludzi, a na dole mała grupa, która próbuje, ale zasadniczo powinna zrobić coś innego, ponieważ tak naprawdę tego nie rozumie. Niestety istnieje jeszcze jedna niewielka grupa niekompetentnych głupców, którzy myślą, że są o wiele sprytniejsi niż wszyscy inni i zwykle mają dość tego, jak powinieneś ich śledzić.

Jeśli chodzi o projekt, podjąłem się wielu zadań i od razu poproszono mnie o „opiekę” nad pewnym ustalonym projektem, zwykle takim, który firma właśnie odkryła, że ​​naprawdę potrzebuje po utracie ostatniego dewelopera. Zazwyczaj znajduję dokładnie to, co nakreśliłeś powyżej - nieudokumentowane, przepracowane, błędne spaghetti. Czasami mogę to naprawić, czasem po prostu zaczynam od nowa. To nawet nie musi być stary kod, znalazłem to w nowych projektach, o które poproszono mnie również o „pomoc”.

Musisz wziąć pod uwagę fakt, że większość firm zapewnia stażystom nieudolną pracę. Zabawne pojawiają się po tym, jak zrobiłeś dwie rzeczy: 1 - sprawdziłeś siebie i 2 - poświęciłeś trochę czasu na pracę nad innymi rzeczami niż naprawianie błędów innych ludzi. Innymi słowy, musisz wykazać zdolność i inicjatywę.

Prawdziwą sztuczką w radzeniu sobie ze złym kodem jest ustalenie, co można odzyskać, a co nie. Wynika to z doświadczenia i badań.

Inną opcją kariery, którą masz, jest zaprzestanie pracy dla uznanych firm i poszukiwanie pracy w startupach. Wtedy nie będzie już żadnego bzdurnego starszego kodu do utrzymania, więc będziesz miał szansę pomóc zbudować coś lepszego. Minusem jest to, że presja dostarczania wywierana na projekty startowe często oznacza, że ​​skróty i hacki są używane, gdy nie powinny.

Programiści zbyt często są gotowi wziąć na siebie dług technologiczny, aby dostarczyć go wcześnie lub na czas. Niestety wpływ długu technologicznego jest często pomijany, minimalizowany, ignorowany lub odrzucany przez deweloperów i kierownictwo, dopóki nie będzie za późno i będą mieli kłopoty.

Przepraszam, jeśli to brzmi przygnębiająco. Jestem pewien, że ktoś inny może zrobić coś bardziej pozytywnego. :-)

Jest tu kilka świetnych odpowiedzi, ale dodam trochę;

Witamy w prawdziwym świecie - niestety jest to bardzo częste.

Zobacz poniższy schemat;

W oprogramowaniu korporacyjnym możesz wybrać tylko 2 lub więcej i musisz poświęcić jeden.

Jak się wydaje, większość świata korporacyjnego podąża za szybkością i ceną.

Nie do końca świadczy o branży, ale z mojego ograniczonego doświadczenia 5+ lat. Przepracuję twój staż i wezmę jak najwięcej lekcji z tego doświadczenia. Poszukaj znaków rozpoznawczych i wskaźników. Na przykład na następnej pozycji bez wątpienia musisz przejść szereg wywiadów. Ten proces jest drogą dwukierunkową i daje szansę na poznanie firmy. Jest to niezwykle ważne i prawdopodobnie doprowadzi do twojego własnego szczęścia i dobrego samopoczucia.

Podsumowując, zauważ znaki ostrzegawcze;

• Kto prowadzi firmę? Czy jest to pojedynczy menedżer, zespół marketingu (jeśli tak, trzymaj się z daleka), zespół programistów itp. Ten kąt oznacza, że ​​możesz uzyskać większą lub mniejszą dźwignię na projekty, czas poświęcony na projekty itp.
• Czy istnieje uznanie techniczne? Zobacz, jak kierownictwo, przełożony i członkowie zespołu traktują się nawzajem. Byłem w wywiadzie, w którym menadżerowie wykonują wszelkiego rodzaju ruchy brwiami, kiedy kierownik techniczny zaczął mówić. Po tym i nauce nie używali kontroli źródła - nie można było wystarczająco szybko pokazać drzwi.
• Cel biznesowy Czy firma żyje z dnia na dzień, tak jak w przypadku codziennych celów finansowych, czy też ma długoterminowy plan, którego jesteś częścią. Tworzenie oprogramowania odbywa się zwykle przez miesiące, więc posiadanie firmy o schizofrenicznym charakterze zwykle prowadzi do bałaganu.
• Grzebać ciężko - zadając pytania techniczne i sprawdzać, czy ludzie się tasują. Kontrola źródła, kontrola dokumentów, proces wydawania, raporty o błędach, styl zarządzania, warunki użytkowania itp.

Żyj więc i ucz się, i pomyśl o swojej następnej roli. Złe doświadczenie nie jest wcale takie złe, ponieważ będziesz lepiej edukowany na temat świata pracy i biznesu.

Cóż, kończę swoją drugą dekadę w branży i mogę powiedzieć, że doskonały czysty kod zdarza się bardzo rzadko, a kiedy to się dzieje, długo tak nie jest. Ogólnie rzecz biorąc, będziesz ciągle próbował naprawiać błędy z przeszłości, a (niestety) zmuszony przez ograniczenia czasowe i słabe przywództwo do popełniania błędów teraźniejszości.

O ile nie prowadzisz bardzo szczególnego rodzaju działalności programistycznej, presja, aby wyciągnąć funkcjonalny produkt za drzwi, zastępuje wszystkie inne obawy, a optymalizacja wykraczająca poza pewien punkt jest uważana za bezcelową. Jeśli program działa w ciągu 5 minut, a potrzebujemy go tylko w ciągu 5 minut, nikt nie da ci kilku tygodni na obniżenie czasu działania do 2 minut.

Jeśli jakimś cudem masz doskonałe połączenie kompetentnego zarządzania, wyraźnego celu, pieniędzy, talentu i czasu, a także produkujesz czysty, super produkt ... Jedynym sposobem, aby tak pozostało, jest to, że nigdy nie dotkniesz to znowu . Utrzymanie i rozszerzenie prawie zawsze ma bardzo niski priorytet, zmiany są zawsze potrzebne w przypadku skutecznego zerowego powiadomienia, a ostatecznie zostają zakłócone błędnie.

Wczoraj myślałem o tym jednym projekcie. To było dla mnie tak oczywiste marzenie o fajce, że wyskoczyłem z drzwi naprawdę minimalnie funkcjonalny badziew. Widziałem to jako stratę czasu i zasobów.

Cóż, niespodzianka, niespodzianka, wszyscy to uwielbiali i wszystko wyszło dobrze. Więc wróciłem do deski kreślarskiej i zrobiłem to dobrze. Nowa wersja była niesamowita! Ale potem nastąpił obrót w zarządzaniu i cała sprawa została odrzucona na korzyść „nowego kierunku biznesu”.

Druga iteracja miała naprawdę w połowie zaimplementowane wdrożenie w firmie i nigdy nie słyszałem o tym nic innego, co jest zabawne, ponieważ wiem, że przynajmniej ~ 10 jednostek biznesowych nadal z niej korzysta (oprogramowanie, które zlecamy do wykonania zadania jest prawie 2 lata opóźnione) i najwyraźniej nigdy się nie psuje.

To prowadzi nas do mojej ostatniej kwestii. Nawet jeśli wytworzysz coś cudownego, fakt, że działa on tak dobrze, oznacza, że ​​ŻADNY nie będzie się z nim w najmniejszym stopniu zaznajomił, a kiedy się zepsuje (zwykle dlatego, że zrobili coś głupiego), przeklną twoje imię gorzej niż oni przeklinać tego idioty, który napisał coś, co psuje się co trzeci wtorek.

Trudno powiedzieć, co uważasz za okropnie niskiej jakości kod, ale tak, niewielu programistów jest bardzo dobrych (z definicji). W miarę rozwoju oprogramowania ludzie popełniają błędy. Z czasem narastają, a presja biznesowa (i lenistwo / ignorancja programisty) powoduje, że refaktoryzacja ... jest rzadkością.

Naprawdę nie mogę mówić za wszystkich, ale oto, co mogę powiedzieć.

Nie mam ponad 30 lat pracy w tej dziedzinie, ale widziałem wystarczająco dużo, aby powiedzieć kilka rzeczy. Projekt ma życie prawie jak człowiek. Wstępny projekt może nie odpowiadać obecnym potrzebom, powiedzmy, jednego projektu po 20 latach rozwoju. To powiedziawszy w tym czasie, wiele osób zmieniło zepsuty kod i dodało rzeczy, które na początku nie byłyby możliwe.

Nie jest trudno wyobrazić sobie brzydki kod w starszych projektach lub dość starych projektach. Nie możemy oczekiwać, że wszyscy w pełni zrozumieją wstępne projekty. To smutne, ale tak już jest.

To powiedziawszy, musisz pamiętać, że refaktoryzacja starszego projektu nie zawsze jest możliwa i czasami nawet nie jest pożądana. Pracowałem w firmie, w której pracowali nad zamiennikiem projektu, nad którym pracowałem. Nie pozwolono mi za bardzo zrefaktoryzować mojego projektu w obawie, że zadziała on lepiej niż nowy projekt. Jestem prawie pewien, że nie ma sposobu, aby ten projekt kiedykolwiek działał lepiej niż nowy, świeży. wyrażenie było trochę jak „Nie poprawiaj, po prostu spraw, aby działało”.

W końcu nie będziesz miał często tego rodzaju projektów, ponieważ często czytam i słucham. Powinieneś spróbować znaleźć pracę ze startupami zamiast z dużymi korporacjami. Startupy są dość interesujące i możesz w końcu iść szybko, jeśli zauważysz, że nie idzie tak, jak chcesz.

Jedną rzeczą, którą możesz zrobić, naprawdę nic nie obiecuję, ale jeśli uważasz, że kod jest tak zły i wymaga refaktoryzacji. Udostępnij to zespołowi. Pamiętaj, że ludzie, którzy napisali ten brzydki kod, mogą z tobą współpracować. Nie chodzi o zranienie ludzi, ale jeśli zauważysz, że projekt, nad którym pracujesz, po pewnym czasie zawali się, a ludzie spędzą więcej czasu na zrozumieniu tego, co robi, zamiast go ulepszać. Lepiej zabrać głos i zgłosić problem, niż zachować go dla siebie. Jeśli masz szczęście, możesz sfinalizować projekt.

Jeśli zakończysz refaktoryzację projektu, możesz być osobą wskazaną na złe wybory projektowe! I wtedy możesz zrozumieć, dlaczego refaktoryzacja nie zdarza się tak często. Mam nadzieję, że jeśli cały zespół będzie musiał dokonać refaktoryzacji, nikt nie zostanie wskazany. Po prostu zwolnią wszystkich =)

Próbowałbym podsumować odpowiedź na te pytania prostym cytatem:

All code turns to crap given enough time and hands.

Reszta to tylko historie ...

Jakość kodu zależy głównie od dwóch czynników.

Po pierwsze zawsze są pieniądze. Firmy, które mają wysoką presję przetrwania, zwykle płacą niskie płace, angażują mniej doświadczonych programistów, mają napięte harmonogramy i nie mają czasu ani pieniędzy, aby wykorzystać swoich programistów.

Drugi to ludzie. Przede wszystkim ci, którzy decydują o budżetach, muszą wybrać wydatki na jakość kodu, a następnie muszą zaangażować ludzi, którzy chcą je „przeżyć”. Jak możesz sobie wyobrazić, może okazać się trudne przekształcenie dobrze płatnego pięćdziesięcioletniego programisty Delphi (bez zamiaru stereotypów, przepraszam) w aktualnego programistę Java, który zajmuje się kompilacją i produkcją CI luźno powiązany kod. Wielu programistów ma niechęć do lekcji przez (być może młodszych) kolegów, nie lubią, gdy ktoś łowi w stawie - lub grzechota na tronie.

Biorąc to pod uwagę, a także biorąc pod uwagę fakt, że masz starszy kod w każdej firmie, powiedziałbym, że dostajesz dużo tego w prawdziwym życiu. Możesz zachowywać się jak harcerz: idź do lasu, weź śmieci i wyczyść je. Następnym razem będziesz miał mniej bałaganu do przejścia.

Witamy w kodzie z budżetem! Istnieje wielka różnica, gdy zarządzanie jest popychane przez kierownictwo do rozwoju, który odbywa się zbyt wcześnie, bez planowania i skracania narożników. Miałem podobne doświadczenie szoku w prawdziwym świecie, kiedy dostałem pierwszą pracę programistyczną po studiach. Brak dokumentacji! Z czasem wiele się nauczyłem, pisanie i aktualizowanie formalnej dokumentacji to tylko strata czasu. Na szczęście był to niesamowity zespół. Prowadził go facet, który wiedział, co robi, a pozostałym członkom zespołu bardzo zależało na pisaniu kodu we właściwy sposób. Od tego czasu moje doświadczenia są podobne do twoich. Dużo okropnego kodu, dużo złego kodu, mnóstwo nieświadomych „programistów”. Wydaje się, że na każdego dobrego programistę przypada 100 złych.

Nie jesteś skazany na nienawidzenie swojej pracy na zawsze. Musisz tylko znaleźć firmę wystarczająco inteligentną, aby dostrzegać długoterminowe korzyści, które są skłonne zainwestować trochę z góry. Udało mi się udowodnić, że robienie rzeczy we właściwy sposób zamiast najszybszego jest korzystne i zyskałem szacunek i zaufanie do tego w firmach, w których pracowałem. Z czasem kod spaghetti zostaje naprawiony lub staje się przestarzały, a Twój kod przejmuje kontrolę. Po prostu bądź przygotowany na kompromis. Czasami najfajniejszym lub najsolidniejszym sposobem programowania jest po prostu przesada i można to zrobić w szybki i brudny sposób.

Otrzymałem staż w jednej z największych firm programistycznych

Nie wszystkie firmy są takie same. W większości firm znajdziesz gówniane zespoły i głupie bazy kodu oprogramowania. Ale możesz także znaleźć świetne zespoły i świetne bazy kodu.

Myślę, że chłopaki z Solaris bardzo dobrze i uczciwie opisali rodzaj kodu, który można znaleźć w dużych firmach: http://hub.opensolaris.org/bin/view/Community+Group+on/dev_solaris

Do tej pory codziennie nienawidziłem pracy i desperacko chcę wiedzieć, czy to właśnie czeka mnie do końca życia.

Nie, koduję od ponad 15 lat i nadal to kocham.

Nie oznacza to, że wszystko było idealne. Widziałem kilka okropnych baz kodu, a także kilka świetnych. Sztuką jest znalezienie odpowiedniego miejsca dla siebie.

Duża firma bardzo różni się od małej. W ramach tej samej firmy zespół A czasami różni się od zespołu B. Znajdź ten, który ma dla Ciebie odpowiednią równowagę (np. Ambitne projekty, kultura, którą lubisz, dobra płaca itp.)

Powodzenia!

Widziałem podobne rzeczy jak ty. Mam dwa doświadczenia przypadków, kiedy to nastąpi.

1. Gdy rozwój jest zbyt ukierunkowany na projekt. Jedyne, co się liczy, to terminowe dostarczenie funkcjonalności, a następnie wylogowanie się. Następnej zmiany dokona ktoś inny, inny zespół / kierownik projektu z nowym budżetem.
2. Kiedy tylko kilka osób zarządza oprogramowaniem przez długi czas, programiści stają się leniwi, ponieważ i tak znają się na swoim oprogramowaniu. Zasady akademickie są daleko.

To smutne, ale tak jest w niektórych miejscach.

Sprawdź, czy możesz dokonać drobnej zmiany na lepsze, przyzwyczaić się do niej lub zmienić firmę i poprosić o sprawdzenie kodu podczas rozmowy kwalifikacyjnej :-)

To będzie krótka odpowiedź.

Edukacja jest bardzo przydatna, abyś poczuł się wykwalifikowany i idealistyczny. To dobra rzecz i powinieneś spróbować trzymać się idealizmu.

Jeśli w ogóle jesteś obiektywny i możesz spojrzeć wstecz na swoją pracę w przyszłości, nie będzie to bardzo satysfakcjonujące doświadczenie. Jeśli nie okłamiesz siebie lub niczego się nie nauczysz, zobaczysz wiele sposobów na ulepszenie tego, co zrobiłeś.

Ogólnie rzecz biorąc, cały świat robi to wokół ciebie. Kiedy więc spojrzysz na pracę z przeszłości, pomijając wyjątki, będzie ona gorsza i wymaga poprawy. Jeśli nie czujesz się w ten sposób, oznacza to, że wykonujesz niewłaściwą pracę lub jej płacenie jest zbyt dobre.

Dobrą wiadomością jest to, że możesz czerpać korzyści z błędów innych i z porównania z przeszłością. Gdyby wszystkie aplikacje działały dobrze i były łatwe w utrzymaniu, nowi programiści nie byliby potrzebni. Moim zdaniem utrzymanie niektórych innych cruft programistów jest przydatnym doświadczeniem edukacyjnym i powinno być obowiązkowym elementem szkoleniowym dla wszystkich programistów blue sky.

Twoje negatywne doświadczenia są nazbyt typowe dla dużych, znanych firm markowych, do których wielu programistów uczy się podchodzić z większą ostrożnością i niepokojem niż wtedy, gdy mieli okazję pracować w jednym z nich. Zasadniczo, im więcej masz warstw zarządzania, tym więcej przeciętności jest wspierana. Kierownicy średniego szczebla nie informują kierowników wyższego szczebla o jakości kodu. Raportują o funkcjach dostarczonych w X czasie i przedstawiają prezentacje Powerpoint na temat interfejsu neato UI, które, jak mają nadzieję, działają wystarczająco długo, aby je przejść. Jeśli wszystko się załamie miesiąc później, zwykle jest to problem kogoś innego i oni o tym wiedzą.

Więc tak, twórcy, którzy są żywicielami w takich miejscach, nie przejmują się zbytnio. Nie mogliby tam przeżyć, gdyby to zrobili. Słyszałem o Dolinie Krzemowej, że jeśli chcesz być leniwy, pracuj dla jednego z wielkich nazwisk. Jeśli chcesz ekscytującej pracy, poszukaj nowszego startupu, który nie jest jeszcze marką. Pracuję w Chicago i mogę tutaj ręczyć za podobne zjawisko.

Zasadą ogólną (z pewnymi wyjątkami jestem pewien), większe uznanie dla jakości kodu w firmach mniejszych i zarządzanych lub będących własnością osób, które również nadal piszą kod. Rekompensata jest często mniejsza, ale moim zdaniem praca jest często znacznie bardziej satysfakcjonująca.

Jako początkujący deweloper prawdopodobnie nie będziesz miał dużej kontroli nad tym, dla kogo pracujesz, ale powiem, że posiadanie dobrego imienia w swoim CV przez rok lub dłużej zdecydowanie ekscytuje rekruterów i pracowników HR. Możesz także nauczyć się czegoś, czego nie nauczyłbyś się, inaczej pracując dla kogoś całkowicie okropnego przez pierwsze sześć miesięcy, a także pomaga lepiej kontrolować, które najlepsze praktyki są tak naprawdę ważne i dlaczego, a które tylko mody.

I oczywiście, pracując z bardziej popularnymi narzędziami korporacyjnymi w głównym nurcie, zwykle zauważysz, że mediana poziomów talentów będzie dość kiepska. Jeśli twoje podstawowe umiejętności to kombinacja Java i C #, nieco poszerz swoje horyzonty. Możesz znaleźć szczęśliwszą niszę na poziomie średnim, pisząc Erlang lub Python lub: o JavaScript.

I nie pozwól nikomu powiedzieć ci nic innego. Być może nie masz wyboru, jak postępować, ale kod bzdury jest! @ # $ Ing drogi.

Twoje pytanie dotyczyło staży. Nigdy nie miałem programistycznego, ale stażysta w stacji radiowej, tak naprawdę tutaj nie ma zastosowania.

Twoje pytanie dotyczyło również twoich doświadczeń podczas staży. Twoje doświadczenia związane ze stażem i odpowiedzi, które otrzymałeś do tej pory, podsumowują moje doświadczenia po dwudziestu siedmiu latach pisania oprogramowania (rozpoczęte w połowie czerwca 1985 r.).

Nigdy nie wierzyłem w to w szkole, kiedy nasi instruktorzy mówili, że jest więcej myślenia niż pisanie kodu. Mieli rację. A jeśli próbujesz dowiedzieć się czyjś kod, jest gorzej bez komentarzy i prawie tak samo źle z komentarzami. Spróbuj utrzymać domowy system poboru podatków komunalnych bez komentarzy, dokumentacji, formalnej kompilacji i kontroli kodu źródłowego.

Ilekroć możesz zrobić dobrze bez bezpośredniego naruszenia standardowych zamówień, zrób to dobrze. Zawsze pamiętaj, że łatwiej jest przeprosić za zrobienie czegoś, o co nie poprosiłeś o pozwolenie, niż nieudzielenie pozwolenia i sprzeczne z bezpośrednim rozkazem.

Nie zapomnij o standardach, których nauczyłeś się w szkole. Nie są bezużyteczne, ale bardziej niż prawdopodobne, że normy te są asymptotami w granicach rachunku różniczkowego. Zawsze możesz spróbować do nich podejść, ale nigdy nie osiągniesz ich wartości.

Powodzenia.