Czy to normalne, że nie mogę zatrzymać w głowie więcej niż trzech błędów przypisanych do mnie, ani nie rozumiem tysiąca linii kodu spaghetti?

Pracuję nad starą bazą kodu, która ... nie jest idealna , w środowisku, które też nie jest. To nie jest najgorsza baza kodów, jaką widziałem w życiu, ale wciąż jest wiele problemów: zerowe testy jednostkowe; metody z tysiącem + linii kodu; niezrozumienie podstawowych zasad obiektowych; itp.

Utrzymanie kodu boli.

1. Za każdym razem, gdy muszę debugować tysiąc wierszy źle napisanej metody ze zmiennymi ponownie wykorzystanymi, jestem całkowicie zagubiony.
2. Niektóre modyfikacje lub refaktoryzacje wprowadziłem błędy w innych miejscach aplikacji.
3. Brak dokumentacji, testów lub obserwowalnej architektury w połączeniu ze źle nazwanymi metodami sprawia, że ​​zapełniam całą dostępną pamięć roboczą. Nie ma już miejsca na wszystkie inne rzeczy, które muszę pamiętać, aby zrozumieć kod, który powinienem zmodyfikować.
4. Ciągłe przerwy w miejscu pracy niepokoją mnie i spowalniają.
5. Nie pamiętam więcej niż dwóch lub trzech zadań na raz bez systemu śledzenia błędów i zapominam o nich wszystkich w weekend.

Wydaje się, że moi koledzy nie mają podobnych problemów.

1. Udaje im się debugować źle napisane metody znacznie szybciej niż ja.
2. Wprowadzają mniej błędów niż ja przy zmianie bazy kodu.
3. Wydaje się, że dobrze pamiętają wszystko, czego potrzebują, aby zmienić kod, nawet jeśli wymaga to odczytania tysięcy wierszy kodu w dwudziestu różnych plikach.
4. Wygląda na to, że nie przeszkadzają im wiadomości e-mail, dzwoniący telefon, ludzie rozmawiają dookoła i inni zadają im pytania.
5. Nie chcą korzystać z systemu śledzenia błędów, który już mamy, odkąd korzystamy z TFS. Wolą po prostu pamiętać każde zadanie, które powinni wykonać.

Dlaczego to się dzieje? Czy są to szczególne umiejętności, które deweloperzy nabywają, pracując ze źle napisanym kodem przez długi czas? Czy mój względny brak doświadczenia ze złym kodem przyczynia się do tych problemów / uczuć? Czy mam problemy z pamięcią?

Tak, to normalne, że na strukturyzowanych ludzi wpływa nieustrukturyzowany kod / środowiska. Twoi koledzy prawdopodobnie lepiej odfiltrowują cały szum tła. Jako cierpiący na migrenę wiem, że moja zdolność do filtrowania środowiska znacznie spada, gdy nadchodzi migrena. Ludzie się różnią.

To samo dotyczy kodu, koledzy prawdopodobnie nauczyli się odfiltrowywać „szum kodu” pochodzący z wielu poziomów abstrakcji w jednej metodzie i opanowali „dzielenie” kodu na większe obszary funkcjonalności.

Po prostu potrzeba czasu, aby dostosować się do bazy kodu, takiej jak ta, którą opisujesz. Twoi koledzy zapewne mieli o wiele więcej czasu, aby się w to rozwinąć i być może wybrali konwencje, wzorce i konstrukcje, które nie wyskakują z „nowicjuszy bazowych kodu”. Chaos może zawierać więcej struktur, niż można sobie wyobrazić. Porozmawiaj ze swoimi kolegami, poproś ich, aby sparowali z tobą trochę czasu i wybrali mózgi na temat tego, jak podchodzą do rozwiązania jednego z przypisanych ci błędów. Kiedy poprosą cię o otwarcie jednostki X, Y lub Z, zapytaj ich, dlaczego ta, a co z tym, mówi im, że może być istotna itp.

Zagubienie się metodą tysiąca linii jest normalne. Zaatakuj go za pomocą dobrego składanego edytora i dodając komentarze, aby podzielić różne części na funkcje i / lub procedury bez faktycznego robienia tego. Pomocne może być również drukowanie materiałów i używanie starego zakreślacza.

Refaktoryzacja bez siatki bezpieczeństwa testów jednostkowych to zastrzelenie się w stopę. Nie rób Po prostu nie.

Nikt nie wymaga od ciebie przechowywania wszystkiego w pamięci. Jeśli twoi koledzy nie chcą lub nie potrzebują systemu błędów, po prostu napisz zadanie przypisane do ciebie na własnej liście rzeczy do zrobienia i pisz notatki, kiedy / po rozmowie z kimś na temat szczegółów twoich zadań.

widzę 3 główne punkty:

punkty 1, 2 i 3 wynikają z faktu, że twoi koledzy są po prostu bardziej doświadczeni w bazie kodu, co oznacza, że ​​znają jej dziwactwa. Oznacza to, że używają pamięci długoterminowej do procesu debugowania i mogą pamiętać, że doXYZ faktycznie robi UVW, ale nigdy nie zmieniono jego nazwy z powodów historycznych. jednak jeśli kiedykolwiek zaczną kodować na nim kilka miesięcy, zaczną odczuwać twój ból.

