Jak przezwyciężyć własne błędy w kodowaniu, gdy przekazuje się starszy kod? [Zamknięte]

22

Jako programiści często jesteśmy dumni z naszych umiejętności i bardzo mocno oceniamy, co to jest „dobry” i „zły” kod.

W którymś momencie naszej kariery prawdopodobnie mieliśmy jakiś system spadków na kolanach i myśleliśmy: „Boże, ten kod jest do kitu!”. ponieważ nie pasowało to do naszego wyobrażenia o tym, jaki powinien być dobry kod, pomimo faktu, że mógł on być doskonale funkcjonalnym i łatwym do utrzymania kodem.

Jak przygotowujesz się mentalnie, próbując obejść pracę innego programisty?

Bryan M.
źródło
2
wow ... to pytanie jest teraz dla mnie bardzo ważne.
WalterJ89,
1
Jeśli nie jest zepsuty, nie naprawiaj go. :-)
richard
Rzeczy, których nigdy nie powinieneś robić i Big Ball Of Mud powinny być obowiązkową lekturą na ten temat dla wszystkich programistów.
Jan Hudec
możliwy duplikat pracy nad kodem innej osoby
gnat

Odpowiedzi:

31

W przypadku dowolnej bazy kodu starszego, poprawnym sposobem przygotowania się mentalnie do radzenia sobie z nią jest rozpoczęcie od napisania testów jednostkowych .

Niezależnie od tego, czy jest do bani, czy nie, najpierw musisz mieć pewność, że możesz to zmienić bez niszczenia rzeczy!

Jeff Atwood
źródło
6
+1. Inne programy często zależą od błędów w istniejącym kodzie, nie wspominając o dziwnych sposobach działania. Zanim zaczniesz się z tym bawić, zrozum to!
Alex Feinman,
Raz miałem ten problem. Naprawiłem błąd w naszych bibliotekach wewnętrznych, ale okazało się, że wiele ważnych kodów było zależnych od tego nieprawidłowego zachowania. Yikes.
Jonathan Sterling
Czasami pisanie tych testów może być bardzo trudne. Ale czasami czasami można znaleźć gdzieś luźny wątek , przetestować to, a następnie szerzyć infekcję testową. Być może będziesz musiał ponownie przetestować i przetestować kilka rzeczy, zanim dojdziesz do elementu, który naprawdę chciałeś zmienić.
Frank Shearar,
5
Zakłada to, że Twoja firma stosuje lub nawet rozumie testy jednostkowe. Przez większość czasu nie ma testów kodu, dokumentacji i krótkiego terminu na jego integrację / naprawę / modyfikację, więc nie można po prostu „zacząć pisać testów jednostkowych”.
Wayne Molina
2
W przypadku starszych kodów często łatwiej jest rozpocząć od automatycznych testów regresji. Testy jednostkowe zakładają, że w kodzie są izolowane jednostki, które można testować niezależnie - musisz mieć szczęście, aby znaleźć tego rodzaju starszy kod.
Doc Brown
30

Nie mogę ci powiedzieć, ile razy mówiłem „Och, to jest całkowicie złe”, przepisałem go, a potem dowiedziałem się, dlaczego ten kod został napisany w ten sposób. Zwykle jest to jakiś nieoczywisty niepisany / nieudokumentowany wymóg. Przynajmniej tak jest w starszym kodzie, nad którym obecnie pracuję.

Frank Shearar
źródło
3
Zdarzyło mi się kilka razy. Czasami lepiej po prostu zostawić to w spokoju
TheLQ
4
A jeśli się dowiesz, bądź miły dla następnego faceta i napisz komentarz!
Frank Shearar
11

Poczekaj, aż będziesz w okolicy wystarczająco długo, aby napotkać swój gówniany kod. To upokarzające doświadczenie i część procesu uczenia się. Tęsknię za czasem, kiedy wszystko wiedziałem.

Myślę, że Fosco miał świetny punkt, aby móc umieścić to w kontekście potencjalnych ograniczeń czasowych i funkcjonalnych. Czasami musisz zmusić coś do działania.

I wreszcie zrozumcie, że właśnie dlatego macie pracę.

JeffO
źródło
4
Zdarza mi się to cały czas. Nieustannie spoglądam wstecz na stary kod i myślę sobie: „Kto napisał to badziewie? O tak… zrobiłem”. Myślę, że to pokazuje, że rozwijasz się jako programista, jeśli możesz przyznać, że kod, który napisałeś w przeszłości, jest zły. Jeśli spojrzysz na nią wstecz i powiesz „Tak, wygląda mi dobrze”, oznacza to, że to cholernie dobry kod, albo nie postępujesz. : P
Jasarien
7

