Tak więc na podstawie dostarczonych szczegółów OP brzmi, jakby pytanie brzmiało: „jak nauczyć się własnego kodu, aby zapytać go o X lub wyjaśnić Y, mogę szybko odpowiedzieć”.
Podczas kodowania musisz poświęcić trochę czasu na naukę i zrozumienie własnego kodu. Może to być to, co twój TL próbuje ci przekazać w niewielu słowach. Będąc TL obecnego projektu, w ciągu ostatnich 11 miesięcy dokonałem wielu recenzji kodu i zauważam, że niektórzy programiści szukają „przykładowego kodu” w naszej własnej bazie kodu lub gdzie indziej (google itp.) i skopiuj / wklej. Osobiście nie mogę tego znieść, ponieważ podczas gdy ich kod przechodzi proste testy jednostkowe, nie rozumieją, co faktycznie robi, więc nigdy nie mamy gwarancji, że nie ma • niektóre przypadki graniczne lub spodziewane warunki awarii, które mogą wystąpić.
W następstwie poprzedniego oświadczenia, jeśli musisz skopiować / wkleić, spróbuj skopiować / wklej tylko kod, który wcześniej napisałeś i który rozumiesz. Z pewnością można „pożyczyć” pomysł innych ludzi, ale w takim przypadku przepisać kod po linii, ponieważ podczas pisania będziesz lepiej rozumieć, co robi. Jeśli korzystasz z zewnętrznych interfejsów API, nawet jeśli masz przykład, który używa tego interfejsu API, i tak poświęć kilka minut na znalezienie odniesienia i dowiedz się, jak działa ten interfejs API. Nie zakładaj tylko, że jeśli wcześniej działał, będzie działał również w twojej sytuacji.
Przeczytaj i naucz się kochać zasadę SUCHEGO . Wiele razy to, co kusi cię do skopiowania / wklejenia, może być umieszczone we wspólnej lokalizacji (osobna funkcja, osobna klasa, osobna biblioteka ...)
Przeczytaj i naucz się kochać SOLIDNE zasady, a gdy już to zrobisz, przejrzyj KISS, o którym wspomniał już mouviciel. Wszystkie te zasady mają na celu stworzenie bardzo zwięzłego, czystego i modułowego kodu. Jeśli masz w nich duże klasy i duże funkcje, to o wiele trudniej będzie znaleźć rzeczy, a na dodatek spróbować wyjaśnić, co robi kod. Z drugiej strony, jeśli podążasz (lub przynajmniej próbujesz podążać) SRP i czynisz każdą klasę / funkcję odpowiedzialną tylko za jedną rzecz, twój kod będzie mały i bardzo czytelny.
Odbierz kopię Clean Code . Bardzo dobra książka. Mówi o pisaniu kodu, który jest zrozumiały i łatwy do odczytania, utrzymania i rozszerzenia. Jeśli ćwiczysz pisanie łatwego do odczytania kodu, nie powinieneś mieć problemów z czytaniem własnego kodu w recenzjach kodu. I to jest zabawne, poprosiłem ludzi, aby przeczytali własny kod lub po prostu powiedzieli mi, co reprezentują zmienne, i nie mogli odpowiedzieć, mimo że napisali ten kod (zupełnie nowe klasy, a nie starsze wersje) zaledwie tydzień temu . Dobre nazewnictwo ma długą drogę.
Jeśli po wszystkich uproszczeniach i refaktoryzacji nadal masz funkcję, która musi wykonać jakiś algorytm, który nie jest bardzo widoczny, poświęć trochę czasu i napisz blok komentarza w tej funkcji wyjaśniającej algorytm. Nie tylko będzie to pomocne, gdy będziesz musiał zmodyfikować tę funkcję za 2 miesiące, ale jeśli wpadniesz w zasadzkę podczas przeglądu kodu, będziesz mógł po prostu przeczytać to, co napisałeś.
Jeśli po wszystkich powyższych elementach nadal masz problemy? jesteś nowy w zespole i zostałeś poproszony o pracę z wieloma starszymi kodami? W takim przypadku może być tak, że twój TL jest A $$ i możesz być proaktywny, prosząc go przed spotkaniem, aby poszedł spokojnie i nie marnował czasu wszystkich zaangażowanych. Gdy do zespołu dołączają nowe osoby, TL musi mieć wystarczającą cierpliwość, ponieważ praca na nowej platformie, nowym produkcie, nowych osobach, nowym środowisku wymaga dużej koncentracji od nowej osoby, a na początku tej osobie brakuje niektórych szczegółów. Działa zgodnie z przeznaczeniem i twój TL powinien to zaakceptować.
Jeśli mimo wszystko powyżej, nadal masz wrażenie, że masz okropne recenzje kodu. Porozmawiaj ze swoim TL. Czasami ludzie czują się źle z powodu natury spotkań związanych z recenzowaniem kodu, gdy w rzeczywistości TL jest z Ciebie w pełni zadowolony. Kiedy robię recenzje kodu, moim celem jest podkreślenie, co należy zmienić, upewnienie się, że rozumiesz zmiany i kontynuacja. Wiele razy nie mam czasu na uprzejmość, a niektórzy się bronią i próbują odpowiedzieć na każdy z moich komentarzy. W takich sytuacjach spotkanie przeglądu kodu kończy się, więc mam tendencję do ich przerywania i kontynuowania. Ogólnie po spotkaniu rozmawiałem z nowymi facetami, aby upewnić się, że rozumieją proces i że nie jest to nic osobistego. Po kilku recenzjach kodu ludzie są na ogół znacznie wygodniejsi.