Jak radzisz sobie ze zrozumieniem abstrakcji w kodzie?

Przyglądając się nowej bazie kodu, chciałbym zacząć od podejścia oddolnego.
Gdzie rozumiem jeden plik, a następnie przechodzę do następnej abstrakcji.
Ale często zapominam, co robi abstrakcja niższego poziomu.

Będę w tym momencie, w którym znajdę się w niemal nieskończonej pętli, wracając do plików, które wcześniej w pełni zrozumiałem, a następnie próbuję je ponownie nauczyć; próbując żonglować wieloma innymi abstrakcjami, które łączą się ze sobą w mojej głowie.

Czy istnieje lepsza strategia radzenia sobie z tą sytuacją?

Czy powinienem po prostu zapomnieć o szczegółach niższego poziomu i wziąć je za pewnik? Ale nawet wtedy konieczne jest wcześniejsze zrozumienie abstrakcji niższego poziomu, aby zrozumieć, co robi obecna abstrakcja.

Konkretne programowanie jest impulsem do przyciągania szczegółów do siebie, abyś mógł je wszystkie przybić w jednym miejscu. Wszyscy zaczynamy w ten sposób i trudno jest odejść.

Programowanie abstrakcyjne to zdecydowanie „zapominanie o szczegółach niższego poziomu”. Czasami nawet szczegóły na wysokim poziomie. Odsuwasz szczegóły i pozwalasz sobie na coś innego. Podstępną rzeczą jest to, że robiłeś to przez cały czas. Czy naprawdę rozumiesz, co się dzieje między print "Hello world"tym, co pojawia się na ekranie?

Najważniejszą rzeczą, której należy wymagać, gdy próbujesz uwolnić się od tych szczegółów, są dobre nazwiska. Dobre imię gwarantuje, że nie będziesz zaskoczony, gdy zajrzysz do środka. Dlatego nie byłeś zaskoczony, że printumieściłeś coś na ekranie i tak naprawdę nie obchodziło Cię, jak to zrobić . foo "Hello world"byłaby inna historia.

Ponadto poziomy abstrakcji powinny być spójne. Jeśli jesteś na poziomie, który polega na obliczaniu pi, nie powinieneś martwić się także o wyświetlanie pi. Ten szczegół wyciekł do abstrakcji, do której nie należy.

Niższe, wyższe lub z boku detale, które nie dotyczą jedynej rzeczy, o której myślę w tym jednym miejscu, mogą albo całkowicie zniknąć, albo przynajmniej ukryć się za dobrym imieniem.

Więc jeśli naprawdę masz problemy z podskakiwaniem z pliku do pliku, zaryzykuję, że ktoś utkwił ci w złych nazwiskach lub nieszczelnych abstrakcjach.

Naprawiam to czytając palcami. Kiedy mam przyzwoite testy w tym bałaganie, dokuczam obowiązkom, nadaję im jasne nazwy, które pozwalają uniknąć niespodzianek, i pokażę to komuś innemu, aby upewnić się, że nie żyję w świecie fantasy.

Najwyraźniej nie jestem sam, jeśli chodzi o pracę w ten sposób:

Ilekroć pracuję nad nieznanym kodem, zaczynam wypakowywać metody. Kiedy to robię, szukam kawałków kodu, które mogę nazwać - a następnie rozpakować. Nawet jeśli w końcu wprowadzę metody, które wyodrębniłem później, przynajmniej mam sposób na tymczasowe ukrywanie szczegółów, aby móc zobaczyć ogólną strukturę.

Michael Feathers - Orange Code

Na dole jest kilka aktualizacji tego, jak mi się to udawało co kwartał, i myślę, że są one cenne.

Dobre nazewnictwo.Lub, jeśli jest to kod innej osoby, próba przypisania dobrych nazw / obowiązków na podstawie nawet złych nazw w klasach / funkcjach tego systemu, aby miało to sens w mojej głowie. Kiedy to nastąpi, implementacje niskiego poziomu stają się o wiele łatwiejsze do zapamiętania.

