Odpowiedzi

Ostatnio na blogu Xiona ukazał się post na temat udzielania odpowiedzi na pytania początkujących programistów. Pytania te często wydają się doświadczonym koderom irytujące ze względu na to, że odpowiedź jest dla nich oczywista. Ciśnie się na usta powiedzenie: Zapomniał wół jak cielakiem był…

Nie mam jednak zamiaru zastanawiać się czy lepsza jest odpowiedź krótka i rozwiązująca problem ale nie wyjaśniająca młodemu programiście dlaczego, ani czy lepsza bedzie długa wyczerpująca odpowiedź, której nikt nie przeczyta – bo kto ma na to czas? 😉

Ja zamierzam podzielić się własnymi spostrzezeniami na temat Dobrej Odpowiedzi. W życiu każdego z nas zdarza się odpowiadać na pytania kolegów odnośnie jakiegoś materiału przerabianego w szkole, na studiach czy nawet wyjasnienia o co chodzi w tej cholernej instrukcji obsługi… Jak wiemy niektórzy mają do tłumaczenia wrodzony talent, a inni tłumaczą tak, że nikt nic z tego nie rozumie. Dlaczego?

Podstawą do udzielenia dobrej odpowiedzi na pytanie jest zrozumienie tematu – jest to dość oczywiste. Czasem oczywiście ludzie, którzy nie wiedzą o co chodzi też starają się udzielić odpowiedzi (patrz dział o programowaniu na forum o2.pl).  Jednak zrozumienie tematu przez tłumaczącego jest często niedostateczne – czy raczej dobre na chwilę. Później i tak będzie trzeba stawić czola podobnym pytaniom zadawanym przez tę samą osobę ponieważ nie zrozumie ona skąd wzięła się tamta odpowiedź więc i następnym razem nie będzie w stanie sobie sama odpowiedzieć.

Aby udzielić dobrej odpowiedzi trzeba samemu się wysilić i zrozumieć skąd wzięło się to potencjalnie głupie pytanie. Zadający je przecież na pewno nie chciał aby takie było. Pytanie jest kreowane przez wizję podanego tematu, zatem jeśli ktoś źle nauczy się jakiejś części drabiny wiedzy z danej dziedziny to później mogą się w jego głowie rodzić zagwostki, których nie bedzie w stanie rozwiązać. Z drugiej strony – jeśli spojrzyna to pytanie bardziej doświadczony gość to pomysli, że jest ono durne.

Z poprzedniego akapitu wynika więc, że bardzo możliwe, że wystarczy naprostować tylko sposób myślenia danej osobie tłumacząc jej inne zagadnienie, które zostało błędnie zrozumiane a przez które osoba ta ma błędną wizję tego o co pyta. Stąd trzeba najpierw zadać kilka pytań pomocniczych aby dowiedzieć, się z czego wynika zadane pytanie.

Warto jednak pamietać, że nie zawsze warto tłumaczyć. Przykłądowo, mamy świeże mięcho – młody programista, zaczyna robić jakiś projekt wieloplikowy z kilkoma różnymi klasami w C++. Niech w pliku nagłówkowym umieści definicję jakiejś klasy (używając oczywiście #pragma once lub #ifndef/#endif) zapominając jedynie o średniku po klamrze zamykającej klasę. Po załączeniu takiego nagłówka w jakimś pliku okazuje się, że kompilator wywala błąd w pliku cpp, do którego jest załączony wspomniany nagłówek, a nie powie, że to brak średnika po definicji.

Doświadczony programista od razu wie o co chodzi, a nowicjusz zacznie się zastanawiać co jest źle w linijce wskazanej  przez kompilator. No i w końcu zada pytanie na forum. Odpowiadający może – tak jak napisałem – zdiagnozować problem i udzielić wyjaśnienia bądź odpowiedzieć po prostu, że brakuje średnika. W tym wypadku lepiej jest powiedzieć o braku średnika bo bardzo wątpliwym jest aby młody programista pojął sposób działania kompilatora. (bo to właśnie trzebaby mu wytlumaczyć chcąc aby miał kompletną wizję i rozumiał skąd ten błąd)

Jak widać nadal chodzi o sztukę wyboru mniejszego zła, a przy odpowiadaniu na pytanie problematyczne jest aby zrozumieć skąd ono się wzięło, a nie znalezienie faktycznego rozwiązania.

Reklamy

3 myśli nt. „Odpowiedzi

  1. Powiem szczerze, że w wielu przypadkach odważyłbym się jednak na drugą opcję, czyli wytłumaczenie jak kompilator działa :). Albo chociaż na zwrócenie uwagi, że w C++ dość często kompilatory pokazują błędy nie tam, gdzie są one faktycznie tylko tam, gdzie po raz pierwszy tworzą jakąś bezsensowną konstrukcję. Nie róbmy z początkujących idiotów, nie ukrywajmy przed nimi prawdy :).

    Początkującym programistom zawsze staram się przekazać natomiast pewien sposób programowania: pomyśl, zanim napiszesz, a pisząc, często zapisuj i często kompiluj – co kilkanaście linijek, co każdą gotową funkcję.

  2. No wiesz – nie trzeba ukrywać prawdy tylko trzeba najpierw zbadać czy delikwent jest gotowy na taką dawkę emocji 😉

    Co do zapisu to ja zapisuje po każdej małej zmianie 😉 W koncu to żaden problem wcisnąć Ctrl+S 😉 Przyłapałem się nawet na wciskaniu tego skrótu podczas pisania posta 😛

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj / Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj / Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj / Zmień )

Connecting to %s