Jak mogę poprosić mojego szefa (w uprzejmy sposób) o skomentowanie jego kodu?

Uczę się od mojego szefa (właśnie skończyłem szkołę i chciał kogoś z małym doświadczeniem programistycznym, więc wybrał mnie, aby mnie wyszkolić w zakresie tego, w czym ta firma się specjalizuje) i zaczął pracować z aplikacjami ASP.NET MVC , niektórymi HTML i CSS . Nie mam nic przeciwko projektowaniu stron internetowych, które mi daje (jest to dość proste do zrozumienia bez wyjaśnień).

Ale na przykład zleca mi zadanie związane z ASP.NET MVC, wyjaśnia to bardzo dobrze. Ale nic nie wyjaśnia w kodzie, który właśnie mi podał. (Używamy kontroli źródła w Visual Studio 2013 ), więc dosłownie setki wierszy kodu, bez żadnego tła na temat tego, co ma zrobić. Kod, który widzę, to kod, którego nigdy wcześniej nie widziałem, więc naprawdę trudno jest go rozgryźć.

Spróbowałbym zadać mu więcej pytań, ale on zawsze pracuje (to jego własna sprawa) i mam wrażenie, że mógłby się zdenerwować tymi wszystkimi pytaniami, które mam na ręce.

Tak więc coś, co pomoże mi się wydostać, dopóki nie opanuję wszystkiego, jak mogę poprosić mojego szefa o umieszczenie komentarzy w jego kodzie, który mi daje, ale uprzejmie?

Jesteś na „głębokim końcu” i, moim zdaniem, to najlepszy sposób na naukę. Nie dlatego, że patrzysz na rzeczy, o których nie masz pojęcia, ale dlatego, że zmusza cię to do zaradności i dowiedzenia się, jakie komponenty odgrywają rolę w systemie, w którym jesteś nowy.

Nie pomaga to, że twój szef jest zbyt zajęty, aby poradzić sobie z kimś, kto jest dociekliwy (i masz całkowitą swobodę bycia dociekliwym; chętnie się uczysz, co jest dobre). Ale niestety poproszenie seniora o zmianę stylu i podejścia do nauki może nie pójść zbyt dobrze, zwłaszcza, że ​​masz do czynienia z osobą, o której mówisz, że jest zajęta.

Siedzenie przed tysiącami wierszy kodu, których nie znasz, jest normą. Nie zawsze można to wyjaśnić czarno-białymi komentarzami. Jednak ze względu na naukę, gdy jesteś w tym nowy, zdecydowanie uważasz, że musisz poprosić go o komentarze - może wyjaśnić, dlaczego. Wyjaśnij to dlatego, że nie chcesz zawracać mu głowy pytaniami, ponieważ często jest zajęty. Nie tylko stanie się to o wiele mniej, niż gdybyś kazał mu coś zrobić, ale także otworzy podłogę do dyskusji na temat tego, jak zamiast tego wolałby odkładać czas na zadawanie pytań.

Po pierwsze, przeszukując tysiące wierszy nieznanego kodu i czując się zagubionym, każdy projekt oprogramowania jest wszędzie od początku.

Największa różnica między tobą a doświadczonym programistą polega na tym, że nie jesteś do tego przyzwyczajony.

Kilka punktów, o których należy pamiętać:

1. Przy wystarczającym wysiłku każdy fragment kodu jest zrozumiały. Wiele osób czuje się sfrustrowanych, jeśli nie mogą czegoś wymyślić w ciągu kilku minut. Bądź bardziej cierpliwy niż to.

2. Dobry szef jest jak najbardziej otwarty na przerwy i pytania. Dobry pracownik stara się maksymalnie starać, aby zminimalizować przerwy i pytania. Bądź tego świadomy.

3. Przerwy są droższe niż pytania. Możesz lepiej wykorzystać swój czas i czas szefa, konsolidując swoje dyskusje i nigdy nie kończąc rozmowy, czując się zagubiony.