To wszystko co mam. Na tej stronie jest wielu purystów, którzy przysięgają, że Bóg wie, jakie wzory lub przedmioty dowolnego rodzaju, ale dobre nazewnictwo zaprowadzi cię daleko. Zrobiłem więcej niż dobrze sam, tworząc minimalnie udokumentowany / dobrze nazwany / dobrze oddzielony kod i nigdy mnie nie gryzł, nawet jeśli mój kod był używany w wielu miejscach przez wiele osób, ale jedną rzeczą, którą zrobiłem dobrze, było marnowanie dużo czasu na dobre nazywanie, dobre komentarze i schematy wyjaśniające przepływ mojego kodu. Wdrożenie niskiego poziomu jest konieczne, aby zrozumieć, czy chcesz głęboko rozwinąć mój kod. Dobrze napisany kod można rozszerzyć w rozsądny sposób, więc jest dobrze, że ktoś lub ty nie rozumiesz / nie pamiętasz implementacji niskiego poziomu.

Jeśli interesuje Cię trochę kontrowersji, które zarówno ludzie w mojej pierwotnej dziedzinie, jak i ja wiedzą, że są prawdą, ale jeśli posłuchasz tego, co tu zapisano, nauczysz się zgadzać i nie zgadzać się z tą odpowiedzią czytaj dalej:

Ale jest tu jeszcze jedna kwestia - puryści. Usłyszysz dobrze sformułowane odpowiedzi i ideologie, które są rozsądne i całkowicie logiczne, w rzeczywistości nie ma w nich nic złego. Ale nie musisz ich przestrzegać, w rzeczywistości mogą one działać na twoją niekorzyść.

Moi przyjaciele pracowali z dużymi systemami i po prostu śmieją się z ludzi, którym troszkę za bardzo zależy na konwencjach i wzorach, i nie bez powodu, ja też to zrobię - mogę znaleźć swoje uzasadnienie w mojej głównej dziedzinie analizy danych, ponieważ nie jestem tak doświadczonym programistą: większość rzeczy, które uważasz za ważne, nie mają znaczenia, i w tym sensie istnieje silna korelacja z twoim ego.Często jednostka, ze względu na swoje ego, zdobyła wiedzę, którą najprawdopodobniej źle zrozumiał ze względu na swoje uprzedzenia, które są obecnie wzmacniane przez autorytet, który, jak myśli, powiedział „to samo, co zrobiłem”. Jest to bardzo dobrze znana pułapka, w którą nigdy nie powinieneś wpaść. Nie oznacza to, że nie używa go we właściwy sposób lub dla większego dobra, ale często to, co ludzie zrobią, to obietnica, że ​​cokolwiek mówią, będzie złotą nagrodą.

Więc co możesz zrobić?

Wyjaśnij swój kod współpracownikowi i zapytaj go, czy ma sens z punktu widzenia wysokiego poziomu.

Tylko to się liczy. Oczywiście każdy, kto czyta czyjś kod, zawsze będzie miał fiestę Alt-Tab, aby zobaczyć implementację pewnych rzeczy, ale to nie ma znaczenia, jeśli ktokolwiek czyta twój kod, rozumie twój system na wysokim poziomie i rozumie „dlaczego coś się dzieje. „(znowu, niekoniecznie wiedząc, w pełni„ jak to się dzieje ”), wtedy jesteś złoty.

Nie mówię, że napisz i napisz bzdury, które nie są wydajne lub niczego nie szanują, ale mówię:

1) Można zapomnieć. Z czasem będziesz lepiej czytać kod, z którym pracujesz. Jeśli czytany kod wymaga znajomości implementacji niskiego poziomu na dobrym poziomie, oznacza to, że kod jest źle napisany i odtwarza to, co powiedziałem wcześniej: czy współpracownik cię rozumie?

