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

72

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?

Aidan Quinn
źródło
2
Komentarze nie są przeznaczone do rozszerzonej dyskusji; ta rozmowa została przeniesiona do czatu .
wałek klonowy
1
Alternatywą dla pytania jest użycie narzędzi do indeksowania kodu źródłowego i narzędzi nawigacyjnych, takich jak SourceGraph .
Dan Dascalescu,
Niedawno zacząłem w zespole pracującym nad dużą (> 100 000 linii) aplikacją MVC5. W sumie jest 150 testów jednostkowych i wszystkie zostały dodane przeze mnie w ciągu ostatnich kilku miesięcy. Kilka komentarzy w kodzie jest przeważnie w innych językach. Welcome to business programming :)
Mark K Cowan
Pytania takie jak „Jak poprosić X o wykonanie Y” są zwykle lepsze w Miejscu Pracy, gdy X dotyczy kolegi.
Blrfl

Odpowiedzi:

130

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

JᴀʏMᴇᴇ
źródło
185
+1 za „Siedzenie przed tysiącami wierszy kodu, którego nie znasz, jest normą” - to nigdy nie pojawia się na kursach programowania i zawsze pojawia się w pracy.
pjc50
11
Dziękuję, że dałeś mi nadzieję, tak naprawdę myślałem o odejściu z pracy i pójściu na uniwersytet czy coś w tym rodzaju. Rozmawiałem z nim jakiś czas temu i powiedział, że jest pod wielkim wrażeniem moich postępów, bla bla haha ​​.. @ pjc50 Całkowicie zgadzam się z tobą, po prostu biorąc pod uwagę test i lekcję później. Prawdopodobnie nie uczyłem się więcej w ciągu ostatniego miesiąca niż 3 lata, które spędziłem w szkole!
Aidan Quinn
9
Dokładnie. Programowanie jako zawód wymaga praktyki (prawdopodobnie samouka), podczas gdy kursy CS mogą zawierać bardzo mało faktycznego programowania. Są symbiotyczne, ale nie to samo. Nie musisz iść na uniwersytet, aby być świetnym programistą, ale znacznie łatwiej jest cię zatrudnić, nawet jeśli kurs ma niewielki związek z pracą, o którą się ubiegasz.
pjc50
11
@AidanQuinn, zespół Impostora ( en.wikipedia.org/wiki/Impostor_syndrome ) może mocno zainicjować na początku nowej pracy, a tym bardziej na początku pierwszej. Jeśli mówi, że świetnie sobie radzisz, uwierz mu na słowo.
Celos
6
Programowanie przez większość czasu jest niekompetentne z powodu krótkich, przeplatanych wybuchów poczucia absolutnie boskiego geniuszu.
MrDosu
75

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

Paul Draper
źródło
6
Szczególnie podoba mi się punkt 3. Czasami dobrze jest napisać szybką dwuliniową wiadomość e-mail z prośbą o pomoc w rozwiązaniu problemu, nawet jeśli siedzi on w biurze kilka metrów od ciebie. To pozwala mu określić, kiedy jest gotowy, aby mu przeszkodzić, i daje ci więcej czasu na opracowanie pełniejszej listy pytań, zanim dyskusja rzeczywiście się odbędzie.
Phil
1
to samo dotyczy @Phil. Będziesz zaskoczony, jak wiele pytań sam sobie wymyślisz, po prostu starannie opracowując jasne pytanie w wiadomości e-mail. Sam proces wyjaśniania zamieszania z precyzją może włączyć światła. Nie mogę powiedzieć, ile razy pisałem tego rodzaju e-maile, które nigdy nie zostały wysłane, ponieważ to rozgryzłem.
kmote
3
@kmote, mam wiele niezadawanych pytań o przepełnienie stosu, które zdarzyły się w ten sam sposób :)
Paul Draper,
18

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.

