Nie mogę programować, ponieważ kod, którego używam, wykorzystuje stare style kodowania. Czy to normalne dla programistów?

Mam swoją pierwszą prawdziwą pracę jako programista, ale nie mogę rozwiązać żadnych problemów z powodu zastosowanego stylu kodowania. Kod tutaj:

• Nie ma komentarzy
• Nie ma funkcji (50, 100, 200, 300 lub więcej wierszy wykonywanych po kolei)
• Używa wielu ifinstrukcji z wieloma ścieżkami
• Ma zmienne, które nie mają sensu (np .: cf_cfop, CF_Natop, lnom, r_procod)
• Używa starego języka (Visual FoxPro 8 z 2002 roku), ale są nowe wersje z 2007 roku.

Czuję, że wróciłem do 1970 roku. Czy to normalne, że programista zaznajomiony z OOP, czystym kodowaniem, wzorami projektowymi itp. Ma problemy z kodowaniem w ten staromodny sposób?

EDYCJA : Wszystkie odpowiedzi są bardzo dobre. Dla mojej (nie) nadziei wydaje się, że istnieje wiele tego rodzaju baz kodów na całym świecie. Punktem wymienionym dla wszystkich odpowiedzi jest refaktoryzacja kodu. Tak, naprawdę lubię to robić. W moim osobistym projekcie zawsze to robię, ale ... nie mogę zmienić kodu. Programiści mogą zmieniać tylko pliki w zadaniu, do którego są przeznaczone.

Każda zmiana w starym kodzie musi być komentowana w kodzie (nawet z Subversion jako kontrolą wersji), a także meta informacje (data, programista, zadanie) związane z tą zmianą (stało się to bałaganem, jest kod z 3 używanymi liniami i 50 skomentowano stare linie). Myślę, że to nie tylko problem z kodem, ale także problem zarządzania oprogramowaniem.

Ok, będę tępy. To złe miejsce do pracy ... Byłem w takich sytuacjach i zazwyczaj kończy się to tym, że zostałeś pochłonięty przez ten kod. Po około roku przyzwyczaisz się do tego i stracisz kontrolę nad tym, w jaki sposób można zastosować nowoczesne alternatywy, aby łatwiej osiągnąć to samo zadanie, w sposób łatwiejszy w utrzymaniu, a także szybciej w czasie wykonywania w w większości przypadków.

Opuściłem takie miejsce pracy, ponieważ po zaledwie miesiącu poczułem, że wciągnięto mnie w stary kod kreskowy. Próbowałem spróbować, ale postanowiłem tego nie robić. Nie mogłem używać czystego kodu i zacząłem tracić umiejętności z powodu braku codziennej praktyki. Każde nowoczesne podejście musiało zostać zatwierdzone przez 3 warstwy programistów, co nigdy się nie wydarzyło, ponieważ chodziło o to, że rzeczy mogą się popsuć, gdy zastosuje się nowoczesne podejście. Kruchy charakter kodu, który pojawia się, gdy nie używasz nowoczesnych metod, jest dość przerażający.

Nie zrozumcie mnie źle, są przypadki, w których ludzie nadmiernie inżynierują rozwiązania, a ja jestem temu przeciwny. Ale ciągnięcie się do konwencji i stylu kodowania z lat 80-tych przez długi czas powstrzyma twoje postępy, a także, jak sądzę, możliwości kariery.

Z drugiej strony musisz zarabiać pieniądze, więc czasami musisz robić to, czego nie lubisz. Jednak w takich przypadkach miej oko na objawy wypalenia i zamień kodowanie w codzienne zadanie.

Ten styl kodowania (jeśli chcesz go nazwać jakimkolwiek stylem) jest złym stylem kodowania.

W większości współczesnych języków można pisać krótkie funkcje z opisowymi nazwami zmiennych i rozsądną kontrolą przepływu (Visual FoxPro jest nowoczesny, tak).

Masz problemy ze złą bazą kodu, niczym więcej, niczym innym.

Takie bazy kodów istnieją i jest ich wiele - fakt, że masz z nimi problemy, świadczy o tym, jak złe mogą być (i że masz dobry trening).