4. Twój szef jest lepszym programistą niż ty. (Prawdopodobnie.) Nie oznacza to, że w niektórych obszarach nie można być silniejszym, ale ogólnie jego wiedza jest większa. Dopóki nie będziesz mieć dużego doświadczenia, upewnij się, że uczysz się z jego wiedzy tak dużo, jak to możliwe.

5. Jeśli masz pewność, że więcej komentarzy znacznie pomoże kodowi, zapytaj swojego szefa. „Trudno mi zrozumieć, co się dzieje w niektórych miejscach. Kiedy coś wymyślę, nie masz nic przeciwko, jeśli dodam komentarze?” Może nienawidzi komentarzy. Może to pokocha. Może będzie obojętny.

W końcu jednak możliwe jest, że za kilka miesięcy pamiętasz pytanie i pomyślisz: „Hę, zastanawiam się, z czym miałem problem? Nie jest tak źle. Hm, cóż, nieważne”.

Jeśli twój szef nie ma czasu, aby odpowiedzieć na wszystkie pytania, dlaczego uważasz, że będzie miał czas na skomentowanie swojego starszego kodu? Co więcej, co sprawia, że ​​myślisz, że jego komentarze naprawdę opisałyby fragmenty, których na razie nie rozumiesz? Z mojego doświadczenia wynika, że ​​próba zmiany stylu programowania szefów po prostu pytając go nie będzie działać, uprzejma czy nie.

Najlepszą rzeczą, jaką możesz zrobić w takiej sytuacji: skomentuj części kodu, które musisz zrozumieć, aby wykonać swoją pracę samodzielnie - oczywiście po zrozumieniu tych części i po uzyskaniu od szefa zobowiązania, że ​​będzie dobrze. Jeśli ty lub twój szef obawiacie się, że możecie coś zepsuć dodając komentarze, dodajcie je w osobnej gałęzi i zapytajcie szefa, czy poświęci czas na sprawdzenie twoich komentarzy, zanim zostaną one połączone w bagażniku. Ponieważ twój szef ma ograniczony budżet czasowy, spróbuj dowiedzieć się, co pewna część robi najpierw sam, inwestując rozsądną ilość czasu. Jeśli naprawdę utkniesz, zapisz swoje pytanie na liście i zapytaj szefa, na przykład, raz dziennie, zamiast przeszkadzać mu jakieś 30 minut. Z mojego doświadczenia wynika, że ​​takie podejście działa z większością ludzi, nawet jeśli są bardzo zajęci, o ile są gotowi pomóc - co z pewnością ma miejsce w twojej sytuacji.

W ten sposób masz pewność, że dostaniesz potrzebne komentarze, a twój szef zobaczy, gdzie potrzebujesz dodatkowych informacji, i jeśli wszystko będzie dobrze. I dopóki ograniczysz się do komentowania tylko nieoczywistych rzeczy, istnieje duża szansa, że ​​twoje komentarze podniosą ogólną jakość bazy kodu, co może przynieść korzyści nie tylko tobie, ale także wszystkim innym, którzy ma do czynienia z kodem, w tym z szefem.

Po pierwsze, niech to będzie dla ciebie przykład, aby poprawnie skomentować swój kod, konik polny!

Potem muszę to robić cały czas. Sprawdziłem mój lokalny egzemplarz, sam go przeglądam i komentuję. (Mogę je wszystkie rozebrać ponownie, jeśli mam zamiar to sprawdzić - lub zostawić je, jeśli nikt nie ma nic przeciwko.) Wtedy, gdy naprawdę nie widzę dalej, mogę kogoś zapytać, myślę, że tak to (co skomentowałem), mam rację? Możliwe, że sam skomentowałeś, ale to już koniec i o to właśnie chodzi.

