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

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?

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!

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ę.

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ę.

Ś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ź.

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”

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ł.

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

To jest wojna.

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.

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.

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ę.

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 .

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ć.

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 .

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.