To, co możesz spróbować, to ulepszyć rzeczy, w których możesz - zmienić nazwy zmiennych, wyodrębnić cechy wspólne i podzielić duże funkcje na mniejsze itp. ... Uzyskaj kopię Efektywnej pracy ze starszym kodem ...

Jestem w projekcie C # o bardzo złej strukturze, a nie mil od tego, co opisujesz. Wystarczy połączyć 12 oddzielnych funkcji (oczywiste kopiowanie-wklej) w jedną, która przyjmuje pojedynczy parametr.

Nie jest to tak naprawdę „staromodne”, z wyjątkiem tego, że (obecne) dobre praktyki projektowe nie zawsze były tak popularne. To po prostu zły kod. Zły kod spowalnia każdego. W końcu przyzwyczajasz się do tego, ale tylko dlatego, że przyzwyczajasz się do określonych dziwactw w twoim systemie. Biorąc pod uwagę nowy projekt, możesz znaleźć zupełnie nowe sposoby pisania złego kodu. Dobrą rzeczą jest to, że już wiesz, jak rozpoznać ten zapach.

Najważniejsze, co możesz zrobić, to nie propagować problemu . Nie traktuj tych złych praktyk jako konwencji, chyba że twój zespół jest. Utrzymuj nowy kod w czystości w sposób, który nie wymusza refaktoryzacji. Jeśli jest tak źle i masz czas, zastanów się nad dużym refaktorem ... ale w praktyce rzadko masz ten luksus.

Zastanów się nad dodaniem komentarzy, gdy coś wymyślisz, i zmień małe kawałki jako praktyczne. O ile nie kodujesz solo, musisz wypracować to ze swoim zespołem; jeśli nie ma żadnych konwencji, powinieneś poświęcić trochę czasu, aby je wymyślić, i być może zobowiązujesz się powoli ulepszać bazę kodu, jeśli i tak regularnie ją utrzymujesz.

Jeśli znajdziesz całkowicie izolowaną funkcję ze złymi nazwami zmiennych, a mimo to ją naprawiasz, równie dobrze możesz sprawić, by nazwy zmiennych były przydatne, przerób ifs. Nie wprowadzaj zmian we wspólnych funkcjach, chyba że zamierzasz przebudować dużą ich część.

• nie mam komentarzy - napraw je, gdy się tego nauczysz
• nie mają funkcji (50, 100, 200, 300 lub więcej wierszy wykonywanych po kolei)

Prawdopodobnie pochodzi z poprzedniej iteracji kodu. W tym momencie uważałbym na subtelne różnice między podobnymi do siebie blokami kodu, które stały się „funkcjami”. Ale niezależnie od tego, jak złym pomysłem jest ten typ struktury, jest dość prosty do zrozumienia ... więc nie jestem pewien, gdzie miałbyś z tym problem.

• używa wielu instrukcji if z wieloma ścieżkami - tak naprawdę nie jestem pewien, co masz na myśli
• ma zmienne, które nie mają sensu (np .: cf_cfop, CF_Natop, lnom, r_procod) -

Chciałbym podkreślić ostrożność za pomocą bitu „zmiana nazw zmiennych”. Istnieje spora szansa, że ​​po prostu jeszcze nie rozumiesz żargonu, a nazwy zmiennych nabiorą większego sensu po dłuższym pobycie. Nie wspominając o tym, że nie może być też problematycznych nazw zmiennych, ale twoje przykłady wyglądają na logiczne, jeśli wiesz, jakie są popularne akronimy w Twojej witrynie. Nie jest to oczywiście tak ważne, jeśli jesteś zespołem 1.

• używa języka, którego nie znam (Visual FoxPro 8 z 2002 r.) - To jest twój problem, a nie kod

Brzmi dla mnie jak szansa .

Oczywiste jest, że już widzisz wiele problemów w tym, jak rzeczy są wykonywane i zarządzane. Możesz albo narzekać, że to wszystko śmieci i że nie możesz nic zrobić, LUB możesz użyć tego jako złotej okazji, aby naprawdę pokazać swojemu pracodawcy swoją wartość.

