Jak uniknąć skakania do rozwiązania pod presją? [Zamknięte]

Kiedy w szczególnie ścisłym terminie programowania (jak godzina), jeśli w ogóle wpadam w panikę, mam tendencję do kodowania bez prawdziwego planu i mam nadzieję, że uda mi się to zrozumieć. Biorąc pod uwagę wystarczającą ilość czasu, może to zadziałać, ale w wywiadzie było to dość nieudane, jeśli nie wręcz przeciwne do zamierzonego. Nie zawsze czuję się komfortowo siedząc i myśląc, gdy zegar tyka.

Czy istnieje lista kontrolna lub istnieją techniki rozpoznawania, gdy rozumiesz problem wystarczająco dobrze, aby rozpocząć kodowanie? Kiedy najbardziej produktywne jest myślenie i projektowanie bardziej niż kodowanie niektórych eksperymentów i późniejsze opracowanie całościowego projektu?

Oto lista technik rozwiązywania testu matematycznego i innych egzaminów ustnych . Czy istnieje podobna lista technik radzenia sobie z problemem programowania pod presją?

ODPOWIEDZI: Myślę, że to poprawna odpowiedź: jak to rozwiązać . Znalazłem ten link jako odpowiedź na kroki do rozwiązania lub podejście do rozwiązania . Było też kilka naprawdę dobrych wskazówek na temat Czy myślenie głośno podczas wywiadu jest naprawdę najlepszą strategią? . Świetny i zwięzły argument dla TDD to pierwsza odpowiedź na TDD Pisanie kodu a zastanawianie się nad odpowiedzią na problem? .

Pamiętam, jak czytałem studium na temat tego, jak strażacy tworzą plan działania po przybyciu na miejsce pożaru; w badaniu zaobserwowano (i potępiono) ich za wymyślenie pomysłu, a następnie natychmiast zrealizowano ten pierwszy pomysł. Z powodu presji czasu było prawie „to może działać”, a następnie „ok, zróbmy to”. W badaniu zauważono, że dostępne są lepsze, szybsze i bezpieczniejsze opcje, ale nie zastosowano się do nich po prostu dlatego, że marshmallowie nie pomyśleli o nich wcześniej.

Jeśli chcesz ustrukturyzowanego podejścia do radzenia sobie z „pożarami”, być może skorzystaj z ich (nowej) książki, która zawiera kilka faz:

RRAPID

1. Reakcja - zmobilizuj zasoby do incydentu
2. Rozpoznanie - Zbierz dane o sytuacji
3. Docenienie - wybierz kierunek działania w oparciu o najlepsze i najgorsze scenariusze
4. Plan - opracuj plan oparty na toku działania
5. Wydawanie zamówień - użyj standardowego formatu odprawy
6. Wdrażanie - wykonywanie i monitorowanie

lub bardziej ogólnie:

1. Obudź wszystkich i zmuś ich do działania
2. Sprawdź, co się dzieje
3. Rozwiązania burzy mózgów
4. Wybierz jeden i zaplanuj
5. Powiedz wszystkim, jaka jest ich praca
6. Wykonaj i monitoruj

Zawsze zaczynam od zrozumienia wymagań i szukania luk w nich, które wymagają odpowiedzi.

Następnie szkicuję (bardzo z grubsza i na papierze lub tablicy) dwa lub trzy możliwe rozwiązania. Następnie zadaję sobie pytanie: „Czy jest coś jeszcze, co muszę wiedzieć, aby wdrożyć którekolwiek z nich?”

Kiedy mam moje początkowe pytania (są pytania w 100% przypadków, jeśli ich nie masz, tak naprawdę tak naprawdę nie przyjrzałeś się wymaganiom). Wracam do interesariuszy, aby uzyskać odpowiedzi.

Podczas gdy czekam na ich odpowiedzi, zastanawiam się nad moimi rozwiązaniami i sprawdzam, czy któreś są lepsze od innych lub czy byłyby lepsze, gdy tylko otrzymam odpowiedzi na pytania. Na przykład, jeśli natychmiast potrzebujesz odpowiedzi na pytania, mógłbym wybrać ten, który ma najszybszy rozwój, ale pozostawiając otwarty sposób na ulepszenie projektu w późniejszym czasie. Jeśli powiedzą mi, że wydajność ma kluczowe znaczenie, to sprawdzam rozwiązania i określam, które z nich będzie bardziej wydajne (są to w tym momencie domysły, ale ogólnie są one dobrze poinformowane). Jeśli w grę wchodzi GUI, mógłbym stworzyć papierowy prototyp kilku różnych projektów i zachęcić interesariuszy do ich przejrzenia, zanim cokolwiek koduję (zazwyczaj widzą, że zapomnieli powiedzieć o XYZ, który jest kluczowy dla projekt!)

Gdy otrzymam odpowiedzi, wybieram wstępny projekt, a następnie sporządzam listę wszystkich rzeczy, które będę musiał zrobić, aby go wdrożyć. Potem zaczynam kodować.

... mam tendencję do wskakiwania w kodowanie bez prawdziwego planu i mam nadzieję, że wymyślę to w trakcie.

Zrobiłem to na uniwersytecie. Stało się to prawdziwym problemem i zwykle spowodowałoby przepisanie kodu. Zacząłem się temu zajmować, nie pisząc kodu. Położyłem nacisk na myślenie o problemie. Przy wystarczającej praktyce instynktownie sięgam po myśli, a nie po klawiaturę.

... w wywiadzie było to całkiem nieudane, jeśli nie wręcz przeciwnieproduktywne. Nie zawsze czuję się komfortowo siedząc i myśląc, gdy zegar tyka.

W trakcie wywiadu musi istnieć uzasadnione, przemyślane wdrożenie rozwiązania, które nie zawsze przychodzi łatwo. To, czego nie chcesz robić, to wymazywanie odpowiedzi bez zastanowienia. Jeśli znasz odpowiedź, szybko ją udziel. Jeśli nie, polegaj na swoich myślach, aby znaleźć rozwiązanie. Zawsze wskazuj, kiedy nie wiesz, i pokaż, jak możesz znaleźć rozwiązanie.

Czy istnieje lista kontrolna lub istnieją techniki rozpoznawania, gdy rozumiesz problem wystarczająco dobrze, aby rozpocząć kodowanie?

Odradzałbym takie, ponieważ możesz na tym polegać sztywno. Zadaj sobie raczej pytanie, czy rozumiesz problem wystarczająco dobrze, aby rozpocząć kodowanie. Skąd mógłbyś wiedzieć? Ponieważ kiedy uzasadnisz swoje podejście, a następnie je przeanalizujesz, biorąc pod uwagę Twoją obecną znajomość języka, będzie to miało sens. Zawsze miej plan i podejście. Pamiętaj także, że kod nigdy się nie kończy, a kod, który nie ewoluował, umrze, więc często powracaj do niego.

Kiedy najbardziej produktywne jest myślenie i projektowanie bardziej niż kodowanie niektórych eksperymentów i późniejsze opracowanie całościowego projektu?

Będziesz chciał poznać cały projekt i przemyśleć go. Następnie zaczynasz tworzyć strukturę klasy i kody pośredniczące. Następnie przejrzyj go ponownie. Czy ma sens? Eksperymenty z kodowaniem to świetny sposób na wykazanie, że coś działa dobrze i należy go używać, ale nie należy polegać na modzie lub kształtowaniu pisanego kodu.