To coś więcej niż osobista prośba. Próbujesz zmienić nawyki / kulturę, a to nie jest łatwe. Z pewnością nie jest to coś, co można osiągnąć rozmową na korytarzu lub e-mailem. Będzie to wymagało trochę wysiłku z twojej strony.

Bądź zmianą, którą chcesz zobaczyć na świecie.

Cytat może być fałszywie przypisany Mahatmie Gandhiemu, ale ma on zastosowanie w przypadku porady. Próbując rozwikłać bazę kodu, napisz komentarze, które chciałbyś zobaczyć, najlepiej jak potrafisz , i zatwierdź je, po sprawdzeniu przez szefa. Zalety:

• Jesteś proaktywny, a nie dokuczliwy.
• Dajesz dobry przykład. W najlepszym przypadku twój szef / zespół zobaczy korzyści i pójdzie za nimi.
• Niektóre komentarze prawdopodobnie powiedzą /* Mystery parameter 3 */lub /* 2015-02-09 AidanQuinn: Is this code ever called? */- są to dla twoich kolegów możliwości albo udokumentować kod poprawnie, albo naprawić ukryte błędy.
• Jeśli podczas przeglądu przed zatwierdzeniem okaże się, że napisany komentarz jest niedokładny, wówczas Twoi koledzy wiedzą teraz, że kod był niejasny.

Nie rób przy tym żadnego przepisywania lub refaktoryzacji, a wprowadzanie komentarzy powinno być prawie pozbawione ryzyka. Jeśli coś przepisujesz, zachowaj te zmiany jako osobne zatwierdzenia.

(Zanim jednak przystąpisz do tego projektu, upewnij się, że Twoje oczekiwania dotyczące komentarzy są uzasadnione. Jeśli Twój pomysł na dobrze skomentowany kod wykracza poza normę ( Przykład 1 , Przykład 2 ), będziesz głupcem siebie.)

Nie prosiłbym o dodatkowe komentarze, ale oto kilka pomysłów dla Ciebie:

1. Umów się na spotkanie z szefem i poproś go, aby przejrzał kod na wysokim poziomie. To powinno zacząć. Spodziewałbym się od kilku godzin do może pół dnia, żebyś mógł nabrać prędkości. Powinno to obejmować ogólny projekt, zastosowane wzory itp.
2. Utwórz projekt testowy i zacznij pisać testy jednostkowe na kodzie, to pomoże ci go zrozumieć bez wpływu. Możesz również znaleźć kilka błędów!
3. W razie potrzeby debuguj kod, aby zrozumieć niektóre obszary.
4. Usuń ulepszenie lub błąd z zaległości i popracuj nad tym.

Komentarze są w porządku, ale jeśli kod jest napisany w prosty sposób, powinien być zrozumiały po kilku dniach.

Nie oczekuj też, że wszystko zrozumiesz, lepiej najpierw skoncentrować się na kluczowych obszarach, a następnie w razie potrzeby poszerzyć wiedzę na temat kodu.

Mniej więcej rok temu byłem w bardzo podobnej sytuacji do twojej. Zacząłem pracować z niewielkim doświadczeniem programistycznym (choć na początku znałem trochę OO i kilka innych języków), a jedna osoba, która mnie uczyła, miała bardzo mało czasu. Zawsze był pomocny, ale czułem się, jakbym nie chciał zadawać każdego pytania.

Inni już zasugerowali tutaj niezwykle pomocne rzeczy (na przykład pisanie testów jednostkowych, ale z własnego doświadczenia wynika, że ​​od samego początku poszedłbym trochę „za daleko” lub komentowanie części kodu, ale może to być trudne w zależności od pierwszego punktu / pytania, które zadam ci za minutę). Poniższe punkty podsumowują to, co zrobiłem i co mi pomogło, ale to zależy od tego, gdzie dokładnie leżą twoje problemy.

