Chociaż nie mogę wymienić wszystkich pułapek, często sformułowanie pytania i ułożenie go w samodzielny problem często wymaga tak dużo pracy, że zanim wystarczająco go przygotowałeś, odpowiedziałeś na własne pytanie więcej inaczej, niż zajęłoby to inaczej.
To samo dotyczy> 75% zadawanych przeze mnie pytań.
Nie jest to jednak argument za tym, aby nie zawracać sobie tym głowy. Jest to skutecznie debugowanie gumowej kaczki. Znajdujesz odpowiedzi na pytania, które Twoim zdaniem mogą się pojawić w odpowiedzi na twoje pytanie; co oznacza, że myślisz o problemie z punktu widzenia różnych osób; co oznacza, że myślisz o problemie ze wszystkich możliwych kierunków; co jest najlepszym sposobem na znalezienie wady.
W najlepszym wypadku ostatecznie udowodniłeś, że wyraźnie nie możesz wymyślić tutaj odpowiedzi. W „najgorszym” kończy się odpowiedź na własne pytanie. Zwróć uwagę na cytaty, ponieważ wcale nie jest tak źle. Być może było to trochę nieefektywne czasowo, ale powolne rozwiązywanie problemu jest lepsze niż szybkie decydowanie się na rozwiązanie problemu . W końcu szybciej uzyskasz rozwiązanie problemu.
Przykładem:
Kiedy byłem początkującym programistą, wiele razy zajmowałem się stroną błędów platformy ASP.Net . Potrzebowałem Google, aby dowiedzieć się, co jest nie tak. może minąć kilka godzin, zanim otrzymam właściwe rozwiązanie. Zasadniczo popełniłem każdy błąd w książce, a następnie musiałem poradzić sobie z konsekwencjami konieczności debugowania problemów.
Teraz, gdy pojawia się błąd, już znam „zwykłych podejrzanych”, co może być przyczyną problemu. Moja lista mentalna „zwykłych podejrzanych” skutecznie opiera się na problemach, z którymi najczęściej miałem problemy podczas mojej kariery. Bez wcześniejszej nieefektywnej pracy godzinnej w Googlingu nigdy nie zrobiłbym tej listy mentalnej . Ale teraz, kiedy mam tę listę mentalną, znacznie szybciej rozwiązuję problemy.
Ponadto, chociaż nie mogę do końca tego dotknąć, responsywności swobodnej rozmowy nie da się porównać z żadną formą dyskusji tekstowej w Internecie, o której mogę pomyśleć.
Trochę się tu nie zgadzam. Masz rację, że komunikacja internetowa jest mniej responsywna, ale (moim zdaniem) się mylisz, że jest to dla ciebie złe.
Jako samotny programista będziesz polegać na debugowaniu gumowej kaczki. Kluczowym składnikiem działania RDD jest oczekiwanie na pytania, które może mieć dla Ciebie gumowa kaczka. Oczywiście nie możesz polegać na tym, co faktycznie mówi gumowa kaczka.
Kiedy masz do czynienia z powolnymi systemami przesyłania wiadomości (wysyłanie wiadomości na StackOverflow lub komunikowanie się poprzez pisanie listów), z natury rzeczy zachęcasz się do upewnienia się, że otrzymałeś to poprawnie za pierwszym razem. Ponieważ konieczność poprawienia błędu będzie procesem powolnym i uciążliwym.
Dla porównania weź pod uwagę, że systemy szybkiego przesyłania wiadomości (konwersacja, komunikatory) możesz natychmiast coś poprawić. Zdolność do szybkiego poprawienia czegoś sprawia, że ludzie są mniej motywowani do upewnienia się, że jest to poprawne.
Cztery przypadki w punkcie:
- Kiedy tworzę własną osobistą analizę / listę rzeczy do zrobienia jako programista, nadal używam długopisu i papieru. Zauważyłem, że podczas pisania notatek omijam założenia i kłamstwa, ponieważ mój umysł myśli, że „mogę to łatwo naprawić później”. Jednak konieczność poprawienia czegoś, co napisałeś na papierze, jest denerwujące, musisz przekreślić rzeczy i napisać między wierszami, a dokument będzie wyglądał o wiele gorzej, gdy będzie na nim rysowanie. Pisanie na papierze zmusza mnie do sprawdzenia faktów, zanim zdecyduję się je napisać. To wychwytuje wiele nieporozumień wcześnie, zanim jeszcze napisam kod, który mógłby powodować błędy.
- Moja babcia była sekretarką (wiek maszyny do pisania). Napisanie literówki w oficjalnym dokumencie oznaczało konieczność ponownego wpisania całej strony. Moja ciocia jest sekretarką (wiek edytora tekstu). Może polegać na automatycznym sprawdzaniu pisowni, a błędy można naprawić łatwo i przy minimalnym wysiłku. Nic dziwnego, że moja babcia popełnia znacznie mniej błędów pisowni i błędów ortograficznych w porównaniu do mojej ciotki.
- Gry wideo były drukowane na kartridżach. Naprawienie błędu po wydaniu było prawie niemożliwe. Trzeba będzie ponownie wydrukować wszystkie naboje, rozprowadzić je wśród wszystkich dostawców i mieć nadzieję, że dostawcy w jakiś sposób będą mogli skontaktować się z klientami, którzy już kupili grę. Kosztowałoby to mnóstwo pieniędzy (podwójny fizyczny koszt produkcji) i nadal nie docierałoby do niektórych klientów. Teraz, w dobie łatek internetowych, twórcy gier okazali się znacznie mniej zainwestowani w testowanie swoich gier, aby mogli uniknąć błędów związanych z wydaniem, ponieważ o wiele łatwiej jest po prostu wprowadzić poprawkę bezpośrednio do każdego klienta. Wpływ popełnienia błędu jest zminimalizowany do punktu, w którym lepiej jest naprawić garść problemów po fakcie, niż testowanie wszystkich możliwych błędy, które mogą wystąpić.
- Mieszkałem w mieszkaniu na trzecim piętrze, bez windy, i często musiałem zaparkować jedną lub dwie ulice od mojego budynku. Prawie nigdy nie zapomniałem zabrać czegoś z mojego samochodu. Teraz mieszkam w domu z samochodem tuż obok mnie na podjeździe. Cały czas zapominam zabierać rzeczy z mojego samochodu .
Podstawową ideą jest to, że trudny system wymiany zachęca ludzi do dokonywania poprawnych i sprawdzonych faktów wymian . Surowość kary (= trudny proces korekty) uczy, aby nie popełniać błędów.
Ponadto ukrywanie szczegółów w celu zadania dobrze zdefiniowanego pytania eliminuje możliwość zauważenia przez kogoś problemów, o których nie pomyślałeś.
Kiedy tworzysz MCVE , nie powinieneś go po prostu tworzyć i publikować w pytaniu. Najpierw powinieneś zrobić to sam , abyś mógł wyizolować problem. A potem, gdy myślisz, że problemu nie można już zmniejszyć, a nadal nie widzisz przyczyny; to masz ważne pytanie dotyczące StackOverflow.
Przykładem:
Zawsze mam drugi program Visual Studio z prostą aplikacją konsolową o nazwie Sandbox. Ilekroć napotykam problem techniczny, kopiuję niepoprawny kod do piaskownicy i zaczynam się nim bawić.
- Co się stanie, gdy zmienię to ustawienie?
- Czy mogę odtworzyć problem, jeśli skrócę kod?
- Które ustawienia umożliwiają / uniemożliwiają odtworzenie problemu?
W 90% przypadków znajduję przyczynę problemu, ponieważ piaskownica pomogła mi spojrzeć na niepoprawny kod, nie rozpraszając go otaczającym kontekstem (lub, na przykład, niepewnością co do wartości, które pochodzą z różnych części kodu.
W pozostałych 10% przypadków mam minimalny kod do odtworzenia problemu, który stanowi doskonały przykładowy fragment do opublikowania na StackOverflow.
I na koniec, nie chcę publikować całego mojego projektu, aby świat mógł przyjrzeć się reszcie wieczności, z oczywistych powodów.
Kiedy już masz swój MCVE, nie powinieneś mieć dużo na drodze do osobistych (lub firmowych) informacji. Jeśli tak, ponieważ kod jest minimalny, łatwo jest zmienić nazwę rzeczy na bardziej podstawowy przykład foo / bar / baz.