2) Świat jest pełen bardzo inteligentnych ludzi, którzy nie są zbyt mądrzy. Często też są bardzo emocjonalni i mają skłonność do wzmacniania uprzedzeń ze strony sił zewnętrznych. Są bardzo dobrzy w tym, co robią, ale jako aktorzy rozpowszechniania informacji zapominają: idee / informacje, nawet jeśli są poparte „logiką”, mają kontekst tego, kto je wysyła, co jest kluczowe dla zrozumienia, czy to informacje też są dla Ciebie przydatne. To, co ma dla ciebie sens, może mieć sens dla innych i bardzo by się podobało, ale informacje nie powinny być traktowane jako absolutne, a jeden raz jeszcze powinien rozważyć, a przynajmniej spróbować zrozumieć kontekst, z którego pochodzi i porównać z jego własny kontekst, aby sprawdzić, czy pasuje. To naprawdę to samo, co miliarderzy, którzy dają nam te „fragmenty wiedzy, aby iść do przodu”

W skrócie: napisz zrozumiały kod i zdaj sobie sprawę, że wciąż jest dyskusyjny tam, gdzie potrzebujemy tyle wzorców / klas i rafinerii, jak niektórzy twierdzą. Po obu stronach kłótni są bardzo mądrzy ludzie i powinno to tylko wzmocnić pomysł robienia wszystkiego, co działa dla twojego zespołu w rozsądny sposób - nie utknij na drobiazgach, które nie mają znaczenia, zrozumiesz je pamiętaj, że żyjesz w niezwykle konkurencyjnym świecie, w którym najważniejsze jest wyczucie czasu:

Czas na sukces startupów.

Przeznacz swój czas i zasoby w znaczący, chciwy sposób.

Oto edycja, 6 miesięcy później:

To była szalona podróż. Nigdy nie myślałem, że tylko separacja / dobre nazewnictwo i dokumentacja może w zasadzie pozwolić ci podłączyć wszystko z bazy kodu. Musiałem ponownie napisać dużo kodu, aby przyśpieszyć go z nowymi zmianami i zrobiłem kawał dobrej roboty w ciągu 2-3 dni. Mogę śmiało powiedzieć, że nie wszędzie śledziłem SOLID z powodu braku wiedzy ani najlepszych praktyk, i mogę powiedzieć, że mam dług techniczny, ale nie za bardzo. Oddziel, nazwij dobrze i dokumentuj, pozwoli ci to zmienić kod w mgnieniu oka, gdy w końcu uświadomisz sobie, jak głupi jesteś.

Nie zrozum mnie źle: jeśli napiszesz swój ściśle powiązany kod, będziesz cierpieć wiele, bez względu na to, czy nienawidzisz SOLID, czy nawet zrozumienie i zastosowanie go na poziomie podstawowym pozwala na świetne oddzielenie, które, szczerze mówiąc, jest jedyna rzecz, w której OOP naprawdę pomaga. OOP miał również dotyczyć ponownego wykorzystania kodu i tak się dzieje tu i tam, tak naprawdę nie możesz ponownie użyć wielu tworzonych obiektów, więc skup się na upewnieniu się, że twój system jest dobrze oddzielony. Kiedy osiągniesz dojrzałość i załóżmy, że wujek Bob przychodzi i kieruje twoim projektem, powie „Ok, to jest głupie jak diabli, ale przynajmniej wszystko jest oddzielone, dobrze nazwane i udokumentowane, więc przynajmniej wiem o co w tym wszystkim chodzi " (Mam nadzieję). Dla mnie to działa. Mój LOC ciągle się zmienia, ale w chwili pisania tego tekstu jest to 110 tys. Linii kodu, 110 tys. Linii wykonania kodu, które działają w harmonii dla jednej osoby, to dużo.

Oto zmiana, 3 miesiące później, na 8-miesięcznym kodzie, który refaktoryzuję:

To wszystko ma sens. Mogę teraz wziąć to, co wtedy napisałem, koncepcyjnie i odświeżyć kod z nowymi pomysłami, ponieważ doskonale rozumiem, co się dzieje i dlaczego działa z powodu schematów / dobrego nazewnictwa i komentarzy. Dawno temu napisałem jakiś kod, że nie dbałem o dobre nazywanie i tak dalej, i przebranie go przez ból. Teraz zastanawiam się, jaki może być następny krok wyjaśniania mojego kodu.