Ponadto muszę zgodzić się z @AK_, który powiedział, że tak naprawdę nie potrzebujesz komentarzy w C #. To może nie być w 100% poprawne (czuję, że istnieją obszary, w których komentarze zdecydowanie pomagają, np. Kod obciążający refleksje), ale w istocie tak jest. Jeśli napiszesz naprawdę „czysty kod” za pomocą dobrze nazwanych metod i zmiennych, i masz dużo małych „bitów” kodu, będą one prawie zupełnie niepotrzebne. Za każdym razem, gdy do tej pory czytałem kod, odczuwałem potrzebę komentowania, a potem, gdy zrozumiałem, co to jest, byłem bardzo niezadowolony ze sposobu, w jaki to zostało zrobione, i pomyślałem, że może być o wiele jaśniejsze dzięki dobrej refaktoryzacji. Edycja: Mówię tu konkretnie o komentarzach w języku C # , a nie dokumentacji (czy to oddzielnej dokumentacji, czy komentarzach XML), ponieważ uważam, że dokumentacja jest zawsze ważna.

• Określ, jakie dokładnie są twoje problemy i czy możesz je podzielić na kategorie. To znaczy, czy nadal masz problemy z samym językiem lub nie rozumiesz określonej składni (np. Wyrażenia lambda i ogólnie LINQ lub Reflection)? Jeśli nie rozumiesz wierszy kodu, nie zrozumiesz, co robi cała metoda / blok, więc komentowanie go będzie trudne. Zdobądź raczej dobrą książkę („C # in a Nutshell”, to było dla mnie, ale słyszałem, że „C # in Depth” jest również spektakularna) i poczytaj o rzeczach, które napotkasz. Podział tych problemów na kategorie ułatwia to, ponieważ możesz wypełnić „większe luki” naraz, a nawet zapytać o to szefa, ponieważ nie jest to już wiele pytań, a raczej wyjaśnienie jednego tematu lub najczęściej używanych konstrukcji, abyś mógł może uzyskać ogromny „impuls”

• Równolegle do powyższego próbowałem zapoznać się z „czystym kodowaniem” i najlepszymi ogólnymi praktykami (nie specyficznymi dla języka). Efekt może nie być natychmiastowy, ale prędzej czy później się opłaci, albo gdy będziesz musiał rozszerzyć istniejące rzeczy, albo zastanowisz się, dlaczego ktoś stworzył tak wiele małych metod zamiast jednej, w której wszystko jest zawarte ;-)

• Zapoznaj się z typowymi wzorami projektowymi. Mogą pojawiać się tu i tam w czytanym kodzie, a jeśli je rozpoznasz, natychmiast da ci a-ha chwilę. Nawet jeśli rozumiesz, co robi kod, który widzisz, możesz zastanawiać się, dlaczego tak się dzieje, a samodzielne ustalenie tego wszystkiego często nie jest takie łatwe.

Proszę nie brać powyższego tekstu, gdy zakładam twoje „umiejętności”, często przypadkowo przełączam się między mówieniem o moich doświadczeniach a mówieniem „do ciebie”. To głównie oznacza to, co spotkałem i co zrobiłem . Jak powiedzieli inni, może to być bardzo dobre doświadczenie i jest to w zasadzie standard w czytaniu kodu, który nie jest twoim własnym i o którym wcześniej niewiele wiesz. Ale może być naprawdę satysfakcjonujące, aby w końcu zrozumieć, co się tam dzieje i rozpoznać, że jesteś coraz lepszy w tej konkretnej „umiejętności”. Skorzystaj z okazji i naucz się dużo w bardzo krótkim czasie, powodzenia! :)

Prawdopodobnie nie zmusisz go do zmiany stylu.

Możesz zadać wiele pytań i zapisać odpowiedzi.