Teraz nie pomoże ci to, jeśli maszerujesz do swojego pracodawcy i mówisz mu, że wszystko musi się zmienić. Sztuka polega na tym, by grać przez chwilę, zadawać DUŻO pytań, a kiedy będziesz musiał napisać kod, będziesz musiał grać zgodnie z ich regułami ze wszystkimi komentarzami itp., Ponieważ będziesz musiał zatrzymać innych programistów poinformowani za pomocą dowolnego systemu, który obecnie preferują, a jednocześnie możesz wprowadzić rozsądne refaktoryzacje, które niczego nie zaryzykują. Możesz wyodrębnić kilka metod, a jeśli twój język to obsługuje, wprowadź kilka testów jednostkowych. Na pytanie, dlaczego zrobiłeś to w ten sposób, lub jeśli powiedziano ci, że robisz coś „źle”, unikaj defensywności lub kłótni podczas racjonalnej prezentacji swojej pozycji dla preferowanego stylu kodowania. Na przykład, możesz odwoływać się do książek, takich jak Clean Code Boba Martina, lub do innych książek, artykułów, a nawet pytań i odpowiedzi, które napotkałeś na Programmers.SE. Wszystko, co może ci się przydać do wsparcia twojej pozycji w faktach, które mogą być poza twoim doświadczeniem w oczach osób, z którymi pracujesz.

Jeśli chodzi o nadmierne komentowanie, niektóre z nich można wyjaśnić, jeśli dodasz kilka opisowych nazw zmiennych i metod, ale możesz również uzasadnić dobry system kontroli wersji i używając tego do prowadzenia rejestru zmian i dat itp. oraz do korzystania z narzędzia do porównywania różnych wersji plików źródłowych, jeśli nie ma jeszcze wybranego VCS.

Tak jak powiedziałem, jest to okazja, aby przyczynić się do ulepszenia zespołu programistów, który brzmi tak, jakby jakby zgubił się, że tak powiem. Masz okazję wyróżnić się jako wykwalifikowany i kompetentny oraz jako ktoś, kto może dawać przykład. To wszystko są dobre rzeczy, które pomogą ci później w miarę rozwoju kariery.

Witaj w dżungli !

Niestety, często rozpoczęcie pracy w firmie oznacza stawienie czoła takim sytuacjom, chyba że pracujesz dla ustrukturyzowanej i dobrze zorganizowanej firmy, sytuacje te są dość typowe ...

Moja rada to:

1. Rozpocznij naukę i zapoznaj się z: używanym językiem programowania (Clipper / dBase) i środowiskiem (Visual FoxPro)

2. Przeczytaj i przeanalizuj bazę kodu i zacznij ją komentować

3. organizowanie / refaktoryzacja kodu (rozwiązanie problemu zbyt wielu wierszy wykonywanych po kolei)

Problem z podobną bazą kodu jest normalny, ale może stać się wielkim wyzwaniem, próbując poprawić jakość kodu i dać programowi „dotyk”, ulepszając bazę kodu i może sprawiając, że jest to lepszy program ...

Aby odpowiedzieć na twoje pytanie: Tak, ludzie / firmy wszędzie korzystają z infrastruktury, która może być zbudowana na kiepskim kodzie. Zintegrowanie się w takich sytuacjach może być bardzo trudne.

Zeszłego lata pracowałem jako stażysta opracowując aplikację do wykorzystania przez zespół kontroli jakości dołączony do określonego działu. Zespół ds. Kontroli jakości wykorzystał wiele niezależnych skryptów (VBScript, Perl, Bash) do uruchamiania testów w bazach danych i tym podobnych, i chciał połączyć je wszystkie w jedną aplikację. Problem polega jednak na tym, że skrypty były używane gdzie indziej w firmie (dlatego podstawowa funkcjonalność / nazwy zmiennych nie mogły zostać zmienione), a kod był „dodawany” przez prawie 10 lat; narobiło dużo badziewia.

Oto, co możesz z tym zrobić:

1. Poproś o pomoc: Twoi współpracownicy, którzy musieli zajrzeć do tego kodu, prawdopodobnie znają jego osobliwości. To, co jest dla ciebie tępe i mylące, jest dla nich całkowicie w porządku. Poproś o pomoc!
2. Refaktoryzuj, gdy tylko jest to możliwe: jeśli musisz patrzeć na ten kod / utrzymywać go przez dłuższy czas, refaktoryzuj go, kiedy tylko możesz. Nawet jeśli używasz funkcji znajdź i zamień na nazwie zmiennej, każda odrobina pomaga. Firma, w której pracowałem przez ostatnie lato, miała podobny problem ze stosowaniem gównianych nazw zmiennych. Przy każdej okazji mogłem przeprowadzić ich kod przez grzebień o drobnych zębach, zmieniając nazwy zmiennych, optymalizując logikę (grupując różne funkcje razem w 1, na przykład) itp. Rób to samo, kiedy masz taką możliwość!

Tak jak wszędzie, dopóki zewnętrzne funkcje kodu działają poprawnie, nie będzie miało znaczenia, jak działają elementy wewnętrzne.

Zamierzam zrobić kilka komentarzy, które różnią się od wielu respondentów tutaj. Wiele moich komentarzy może być dla ciebie oczywistych, ale i tak musisz je wypowiedzieć.

• Zachowaj ostrożność przy zmianie kodu, którego nie rozumiesz, dopóki go nie zrozumiesz.
• Jeśli pracujesz w środowisku zespołowym, korzystając z kodu, nad którym pracują twoi koledzy, przedyskutuj zmiany z nimi przed ich wprowadzeniem. Nikt nie lubi, aby „samotny rewolwerowiec” wszedł i zmienił kod, który wszyscy znają. Nie oznacza to, że twoje zmiany nie są uzasadnione ani „słuszne”.
• Zdobądź adopcję swoich pomysłów. Zaangażuj wszystkich w swoje pomysły, a następnie możesz wykorzystać umiejętności swojego zespołu do refaktoryzacji, zamiast obciążać się całym obciążeniem.
• Zdobądź wpisowe do zarządzania. Mogą być w stanie przeznaczyć środki na przejście i ponowne uwzględnienie kodu.
• Porozmawiaj z zarządem w kategoriach, które rozumieją o korzyściach wynikających z przefaktoryzowania bazy kodu. Łatwiejszy do utrzymania kod oznacza mniej czasu poświęcanego na rozwiązywanie problemów, dodawanie funkcji itp. Co oznacza opłacalne programowanie. Szybszy czas zawracania itp.

Łatwo jest dodać czyste kodowanie, sugestie dotyczące najlepszych praktyk bez zrozumienia polityki danego środowiska. Ludzie, z którymi pracujesz, mogą nie chcieć zmieniać lub przeznaczać czasu na zmianę bazy kodu, ale spróbuj sprzedać ten pomysł wszystkim, zanim wskoczysz i zmienisz wszystko (co samo w sobie wiąże się z ryzykiem)

Mam nadzieję że to pomoże.

Jedną z rzeczy, które wyróżniają się, jest edytowany komentarz

Każda zmiana w starym kodzie musi być komentowana w kodzie, a także meta informacje (data, programista, zadanie) związane z tą zmianą (stał się to bałagan, są kod z 3 używanymi liniami i 50 starych linii komentowanych). Myślę, że to nie tylko problem z kodem, ale także problem zarządzania oprogramowaniem.

Mam również projekt, w którym odziedziczyłem starszą bazę kodu FoxPro z wieloma opisanymi przez ciebie problemami. Jedną z pierwszych rzeczy, które przedstawiłem w projekcie, było dobre repozytorium kodu źródłowego. FoxPro można zintegrować z SourceSafe, ale korzystanie z tego produktu jest bolesne.

Wziąłem kopię narzędzia scx Paula McNetta http://paulmcnett.com/scX.php i zintegrowałem ją z moim cyklem programistycznym. Bardzo dobrze radzi sobie z wyodrębnieniem binarnego kodu FoxPro do formatu tekstowego, który można następnie umieścić w źródłowym repozytorium, takim jak Subversion, Mercurial, a nawet git. (Projekt SubFox może być przydatny na stronie http://vfpx.codeplex.com .

Te narzędzia udostępniają Historię i pozwalają programistom na utrzymanie kodu. Na pewno potrzeba trochę czasu, aby nauczyć się korzystać z tych narzędzi, ale ponieważ wszystkie są bezpłatne, naprawdę nie ma sensu nie inwestować w nie trochę czasu. (nawet jeśli nie możesz w ten sposób przenieść projektów Job).