Śmiej się z tego, staraj się nie osądzać go zbytnio i po prostu przejdź przez to. Nie jest dobrze być prawdziwym nazistą kodem ... Zdecydowanie istnieje coś takiego jak „wystarczająco dobry”, a nawet „wystarczająco dobry w tym czasie”. Wiele razy coś jest opracowywane lub zabandażowane, aby naprawić kryzys, a potem nigdy nie wracane.

Jeśli jest naprawdę źle, sprawdź, czy możesz uzasadnić jego ponowne napisanie. Jeśli nie jest to ważne, po prostu wejdź i wyjdź.

Fosco
źródło
7

Wybierz bitwę. Poznaj różnicę między „nie napisałbym tego w ten sposób” a „stwarza to poważne wyzwanie w utrzymaniu lub wsparciu”

AShelly
źródło
Ukradnę tę odpowiedź. :-)
cringe
4

Często uważam, że warto poczuć, co oryginalni twórcy uważali za dobry.

Poszukaj wzorców i motywów do tego, co zrobili i często zdarza się, że były powody niektórych dziwnych decyzji w pierwszej kolejności.

Czasami okazuje się, że pierwotny twórca był naprawdę zły, ale masz pojęcie, jaki zło sprzedawali wtedy.

Tak czy inaczej, po zrobieniu tego powinieneś mieć lepszy obraz tego, od czego możesz zacząć od nowa pisać lub jak wyglądałaby szybka poprawka bez konieczności refaktoryzacji wszystkiego.

Co najważniejsze, nie zakładaj od razu, że tylko dlatego, że jest brzydka, jest zła. Nic nie sprawia, że ​​wyglądasz bardziej głupio niż spędzanie czasu na modernizowaniu czegoś, aby dowiedzieć się, że jest mniej zdolny niż oryginał.

Rachunek
źródło
3

Jeśli mam czas , zaatakuję go i zabiję źle napisany kod.

To jest wojna.


źródło
3

Zawsze rozumiem, że ten brzydki kod jest kodem, który widział wiele debugowania, z wieloma subtelnościami, które nie są widoczne po pobieżnej inspekcji. Jeśli go zastąpię lub głęboko przeprojektuję, muszę upewnić się, że rozumiem absolutnie każdy aspekt działania kodu. Jeśli nie mam czasu, aby dojść do sedna, muszę podjąć minimalne ryzyko, dokonując możliwie najmniejszej zmiany, aby osiągnąć moje cele.

Zwykle dokonam drobnej poprawki / zmiany i zaproponuję funkcję do późniejszego rozwoju, która usprawiedliwiłaby przejście do sedna rzeczy i przefakturowanie całości. Następnie staram się zignorować kod, dopóki funkcja nie pojawi się na mapie drogowej.

Joeri Sebrechts
źródło
3

Kiedy starszy kod ma więcej niż kilka lat, mógł zostać napisany w ten sposób z powodu ograniczeń w języku lub systemach operacyjnych itp., Które istniały w momencie pisania kodu. Hej, teraz wygląda źle, ale czy wtedy było źle? Staram się założyć, że programista miał powód tego, co zrobił. Ten powód może już nie obowiązywać, ale zakładanie, że był taki, zamiast ogólnej niekompetencji (młodzi programiści będą myśleć o tym samym kodzie za 5 lat, a może nawet mniej), sprawia, że ​​jesteś mniej zły z tego powodu. Jeśli to działa i nie ma z tym żadnych problemów, pielęgnuj ten starszy kod, bez względu na to, jak brzydki, ponieważ pozwoli ci to rozwiązać bardziej ekscytujące problemy.

HLGEM
źródło
Ach, odwieczne pytanie DLACZEGO ...
1

W przeszłości, kiedy nie miałem czasu sikać na czyjś kod i wprowadzać go w „mój” styl, musiałem uciekać się do tego, że kierowałem się bardzo zadaniami:

Co próbuję dodać do tego kodu / fix / make work?

Czy to, co robię, dąży do tego celu? Jeśli nie, przestań to robić i powróć do ostatniego razu, kiedy wprowadzałem zmiany zorientowane na zadania.