Odziedziczyłem ogromną bazę kodu po mojej ostatniej pracy, mało dokumentacji i kilka komentarzy. Spróbowałem więc przez pół godziny tego samego problemu, a jeśli nadal nie będę w stanie go rozwiązać, zapytam kogoś, kto albo go napisał, albo wiedział, jak go użyć. Następnie dokumentowałbym wszystkie rzeczy, które mi powiedział. Większość poszła w naszej dokumentacji, niektóre w kodzie jako komentarze. Po roku praktycznie napisałem dużą część naszej dokumentacji i dużo wiedziałem o podstawie kodu.

Powodzenia!

Miałem ten sam problem. Jestem studentem fizyka i mam dobre doświadczenie programistyczne. Programowałem w wielu językach, ale nic dla aplikacji premium.

Złożyłem podanie o pracę dla programisty i natychmiast odłożyli mnie na zaplecze programowania. Kiedy szef pokazał mi podstawowy interfejs API dla aplikacji REST węzła, myślałem, że go wyrzucę. Nigdy nie widziałem funkcji z wywołaniem zwrotnym i tak dziwną składnią. I pytam mojego szefa, czy mam problem, jeśli nie rozumiem niczego w kodzie. Smutne, że nie, smutne, że mam 1 miesiąc, żeby to rozgryźć, a tymczasem stworzę CMS do testowania mnie z innym frontenderem.

No i poszedłem wtedy 1 linijkę kodu i wyszukuję w Google wszystko, czego nie wiem. Minął więc tydzień i znałem kod na tyle, że mogłem nawiązać współpracę z front endem. Mój kod na początku był gównem, ale do zobaczenia 3 miesiące później! Koduję lepiej i szybciej niż nasz architekt oprogramowania!

Sugeruję, że nigdy nie przestajesz się uczyć! Moje moto -> Ucz się i zachowaj spokój :) Nie polegaj na szefie bądź niezależny i pytaj go bezpośrednio, ale tylko najtrudniejsze problemy. Ponieważ będziesz szczęśliwy, gdy rozwiążesz to samodzielnie. I pamiętaj, kiedy przestaniesz się uczyć czegoś złego, naucz się każdego dnia, jak być dobrym programistą.

Jeśli nauczysz się od bossa, nigdy nie będziesz lepszy od niego, ustanawiając własny standard, ucz się pisania na ślepo, VIM lub wtyczki VIM dla IDE, Linux wmii, więc pewnego dnia wyjdziesz poza bossa i będziesz lepszy od niego!

Jako inżynier oprogramowania od 20 lat, pracujący głównie nad kwestiami związanymi z bezpieczeństwem (SF-PD), muszę powiedzieć, że twój szef może nie być osobą, którą chcesz być twoim przykładem. Brak komentarzy jest oznaką samouka-programisty amatora, który nigdy nie nauczył się prawidłowo wykonywać tej pracy, lub niedoświadczonego inżyniera. A może inżynier, który po prostu nie ma czasu - terminy i celowość mogą zrobić okropne rzeczy w twoim kodzie! ;) Jest to zdecydowanie anty-wzorzec dla każdego kompetentnego inżyniera oprogramowania.

Twój szef może być bardzo dobrym programistą, ale wygląda na to, że nie jest dobrym inżynierem oprogramowania. Inżynier wykorzystuje zbiorowe doświadczenie grupowe, aby uniknąć pułapek, którymi inni ludzie już zostali złapani. Skuteczne komentowanie jest częścią tego doświadczenia grupowego oprogramowania, podobnie jak analiza naprężeń jest częścią doświadczenia grupowego inżynierii mechanicznej. To, co liczy się jako skuteczne komentowanie, jest jednak bardziej płynne i zdecydowanie jest to coś, co można uzyskać z doświadczenia.