Zamierzam zdecydowanie zgodzić się z odpowiedzią funkymushroom. Jeśli jesteś środowiskiem zespołowym, upewnij się, że inni wiedzą, że dokonałeś refaktoryzacji lub reorganizacji kodu, jeśli kiedykolwiek planujesz uzyskać dobre przyszłe zadania.

Z własnego doświadczenia wiem, że chociaż nie jesteś w swoim stylu kodowania, jeśli utrzymujesz kod, który inni również modyfikują i utrzymują, pozostań w stylu istniejącego kodu. Dodawanie komentarzy i wyjaśnień jest w porządku, ale podstawowy układ i konwencje powinny pozostać. Dawni guru / dział w projekcie oczekują, że kod będzie podobny do tego, co widzieli od lat.

Gdy klient krzyczy o błędzie, kierownictwo pójdzie do starych pistoletów, aby jak najszybciej rozwiązać problem. Jeśli te stare pistolety, gdy znajdą się pod presją, okażą się, że „wyczyściłeś kod”, a więc będą musiały spędzić czas na ustaleniu, gdzie się przeniosłeś lub zmieniłeś nazwę tej jednej zmiennej, którą znają, trzeba poprawić, twoje nazwisko w firmie zostanie zmienione na „ błoto".

Kiedy kryzys się skończy, najpierw stary pistolet będzie cię winił za krytyczną aktualizację. Następnie przekonasz się, że możesz utrzymywać wyczyszczony kod tak długo, jak będziesz w firmie. Wreszcie, gdy pojawią się nowe ciekawe projekty, twoi menedżerowie zapytają guru, kto powinien popracować nad projektem, a jeśli raz je nakręcisz, nigdy nie przejdziesz do nowego projektu, dopóki twoja pasza nie zostanie wrzucona na końcu dotrzymać terminu.

Jeśli nauczyłeś się na studiach „właściwego” sposobu kodowania i jesteś teraz na rynku pracy, zapomnij o tym „właściwym” sposobie. To nie są zadania na studia, te projekty nie trwają tylko semestr, mogą żyć przez lata i będą musiały być utrzymywane przez grupę osób o różnym poziomie wiedzy i różnych poziomach zainteresowania najnowszym trendem CS. Musisz być graczem zespołowym.

Możesz być największym programistą w szkole, ale w miejscu pracy, swoją pierwszą pracą, jesteś nowicjuszem z zerową ulgą. Ludzie, którzy od lat zajmują się programowaniem, nie podchodzą do twojej szkoły ani klas, chodzi o to, jak dobrze bawisz się z innymi i ile zakłóceń w ich życiu.

Przez 20 lat wydawało mi się, że wielu programistów asów zostało zwolnionych, głównie dlatego, że żądają robienia rzeczy po swojemu. Jeśli nie przyniesiesz do pracy czegoś bardzo, bardzo, bardzo unikalnego, jesteś wymienny. Być może byłeś na szczycie swojej klasy, ale w przyszłym roku ktoś inny będzie na szczycie swojej klasy i będzie szukał pracy.

Uważam to za podstawową pracę, to utrzymanie pracy, dopóki nie zdecydujesz się zmienić pracy. Aby utrzymać pracę, musisz dobrze bawić się na placu zabaw, za który ktoś inny zbudował i zapłacił.

Wiem, że brzmię negatywnie, ale zawsze jest nadzieja. Gdy zdobędziesz doświadczenie, odniesiesz sukces, zyskasz wpływy i będziesz w stanie przenieść rzeczy na lepszy sposób. Pisząc nowy kod lub nowy projekt, naciskaj na poszukiwane zmiany. Jeśli jest to nowy kod, stare pistolety nie oczekują, że będzie tak, jak go zostawili, a kiedy zobaczą zalety, mogą nauczyć się i dostosować nowy sposób.

Stary system może się zmienić, ale wymaga czasu. Zmiana czegoś wprowadza ryzyko i ryzyko nienawiści biznesowej, a Ty musisz poświęcić czas i pracę, aby firma czuła się komfortowo w związku ze zmianą.