Doktor Brown
źródło
3
Możesz również zaproponować łatkę dodającą kilka uwag do swojego szefa.
Basile Starynkevitch,
2
@BasileStarynkevitch: oczywiście, aby uniknąć ryzyka zepsucia czegoś, może on najpierw dodać komentarze w osobnym oddziale i poprosić swojego szefa o przejrzenie komentarzy, zanim zostaną one połączone z bagażnikiem.
Doc Brown
2
@DocBrown Praca w osobnym oddziale jest ogólnie dobrą strategią, ale jeśli dodawanie komentarzy coś zepsuje, to powiedziałbym, że baza kodów ma większe problemy ......
CVn
1
@ MichaelKjörling: tak naprawdę OP powinien omówić ze swoim szefem. Użycie innej gałęzi ma dwie zalety: pozwala uniknąć przypadkowych przerw, popełniając literówkę, np. Usuwanie jednej linii za dużo podczas usuwania przestarzałego komentarza, i popycha szefa do przejrzenia komentarzy.
Doc Brown
@ MichaelKjörling nie chodzi o to, że komentarze coś psują, ale komentarze muszą być zgodne z rzeczywistym kodem.
Hugo Zink
8

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.

RedSonja
źródło
5

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

200_sukces
źródło
5

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.

Jon Raynor
źródło
2

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! :)

InvisiblePanda
źródło
1

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!

Joshua Dance
źródło
1

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!


źródło
ten post jest raczej trudny do odczytania (ściana tekstu). Czy mógłbyś edytować go w lepszym kształcie?
komara
Przepraszam za moją ignorancję :)
zaktualizowany post jest znacznie łatwiejszy do zrozumienia (dobra edycja!), ale to, co widzę teraz, wydaje się po prostu powtarzać punkty, które zostały już (i zauważalnie lepiej wyjaśnione) w poprzednich odpowiedziach, zwłaszcza w tym
komnata
1
Przepraszam, że robię to rano przed pracą i nie mam zbyt wiele czasu na ręce, ponieważ właściciel pytania zobaczy, o co mi nie chodzi :)
0

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!)

Graham Bartlett
źródło
1
Pierwszy akapit sugeruje, że szef - i większość z nas - są niekompetentni, ponieważ (jak się zakłada) nie komentuje tak, jak powinien. To niefortunne, ponieważ reszta porad na temat tego, kiedy i jak komentować, jest w rzeczywistości dość rozsądna. Większość z nas prawdopodobnie zgodziłaby się z tym, gdybyśmy nie byli tak zniechęceni na początku.
John M Gant,
Ostatnie trzy akapity twojej odpowiedzi są bardzo przydatne, @Graham. Nie pozwólcie, aby kilka głosów negatywnych cię zniechęciło.
DavidS,
Byłem zaskoczony widząc opinie negatywne. Informacje na temat tego, jak i dlaczego komentować są martwe. Zgadzam się z innymi, że twoje spekulacje na temat kompetencji jego szefa są nieproduktywne.
@Superstringcheese: Niestety często dostajesz głosy negatywne za zajmowanie pozycji innej niż „Mama i szarlotka”. Nie zgadzam się z niektórymi z tego, co powiedziałeś (nie z pierwszego akapitu! Jest to całkowicie poprawne IMO) - ale nadal otrzymujesz ogólne poparcie.
einpoklum
0

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.

Jay D.
źródło
0

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.

dkippers
źródło
1
Kod bez komentarza nie jest dobrze napisanym kodem. Mówię moim programistom, aby umieszczali komentarz na początku każdego bloku jako ogólną zasadę. Lub przepisać blok na metodę o samokontrującej nazwie. O ile twoja metoda nie jest instrukcją if, wywołaniem metody i zwrotem, potrzebujesz komentarza.
bogate przypomnienie
@richremer Myślę, że jesteśmy prawie całkowicie zgodni. Dążę do samodokumentowania kodu z komentarzami, w których sprawy stają się napięte.
dkippers
0

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.

Daniel Hollinrake
źródło
0

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”.
Karl Bielefeldt
źródło
0

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.

einpoklum
źródło
0

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.

Ahmad
źródło
0

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.

Mike Nakis
źródło