w przypadku punktu 4 opierającego się na przerwach, nie pozwól, aby nie pilne sprawy wyprowadziły cię ze strefy , powrót do niej po przerwie zajmuje dużo czasu; ustaw komunikator firmowy na zajęty, spróbuj zaplanować długie bloki (pełne popołudnia) samego kodowania

na punkt 5 sekund utwórz arkusz z błędami, nad którymi obecnie pracujesz, jako osobistą listę rzeczy do zrobienia (lub skorzystaj z możliwości zarządzania zadaniami w swoim IDE), chętnie się założę, że niektórzy z twoich kolegów robią to samo

Nie brzmi dla mnie jak problemy z pamięcią. Wygląda na to, że twoje nawyki / tendencje w pracy nie pasują do tego, co napotykasz, i zbyt dużo myślisz o swoich współpracownikach, a nie o sobie.

1. Metoda tysiąca linii - wszyscy zgubią się, chyba że po prostu nad tym popracują. Mogą być szybsze w podnoszeniu go lub odzyskiwaniu. Nie możesz tego zmienić inaczej niż poprzez doświadczenie, a może nawet wtedy.

2. Refaktoryzacja wprowadzająca błędy, cóż, to zawsze ryzyko. Możesz spróbować opracować test jednostkowy, aby uwzględnić to, co zmieniasz, zanim to zrobisz, ale może to nie być dozwolone przez kierownictwo (prawdopodobnie nie, lub byłoby to już zrobione). A testy jednostkowe nie są magią, wciąż mogą coś przeoczyć, wciąż możesz wprowadzać błędy. Możliwe, że po prostu nie refaktoryzują. Powraca to do (1), prawdopodobnie starają się skupić na tym, co należy naprawić, co oznacza, że ​​docierają do punktu szybciej, ale przegapiają większy obraz i potrwa dłużej, aby naprawić kolejną rzecz w tym tysiącu bałaganu na linii.

3. Stwórz to, czego potrzebujesz, aby wykonać zadanie. Jeśli oznacza to utworzenie schematu blokowego lub innej dokumentacji, zrób to. Nie ma znaczenia, czy tego potrzebują, czy nie, i czy używają go po jego utworzeniu.

4. Przerwy spowalniają wszystkich. Skupienie się na tym spowolni bardziej. Zaakceptuj to i postaraj się jak najszybciej wrócić do rowka.

5. Pamiętając o dwóch lub trzech błędach nie jest źle, trzy lub cztery byłyby lepsze, ale zamiast próbować to poprawić, poddaj się i zapisz. Kawałek papieru, tablica, tfs, excel, słowo lub notatnik - po prostu zapisz. Założę się, że to robią twoi koledzy. Albo to, albo naprawiając losowo.

Programowanie nie polega na idealnej pamięci i nie jest w stanie ignorować rozproszeń - skupienie się na tym to tylko rozproszenia, które tworzysz.

CAVEAT / UPDATE: Po przeczytaniu poniższej odpowiedzi poczułem, że może być nieco zbyt ostro. Nie moją intencją jest to, że środowisko, które opisujesz, jest okropne i wpłynęłoby na większość ludzi (prawdopodobnie cierpią na to nawet lepsi programiści, ale są „lepsi” w porównaniu z innymi w tym samym środowisku). Moja odpowiedź jest tylko refleksją punkt po punkcie w twoich pytaniach, przy założeniu, że środowisko się nie zmieni (nawet jeśli powinno).

Odpowiedź całkowicie pozytywna:

1) To zależy od doświadczenia w technologii, w utrzymaniu aplikacji (więcej, jeśli jest źle zaprojektowana), a nawet w określonych częściach aplikacji. Zależy także od twoich problemów z koncentracją (numer 4)

2) Jest taki sam jak numer 1, ale używa innej miary. Ta sama odpowiedź

3) noteblock i długopis. Lub dokument Word / Excel. Nie tak trudne do rozwiązania.

4) jest to osobisty problem koncentracji. Nie jestem jednak pewien, czy samemu możesz to poprawić.

5) korzystanie z systemu biletów lub nie powinno być podejmowane przez programistów, ale przez kierownika projektu. Zapytaj jego opinii / przedstaw swoje punkty. Jeśli jest przeciwko temu, noteblock i pióro ponownie.

Przeszedłem już przez taką sytuację i na podstawie tego doświadczenia mogę powiedzieć, że twój problem nie jest związany z pamięcią i że masz na myśli coś (z całą pewnością niezwiązane z pracą), co sprawia, że ​​jesteś stresujący i powstrzymujesz się od koncentracji 100 % na dane zadanie.

Pierwszym krokiem jest oczyszczenie umysłu z tych rzeczy, gdy siedzisz przy biurku.

Ten stres może również wzrosnąć, ponieważ czujesz, że masz zaległości w zakresie wydajności, więc spróbuj porozmawiać ze swoimi współpracownikami i zapytaj ich o wskazówki na temat ich podejścia do refaktoryzacji.

Wreszcie, nie czuj się zawstydzony, jeśli musisz zapisać problemy, które rozwiązałeś i / lub pracujesz teraz (nie musi to być wyrafinowany system śledzenia błędów), lepiej być pewnym, ponieważ czytasz to z twoje notatki niż stwierdzenie tego z czubka głowy, nie będąc w 100% pewnym