Najbardziej podstawową rzeczą jest to, że komentarze nie powinny mówić o tym, co robi wiersz kodu. Są chwile, kiedy komentarze do powiedzenia, co robi funkcja, są zbyteczne (szczególnie w języku C #). Nadmierne komentowanie może być tak samo nieskuteczne (i wskaźnik do braku doświadczenia), ponieważ nie możesz znaleźć ważnych rzeczy w żużlu. Jako nowicjusz, być może nadal pracujesz nad ustaleniem „co” w kodzie, a do tego musisz po prostu przeczytać i zrozumieć, co zrobił.

Ważną rzeczą w komentarzach jest to, że mówią DLACZEGO wiersz kodu lub funkcja robi to, co robi, co może nie być oczywiste. Czy musisz skonfigurować moduł X przed modułem Y? Czy ważne jest, aby sprawdzić kod powrotu, aby zobaczyć, czy plik był już otwarty, czy też świadomie ignorujemy kod powrotu, ponieważ został on sprawdzony w innym miejscu? „Dlaczego” kodu będzie istotne dla wszystkich, bez względu na doświadczenie - i będzie miało również znaczenie dla niego za 6 miesięcy, kiedy zapomni o dobrym powodzie, aby zrobić coś w określony sposób. Komentowanie jest nie tylko dla innych ludzi, ale również dla ciebie w przyszłości.

Jeśli chcesz uniknąć irytowania swojego szefa, zadawaj sprytne pytania. Skoncentruj się na pytaniu o „dlaczego” i spróbuj sam wyliczyć „co” (chyba że jest to naprawdę niejasne). Żaden dobry szef nie będzie miał nic przeciwko zadawaniu pytań, jeśli nie są to rzeczy, które można znaleźć w R-ing TFM. I żaden dobry inżynier nie będzie miał nic przeciwko poproszeniu o zrobienie czegoś, co znacznie ułatwi życie innemu inżynierowi, przy niewielkim koszcie. (Po prostu nie proś go o wypełnianie komentarzy dotyczących całej bazy kodu!)

Byłbym w podobnej sytuacji, powiedziałbym

1. Twój szef może chcieć, abyś nauczył się brudnej drogi (przechodząc przez kod, o którym nie masz pojęcia) z jakiegoś powodu. W ten sposób uczymy się więcej w ciągu miesiąca w pracy niż w szkole, jak wspomniano w innych odpowiedziach.

2. Jest to „norma”, jak wspomniano w innych odpowiedziach. Powinieneś bardziej martwić się, od czego zacząć i jak podejść i na czym się skupić, niż próbując od razu zrozumieć każdy wiersz kodu. Zapytaj swojego szefa o odpowiednie narzędzia i sposoby debugowania / przejścia przez kod. Tego rodzaju pytania przyniosą ci punkty.

3. Regularnie zwracaj się do szefa o opinię na temat tego, co robisz, abyś miał pomysł, w jaki sposób stoisz w percentylach, zakładając, że twój szef widział wiele osób w tej samej sytuacji i miał pomysł, jak to zrobił.

4. Wykorzystaj to jako okazję i gdy będziesz lepiej rozumieć kod, dodawaj komentarze, o które pierwotnie spodziewałeś się zapytać swojego szefa.

Jeśli naprawdę chcesz spróbować poprosić go o umieszczenie komentarzy w jego kodzie (nie polecam), sugerowałbym znalezienie kodu, który musisz edytować, który mógłby naprawdę użyć niektórych komentarzy (większość jest oczywista) i zadając pytanie o w ten sposób „Patrzyłem na ten kod tutaj i próbuję wymyślić [masz problem] i nie mogłem znaleźć żadnych komentarzy, które mogłyby to wyjaśnić”. Zasadniczo postaraj się pokazać, że włożyłeś wysiłek w zrozumienie tego i wyjaśnij, dlaczego oboje mogliby skorzystać z zamieszczonych komentarzy.

Prawdopodobnie 90% dobrze napisanego kodu nie wymaga komentarzy. Naprawdę chcesz udokumentować tylko te części kodu, które zostały zoptymalizowane i stały się dość napięte. Pracowałem kiedyś w firmie, która wymagała od Ciebie udokumentowania każdego zmodyfikowanego fragmentu kodu. Zasadniczo komentarze były aktywnie szkodliwe dla czytelności kodu, ponieważ często odnosiły się do kodu, który został usunięty lub zmodyfikowany nie do poznania. Uważaj na słabe komentarze Spędziłem tydzień na debugowaniu funkcji i na koniec odkryłem, że komentarz, który czytałem o ustawianiu takiej i takiej flagi na „fałsz” był w rzeczywistości całym problemem. Ustawiłem flagę na „prawda” i wszystko działało tak jak powinno.

Jeśli chcesz, aby komentarze w kodzie zrozumiały, dlaczego coś zostało napisane, najprawdopodobniej (biorąc pod uwagę, że jesteś nowy) jeszcze nie rozumiesz potrzeb biznesowych. Jestem pewien, że znasz całą składnię i umiesz czytać kod, ale jeśli nie znasz celu jakiegoś kodu, poczujesz się trochę zagubiony.

Jedną z rzeczy, które przychodzą na myśl, jest programowanie w parach. Mówisz, że twój szef jest pod wrażeniem twoich postępów, więc możesz zasugerować współpracę z nim. Pomoże to wam obojgu na dłuższą metę. Twój szef będzie musiał wyjaśnić rzeczy, które uważa za oczywiste, a ty dowiesz się więcej o firmie.

Jak wspomnieli inni, jest to dość powszechne, ale to nie znaczy, że musisz go po prostu wyssać i przeorać. Nie musisz rozumieć tak dużo kodu tak głęboko, jak ci się wydaje, i istnieją konkretne strategie, dzięki którym „głęboki koniec” będzie o wiele płytszy:

• Znajdź w kodzie coś związanego z danym zadaniem. Zwykle najłatwiejszym do wyszukania jest coś widocznego dla użytkownika, na przykład etykieta przycisku w GUI. Zapisz, gdzie go znalazłeś. To będzie twój punkt zaczepienia.
• Teraz wyszukaj kod o krok i zapisz go. Kto tworzy przycisk? Jaki kod jest wywoływany po kliknięciu przycisku?
• Kontrola źródła jest często przydatna do znajdowania kodu oddalonego o jeden krok. Sprawdź, kiedy kod, który oglądasz, został dodany lub zmieniony, i zobacz, co jeszcze zostało zarejestrowane w tym samym czasie i dlaczego.
• Powtarzaj tę czynność, dopóki nie zrozumiesz na tyle, by dokonać zmiany, i jeden poziom głębiej, aby upewnić się, że niczego nie umknie.
• Jeśli utkniesz w dowolnym momencie, masz teraz bardzo konkretne pytanie. Na przykład „Nie mogę się dowiedzieć, skąd pochodzi ten przycisk”.

Oto moje 0,02 $ w tej sprawie. Nie sugeruję wyłącznej odpowiedzi, wiele z tego, co zostało tu powiedziane, jest dość istotne.

Spróbowałbym trochę inżynierii społecznej, aby ułożyć rzeczy tak, aby twój szef łatwiej / mniej czasochłonnie komentował część swojego kodu niż nie.

Może to być całkiem łatwe, jeśli zechcesz zaryzykować i zirytować go - ale nie chcemy tego robić. (uwaga dodatkowa: możesz po prostu nie być w stanie nic zrobić bez jego zapisywania lub dyktowania komuś komentarzy, nalegania i zadręczania go w nieskończoność itp.)

Jaka jest zatem alternatywa? Kilka pomysłów, w zależności od okoliczności.

opcja 1

1. Poświęć trochę czasu, aby zrozumieć fragment jego kodu jako X.
2. Pomyśl teraz o rozsądnym sposobie, w jaki Y nie zrozumie tego.
3. Powiedz szefowi (e-mailem lub powiedz przy śniadaniu lub czymkolwiek innym), że próbujesz to rozgryźć.
4. Dodaj komentarz mówiący, że nie jest jasne, co oznacza kod, ale rozumiesz to jako Y; postaraj się, aby ten komentarz był dla niego widoczny - ale nie próbuj zbyt mocno!
5. Działaj, zakładając Y - i upewnij się, że twój szef zauważy twoje działanie (abyś nie marnował czasu na pracę przez długi czas na fałszywe założenia).
6. Szef powinien podjąć inicjatywę, aby cię poprawić. W tym momencie powiedz mu coś w stylu „Naprawdę chciałbym, aby ten kod miał kilka komentarzy, aby zapobiec błędnemu założeniu. Poprawię komentarz, który sam dodałem. Czy uważasz, że możesz mi pomóc z jakimś ogólnym opisem tego i tamtego fragmentu kodu? Nie mam wystarczającego doświadczenia, aby zrozumieć dokładną intencję, i jestem tylko kilkoma zdaniami, by to załatwić ”. Lub coś..

Opcja 2

Trenujesz Spróbuj zorganizować z nim (dodatkowe?) Cotygodniowe spotkanie o stałej częstotliwości. Na tym spotkaniu omów trochę kodu - ale musisz przyjść wystarczająco przygotowany, aby nie musiał wyjaśniać każdej linii. W pewnym momencie - mam nadzieję - zda sobie sprawę, że może pominąć spotkanie, jeśli tylko doda komentarze.

Opcja 3

Poproś innego współpracownika, aby nie rozumiał tego samego fragmentu kodu, co Ty. Obaj podchodzicie do szefa w różnym czasie, zadając te same pytania. To pewny sposób, aby uświadomić mu, że coś nie robi ... ale nie każdy ma luksus pomocnych współpracowników przy tym samym projekcie.

Tak więc coś, co pomoże mi się wydostać, dopóki nie opanuję wszystkiego, jak mogę poprosić mojego szefa o umieszczenie komentarzy w jego kodzie, który mi daje, ale uprzejmie?

Jeśli nie rozumiesz kodu, dlaczego uważasz, że komentarze są Twoim rozwiązaniem?

Nie znam jego stylu programowania, ale przyznaję, że jeśli nazwa funkcji i zmiennych wprowadza w błąd, bardzo utrudnia to zrozumienie kodu. Ale jeśli nazwy i funkcje, a nawet organizacja programu (klasy, metody, właściwości ...) sprawiają, że kod jest zrozumiały, wówczas kod sam z tobą porozmawia.

Lepiej zapytaj go o architekturę programu, a jeśli chcesz o coś poprosić, poproś o bardziej sensowne nazwy funkcji; jest to dla niego wygodniejsze.

Nawet jeśli istnieje sposób, aby zapytać o to uprzejmie, istnieją dwie możliwości, co twój szef pomyśli o komentarzach w swoim kodzie:

1. Albo dobrze byłoby mieć komentarze w jego kodzie, albo

2. Komentarze w jego kodzie nie byłyby dobre.

Jeśli twój szef uważa, że ​​komentarze w jego kodzie nie byłyby dobrą rzeczą (i istnieją bardzo dobre argumenty, np . Kod ma być dokumentacją , a żadna dokumentacja nigdy nie będzie określać czegoś tak precyzyjnie i jednoznacznie jako kod, który to robi ,) nic się nie wydarzy.

Teraz, jeśli przypadkiem twój szef pomyśli, że komentarze w jego kodzie byłyby dobre, to jest duża szansa, że ​​powie ci, abyś przestudiował swój kod, zrozumiał, jak to działa, i zaczął dodawać komentarze do swojego kodu koduj siebie . (Są też bardzo dobre argumenty na ten temat, tzn. Musisz się uczyć , a jego czas jest z definicji znacznie cenniejszy niż twój .)

Tak więc, jeśli nie jesteś na to przygotowany, lepiej nie mówić nic.