Czy skończyłem z tym zadaniem? Jeśli tak, przestań majstrować przy kodzie, nawet jeśli wygląda na to, że został napisany przez nieświadomą marsjańską formę.

Alex Feinman
źródło
1

Jeśli nie jesteś przygotowany na posiadanie kodu i niezbędnych poprawek w przyszłości, nie dotykaj go. Pokonasz tendencję do chęci naprawienia czegoś, gdy zepsułeś coś, czego nie napisałeś, ponieważ nie przestudiowałeś go wystarczająco dobrze, zanim się zanurzysz, i zajmuje Ci to 2 dni oraz ćwiczenie, aby znów zacząć działać .

Nie zrozumcie mnie źle ... istnieją uzasadnione powody do zmiany kodu, ale jeśli firma wymaga, aby kod działał, a ty „naprawiasz” go, nie znając konsekwencji przed wskoczeniem, prosisz o świat bólu .

CokoBWare
źródło
1

Trochę refaktoryzacja może być przydatna, ale należy zachować szczególną ostrożność przy zmianie każdego drobnego aspektu tego, jak kod faktycznie zachowuje się, chyba że zrozumiesz, dlaczego takie zachowanie istnieje i na co wpływa. Niestety, kod, który najbardziej go potrzebuje, jest czasem najtrudniejszy do zmiany bez dotykania zachowania, chociaż zwykle można go wyprostować lub przynajmniej skomentować.

David Thornley
źródło
0

Obecnie pracuję prawie wyłącznie nad starszym kodem i zawsze myślę: „O kurwa, o czym oni myśleli?” . Następnie zaczynam pisać testy jednostkowe dla kodu i to jest punkt, w którym naprawdę muszę analizować przepływ sterowania i zależności.

Czasami nie jest możliwe łatwe napisanie testów jednostkowych. Ale kiedy próbuję, otrzymuję informacje o kodzie i zrozumiem, dlaczego został napisany tak, jak jest. Czasami to udowodni, że kod jest naprawdę bałaganem, czasem rozumiem proces myślowy oryginalnych programistów i mogę dodać użyteczną dokumentację lub przepisać kawałek kodu, gdy chcę dodać nową funkcjonalność.

Dla mnie pomaga myśleć, że mój kod będzie wyglądał tak samo dla siebie, kiedy wrócę do niego za 12 miesięcy .

warować
źródło
0

Z doświadczeniem przychodzi osąd, aby wiedzieć, kiedy kod jest naprawdę zły, a kiedy jest napisany w innym stylu. Jeśli jest on w pełni funkcjonalny i łatwy w utrzymaniu, a zakres testów automatycznych jest dobry , nie jest źle i wystarczy otworzyć umysł. Prawdopodobnie się czegoś nauczysz. Zły kod nie działa i nie można go naprawić.

Oto kilka znaczników naprawdę złego kodu:

  • Duże bloki logiki zostały zduplikowane zamiast refaktoryzowane.
  • Zależności kołowe między klasami lub pakietami
  • Wysokie sprzęgło; niska kohezja
  • Nieużywane zmienne, zapisywanie do zmiennych, które nigdy nie są odczytywane, nieosiągalny kod.
  • Reimplementacja standardowych funkcji biblioteki, np. Formatowanie daty.
  • Niepotrzebnie złożona logika; tj. 50 linii kodu, przy czym 10 dobrze by to zrobiło.
  • Brak komentarzy opisujących cel klas lub metod.
  • Wprowadzające w błąd komentarze.

Brak zautomatyzowanych testów nie oznacza, że ​​kod jest zły, ale oznacza, że ​​projekt jest zły.

To nie jest kwestia gustu; praktyki te powodują, że utrzymanie programu jest znacznie droższe.

Jak się przygotowujesz?

Zaakceptuj fakt, że potrzeba czasu, aby móc pomyślnie pracować nad nową bazą kodu. Jeśli jest „w pełni konserwowalny”, a zasięg testu jest wysoki, zajmuje to mniej czasu, ale nadal nie nastąpi to natychmiast. Jeśli kod jest zły, pierwszą rzeczą, którą robię, jest ostrzeżenie interesariuszy, że jest w złym stanie, a początkowy postęp będzie powolny. Jeśli są sceptyczni, potwierdzam swoje twierdzenie, pokazując próbkę problemów w rzeczywistym kodzie i wyjaśniając, jak różni się on od najlepszych praktyk branżowych.

Kevin Cline
źródło