Jak radzić sobie z porażeniem analizy?

60

Bardzo często utknąłem przy wyborze najlepszej decyzji projektowej. Nawet w przypadku drobnych szczegółów, takich jak definicje funkcji, przepływ sterowania i nazwy zmiennych, spędzam niezwykle długie okresy, analizując korzyści i kompromisy z moich wyborów.

Czuję, że tracę dużo wydajności, spędzając godziny na takich nieistotnych szczegółach. Mimo że w głębi duszy wiem, że mogę zmienić te rzeczy, jeśli mój obecny projekt się nie powiedzie, mam problem z podjęciem zdecydowanego wyboru.

Co powinienem zrobić, aby zwalczyć ten problem?

8
źródło
Porozmawiaj z kolegą na tablicy. To często pomaga wyjaśnić sprawę, a jeśli się zgodzisz, to ma szansę być dobrym wyborem

Odpowiedzi:

34

Dwie proste zasady:

  1. Zrób najprostszą rzecz, która może działać.
  2. Refaktoryzuj w sposób ciągły.

Gdy zaczniesz robić każdą z tych rzeczy, zyskasz pewność, że możesz teraz podejmować proste decyzje bez uszczerbku dla twojej zdolności reagowania na zmiany później.

Pamiętaj, że korekta w przyszłości oznacza łatwość zmiany kodu, a nie próbowanie przewidywania wszystkich możliwych sposobów zmiany kodu.

Rein Henrichs
źródło
4
Ciągłe refaktoryzowanie jest uzasadnione tylko wtedy, gdy masz dobry zasięg testu. Powiedziałbym więc: „Napisz test jednostkowy. Następnie zrób najprostszą rzecz, aby test zdał. Refaktoryzacja. Powtórz”.
kevin cline
Zdecydowanie się zgadzam. „Czerwony, zielony, refaktor” jest właściwą drogą.
Rein Henrichs,
5
Urocza mała smakołyk z podręcznika XP, ale tak naprawdę nie jest to świetna rada, gdy zostanie wyjęta z kontekstu.
Aaronaught
2
Poza kontekstem jest to dosłownie odpowiednik kodowania kowbojskiego. Zobacz Fowler Is Design Dead? który przestrzega przed zasadami wybierania wiśni z XP i podobnymi metodami. Być może jesteś doskonałym projektantem i programistą i jesteś wewnętrznie i domyślnie zdolny i zmotywowany do zachowania integralności pojęciowej podczas refaktoryzacji, ale większość programistów nie jest, a udzielanie im tych rad poza kontekstem jest nieodpowiedzialne (chociaż wszyscy uwielbiają to słuchać, ponieważ oznacza to dla nich mniej pracy).
Aaronaught
1
„Zrób najprostszą rzecz, która mogłaby ewentualnie zadziałać” nie wymaga dodatkowego kontekstu. Refaktoryzacja tak, ale w jaki sposób ktoś, kto nie zna kontekstu, nauczyłby się refaktoryzacji, gdyby się tego nie nauczył?
Rein Henrichs,
9

Zwykle, gdy czuję się w ten sposób, oznacza to, że muszę spróbować:

  1. Wstań, chodź i upewnij się, że cała biologia działa poprawnie.
  2. Podejdź do tablicy i rysuj, aż poczuję się pewnie.
  3. Znajdź „kumpla reklamującego projekt”, z którym możesz porozmawiać o problemie.

Jeśli problem dotyczy składni i małych elementów, wówczas:

  1. Przekonaj się, że nawet jeśli jest brzydka, jest gdzieś ładnie zamknięta i reprezentuje czysto lokalny rodzaj cruft.
  2. Dodaj znaczniki DO ZROBIENIA lub po prostu komentarze wyjaśniające, dlaczego kod Cię popełnił.
  3. Przejdź do następnego zadania.
Darien
źródło
+1 dla pierwszego i drugiego # 2. Rysowanie ramek, linii i etykiet oraz uzyskiwanie dużych zdjęć zwykle pomaga mi wybierać między opcjami. Jeśli masz ładny analizator kodu, który śledzi zadania (Hudson może śledzić zadania TODO i ładnie wyświetla je w twoich kompilacjach), możesz łatwo śledzić rzeczy, których nie lubisz.
Randy
5

Bardzo łatwo jest myśleć o bezczynności. Nawet jeśli uda jakoś wymyślić najlepsze rozwiązanie w tej chwili , że może łatwo zmienić przed zakończeniem projektu, a co potem?

Lepiej wybrać przyzwoite rozwiązanie i biegać z nim, niż usiąść i zastanowić się, jakie byłoby najlepsze rozwiązanie. Najlepsze rozwiązanie jest nieuchwytne, a co gorsza - subiektywne. Jeśli wymagania zmienią się nawet nieznacznie, Twoje rozwiązanie może okazać się gorsze niż rozwiązanie, które odrzuciłeś, ponieważ nie było wtedy najlepsze.

Satanicpuppy
źródło
Zdaję sobie z tego sprawę, ale nadal mam trudność z wyborem jednego wyboru.
Anne Nonimus,
@anne: Lepiej zrobić coś konstruktywnego od razu, niż zrobić coś zbyt późno. Jedyną rzeczą, która z pewnością będzie niewłaściwa, jest nic nie robić.
Satanicpuppy
4

Uczę się również unikać paraliżu analizy, więc cześć dla nas =) To często się zdarza, ponieważ chcemy zrobić „najlepszy projekt”. W rzeczywistości „najlepszy” jest w oku patrzącego . Moją formułą, aby uniknąć paraliżu analizy, jest zastosowanie wystarczająco dobrej zasady projektowania . Jak ja to robię? Wprowadzam zmienne takie jak ograniczenia czasowe, harmonogram i zadaję sobie pytanie, jaki jest najprostszy projekt, który może wykonać zadanie (nie oznacza to najłatwiejszego) bez pogorszenia jakości, ale jednocześnie upewniam się, że jest to testowalne i otwarta na przedłużeniu zamknięte modyfikacji (OCP)również projekt. Co mam na myśli przez testable i OCP? Cóż, zamiast szukać tego, co uważałem za najlepsze, zastanowiłem się nad projektem, który może mi powiedzieć, kiedy coś idzie nie tak, i spróbować zrobić tyle kodu, który pozwoli mi zreformować i poprawić później. Ponadto, staramy się oddzielić kod, który będzie się zmieniać wraz z kodem, który pozostaje taki sam. Refaktoryzacja staje się łatwiejsza, ponieważ kod, który nie powinien się zmieniać, jest bezpieczniejszy od twojej przyszłej ciebie lub kogoś innego.

Armando
źródło
2

Co powiesz na to, by pozwolić sobie na przeczucie wyboru jednej z opcji? Powinno to iść dość szybko i dobrze łączyć się z timeboxingiem , który również zaproponował ammoQ . Możesz spróbować limitu 1 minuty, jeśli opcje są już ustalone, lub 2 minut, jeśli musisz je najpierw zdefiniować. Lub cokolwiek wydaje się właściwe (zdefiniowane wcześniej). Kiedy nauczysz się słuchać instynktu jelitowego, intuicyjny wybór stanie się szybszy i lepszy z praktyką .

Jeśli martwią Cię możliwości wybrania nie idealnie, oto kilka pomysłów na rozwiązanie tego problemu:

  • Gdyby istniała opcja z wyraźną przewagą nad innymi, nie zadałabyś sobie wyboru. Dzięki takiemu rozumowaniu, ilekroć nie jesteś zdecydowany, co do wyboru w niezbyt skomplikowanej sprawie, oznacza to, że wszystkie opcje są całkiem równe; więc nie ma wiele do stracenia , wybierając jedno z nich.
  • To powiedziawszy, intuicja wcale nie jest przypadkowa, ale całkiem niezła, wykształcona domysł dla optymalnego rozwiązania. Często lepsze niż to, co można wymyślić poprzez niekończące się szperanie.
  • Uwzględniając perfekcjonizm, można oceniać szybkość decyzji wyższą niż optymalność wyboru, gdy półświadomie ocenia się wydajność. Co jest całkowicie sensowne w przypadku nieistotnych wyborów, ale nie jest łatwe do zapamiętania.

Powodzenia! :)

TatuażUkład
źródło
2

Myślę, że to odchodzi z małym doświadczeniem. Większość mojego paraliżu dzieje się, ponieważ próbuję sobie wyobrazić, jak baza kodu będzie wyglądać znacznie dalej, niż jest to konieczne, więc aby ją przezwyciężyć, po prostu robię najprostszą możliwą rzecz, która zadziała, a następnie przejdę dalej. Gdy projekt ma określony kształt, powtarzające się jednostki kodu zaczynają się wyróżniać i łatwo jest wyodrębnić powtarzające się wzorce i uprościć kod.

davidk01
źródło
1

Aby przezwyciężyć niechęć do decydowania, zastosuj timeboxing : ustaw budzik na kilka minut; dręczyć swój umysł do tego czasu, ale kiedy włączy się alarm, wybierz najlepszą z dotychczas dostępnych opcji.

281377
źródło
3
A potem może spędzić godziny, dręcząc się dokładnie, jak długo powinien być ustawiony budzik! :)
Jordan
1
Jordan: Istnieje kilka możliwych rozwiązań tego problemu. Niestety nie mogę zdecydować, który z nich zaproponować.
user281377
0

Utwórz prototyp. Pamiętaj, że prototyp został wyrzucony, więc nie ma znaczenia, jakich funkcji, nazwy zmiennej, a nawet wielkiej architektury używasz. Po prostu budujesz go, aby udowodnić, że działa.

Gdy go utworzysz i wyrzucisz, chętnie się założę, że podejmowanie takich decyzji będzie łatwiejsze.

tylermac
źródło
Nigdy nie powinieneś wyrzucać prototypu, ponieważ być może możesz go rozwinąć później, gdy dodasz funkcję. A może musisz przetestować błąd za pomocą SSCCE. Zawsze kontroluję źródła wszystkich moich prototypów w osobnym miejscu.
wałek klonowy
2
Myślę, że idea „wyrzucenia” nie polega na tym, że tracisz dane, ale na tym, że nie powinieneś używać prototypów jako podstawy programu, ponieważ celem prototypów jest eksperymentowanie ze swobodą popełniania błędów.
Darien
prototyp w oddziale, wykonaj niezbędne testy i utwórz czystą wersję w rdzeniu.
zzzzBov
0

Też cierpię z tego powodu. Powiedziałbym, że nie masz wystarczającej motywacji do ukończenia.

Na przykład, kiedy pisałem kod renderujący, miałem dużą zachętę do ukończenia, ponieważ wiedziałem, że gdybym sobie z tym poradził, zobaczyłbym system w akcji i pomyślałbym, jak wspaniale było pisać tekst na quadzie, lub przekształcenie vert. Ale teraz, kiedy zmieniam faktoring (próba 4, jeśli chcesz wiedzieć), cierpię, ponieważ to dużo pracy, a nawet jeśli skończę, zobaczę ten sam stary quad. I naprawdę nie chcę ponownie refaktoryzować i mam dość ciągłego oglądania tego samego starego quada i nie jest to dla mnie żadna nagroda.

Musisz rozbić go na komponenty i nagrodzić się za ich ukończenie, nawet jeśli jest to tylko niektóre we / wy konsoli, które pokazują, że działa.

DeadMG
źródło
0

Czytałem twoje pytanie i zastanawiałem się nad innymi plakatami: nie nadajesz się do tej pracy; wyznaczyć sobie termin; zrób coś jeszcze przez chwilę. Po krótkiej refleksji nie jestem pewien, czy którakolwiek z odpowiedzi jest tak pomocna

Problem z takimi problemami psychicznymi polega na tym, że nie są one łatwe do rozwiązania, są częścią ciebie i oczywiście zależy ci (zbyt wiele) na swojej pracy, nie masz pewności, by się ze sobą zgodzić, są też zbyt Niedoświadczony, że przez cały czas miałeś rację, lub zbyt mocno stresujesz się nad tym, aby idealnie go wybrać. Dlaczego miałbyś się martwić takimi błahostkami ?!

Teraz mam podobne problemy, ale nie tyle z kodem ... zwykle jest to, co na obiad .. pizza lub curry .. hmm ... pizza, ale curry jest fajne, ale czy czuję się jak curry, pizza jest tańsza , ale wtedy dostajesz więcej curry, ale ... i tak dalej. :)

Pomyślałem więc - dlaczego nie mam podobnych problemów z kodowaniem i myślę, że po prostu dlatego, że mam zestaw wzorców, z których regularnie korzystam. Jeśli potrzebuję definicji funkcji, to jest łatwe ... będzie w tym samym stylu, co każda inna definicja funkcji, jaką kiedykolwiek kodowałem. Jeśli potrzebuję przepływu kontrolnego, najpierw decyduję, czy potrzebuję pętli for, czy chwilowej, a następnie tworzę ten sam stary kod, którego użyłem ostatnim razem, gdy potrzebowałem jednej z tych rzeczy. To samo dotyczy wszystkiego, czy chcę kolejkę? Jasne - chodźmy wyciąć i wkleić mój „standardowy” kod kolejki (pobrany z ostatniego projektu, nad którym pracowałem, lub dowolnego, który pamiętam, używając jednej z tych rzeczy). Efekt końcowy ... Martwię się tylko o nowe rzeczy i szczerze mówiąc, to przyjemność.

Tak więc, radzę zacząć budować bibliotekę fragmentów kodu - zwykłem przesyłać je e-mailem do siebie i umieszczać w folderze, ale wszystko, z czym pracujesz, jest najlepsze - a wtedy zaczniesz wiedzieć, co robić za każdym razem. Zawsze przejdziesz do starego kodu, który napisałeś, i usuniesz problem z pracy, gotowy na następny problem. Przekonasz się, że zostałeś znacznie szybszym programistą (poważnie, to jedyny sposób na zwiększenie produktywności programisty) i mam nadzieję, że znajdziesz czas na zabawne elementy, a nie na ponure codzienne rzeczy, które już rozwiązałeś wiele razy koniec.

Oczywiście ostatnia część wszystkiego jest również ważna - im więcej pracy masz, tym mniej luksusu musisz poświęcić na myślenie.

gbjbaanb
źródło
programowanie fragmentów kodu jest najgorszą złą praktyką
Neil Butterworth,
@ Neil: Używanie fragmentów innych ludzi jako programowania fragmentów i niewiedza, co robią, jest złą praktyką. Korzystanie z własnych fragmentów kodu jest na ogół dobre, ponieważ prawdopodobnie rozumiesz, co napisałeś. Jeśli nie, to prawdopodobnie nie ma dla ciebie nadziei.
Jordan
@ Nee, dzisiaj jesteś w szczególnie złym humorze! Większość starszych programistów i tak ma ogromną bibliotekę fragmentów w swoich głowach, po prostu nie zauważasz, że ich używasz. Dla juniorów zapisywanie ich pomaga im to zbudować.
gbjbaanb
0

Oto strategia łącząca sugestie Reina Henrichsa ( rozpoczęcie proste, refaktoryzacja ) i amunicji ( timeboxing ):

  1. Daj sobie dość ścisły limit czasu na pierwsze rozwiązanie, które po prostu działa. Np. 30 sekund na nazwę zmiennej. Możesz najpierw wymyślić coś takiego x, a następnie dopracować string, a potem, nameaż czas się skończy.
  2. Następnie przejdź do innych zadań przez określony czas, np. 10 minut.
  3. Dopiero wtedy pozwól sobie na kolejne pole czasowe dla dalszej poprawy swojej decyzji, npuserHandle

Możliwe korzyści z tego podejścia:

  • wiedza o powrocie do tego później może na razie złagodzić problem
  • kontynuując inne zadania, możesz po prostu znaleźć dobre, satysfakcjonujące rozwiązanie bez czasochłonnego szperania
  • po puszczeniu kroku 1 i przejściu do kroku 2 , może być łatwo utrzymać krok 3 naprawdę szybko, ponieważ chcesz kontynuować krok 2, a zatem z radością wybierz jedno przyzwoite rozwiązanie i zaakceptuj je
TatuażUkład
źródło
Ta odpowiedź wydaje się bardziej szczegółowa i kompletna niż poprzednia , ale obie wydają się obejmować ten sam grunt. Połącz je w jedno lub wybierz, które chcesz zachować.
Adam Lear
@Anna Zrobiłem dwa osobne posty, ponieważ odkryłem, że zawierają one różne pomysły koncepcyjne, na które należy głosować niezależnie: Ten: odpuszczenie przez odłożenie ostatecznej decyzji. Poprzedni: uczucie jelit. Rzeczywiście obie techniki dobrze do siebie pasują, ale każda działa również bez drugiej.
Aaron Thoma,
0

Kiedy przeprowadziłem badania i nie mam jednoznacznego najlepszego wyboru, daję sobie limit czasu (zwykle 5 minut) na wybranie jednego, a następnie po prostu idę naprzód. Nawet jeśli napotkasz przeszkody, w tym momencie nie ma gwarancji, że nie trafiłbyś na taką samą przeszkodę, podejmując inną decyzję. Nie mogę wymyślić momentu, w którym żałuję swojej decyzji.

John MacIntyre
źródło
0

Zwykle powodem, dla którego nie możesz podjąć decyzji, jest to, że różnica jest nieznaczna lub nie masz wystarczającej ilości informacji.

W przypadku, gdy: a) Ustaw termin na przedstawienie rozsądnych opcji do rozważenia. Nie decyduj jeszcze, który z nich. Na koniec wybierz jedną (losowo, jeśli nie ma wyraźnej preferencji) ze wskazanych opcji i inny limit czasu. Jeśli pod koniec czasu nie zostanie podjęta jasna decyzja, jest to już ta wybrana. Rozpocznij kodowanie i dokonaj refaktoryzacji, jeśli wyraźnie popełniłeś błąd. Jeśli szef zapyta dlaczego, powiedz „Rzuciłem monetą, masz lepszy sposób?”

W przypadku b) - potrzebujesz więcej informacji, a siedzenie na dużym tłuszczu A .... przez cały dzień ich nie dostarczy. Wyjdź z trybu projektowania i przejdź do trybu zbierania informacji. Prototypy, zadawaj pytania, czytaj czasopisma techniczne. Cokolwiek robisz, nie śpij zbyt długo.

mattnz
źródło
0

Często najlepszym rozwiązaniem jest wyjaśnienie swojej decyzji koledze. Ponieważ jednak nie chcesz tego robić zbyt często, następną najlepszą rzeczą jest myślenie na papierze - albo za pomocą papieru / długopisu, albo pustego okna notatnika.

Zacznij od napisania absolutnie wszystkiego - tylko po to, aby wejść w rytm pisania. W oknie notatnika możesz po prostu wpisać „myślę na papierze”, a następnie kontynuować strumień świadomości. Po kilku sekundach będziesz w rytmie pisania, więc naciśnij kilka razy enter i zacznij wyjaśniać swój dylemat.

Określ problem, a następnie podaj możliwe rozwiązania, co jest dobre w każdym z nich itp.

Chociaż nie zawsze działa, proces wydobywania myśli z głowy (RAM) i na media zewnętrzne (dokument notatnika) daje większą swobodę nawiązywania nowych połączeń i patrzenia na decyzję z różnych perspektyw.

Saqib
źródło
0

Cierpię na ten sam problem. W przypadku drobnych problemów próbuję sobie z tym poradzić, jeśli chodzi o pierwszy projekt, który według mnie nie jest głupi. Nie ma sensu szukać optymalnego projektu; trudno jest, jeśli nie niemożliwe, uzasadnić wszystkie niuanse każdego projektu, o którym możesz pomyśleć bez napisania tego. W miarę pisania kodu zauważysz, że możesz wprowadzić niewielkie ulepszenia. Zrobione dobrze, uważam, że dość łatwo jest w ten sposób uzyskać dość dobre rozwiązanie.

W przypadku większych problemów wydaje mi się, że warto najpierw przemyśleć opcje, ale z czasem to zrobić. Duże problemy mają duże przestrzenie rozwiązań, nie możesz ocenić każdej możliwości, nie powinieneś też próbować.

TLDR; Wybierz rozsądne rozwiązanie, ulepszaj je na bieżąco.

Dotyczy to również:

Nauczyciel ceramiki ogłosił w dniu otwarcia, że ​​dzieli klasę na dwie grupy. Powiedział, że wszyscy po lewej stronie studia będą oceniani wyłącznie na podstawie ilości wykonanej pracy, wszyscy po prawej tylko na podstawie jakości. Jego procedura była prosta: w ostatnim dniu zajęć przynosił wagi łazienkowe i ważył pracę grupy „ilościowej”: pięćdziesiąt funtów garnków oznaczonych „A”, czterdzieści funtów „B” i tak dalej. Ci, którzy zostali oceniani na „jakość”, musieli jednak wyprodukować tylko jedną doniczkę - choć idealną - aby uzyskać „A”.

Cóż, nadszedł czas oceniania i pojawił się ciekawy fakt: wszystkie prace najwyższej jakości zostały wyprodukowane przez grupę ocenianą pod względem ilości. Wygląda na to, że podczas gdy grupa „ilościowa” zajęła się produkcją stosów pracy - i uczyła się na własnych błędach - grupa „jakościowa” siedziała w teorii o doskonałości, a na koniec miała niewiele więcej do pokazania za swoje wysiłki niż wielkie teorie i kupa martwej gliny.

z http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

dan_waterworth
źródło
-8

Nigdy tego nie zrozumiałem. Kiedy byłem instruktorem, powiedziałbym coś takiego:

"OK, create an integer variable and assign the return value of strlen() to it."

Może nie jest to zbyt skomplikowane, a 95% ludzi napisało coś takiego:

int x;   // or y, or len, or whatever
x = strlen( s );

Ale od czasu do czasu pojawiał się ktoś sparaliżowany w świetle reflektorów jak królik. Spytałbym współczująco, na czym polega problem, a oni powiedzieliby: „Nie wiem, jak to nazwać!”.

To są ludzie, którzy powinni szukać innej kariery. Jak może powinieneś.

Neil Butterworth
źródło
2
@Anne Nie przyjmuję założeń - sam powiedziałeś, że trudno ci wymyślić nazwy rzeczy - „Bardzo często utknąłem przy wyborze najlepszej decyzji projektowej. Nawet w przypadku drobnych szczegółów, takich jak ... nazwy zmiennych”
Neil Butterworth,
3
I dlaczego powinienem szukać innej kariery, ponieważ mam trudności z nazwaniem niektórych rzeczy? Nie każda koncepcja ma czyste, krótkie odwzorowanie na język naturalny.
Anne Nonimus
2
@Anne Wydaje mi się, że Twoim pierwotnym pytaniem jest problem z robieniem tego, co przychodzi naturalnie dobrym programistom. Nie ma w tym wstydu - większość ludzi (nawet większość programistów!) Jest okropna w robieniu tych rzeczy. Jednak zakładając, że podobnie jak ja możesz być szczęśliwy, robiąc coś, w czym jesteś naprawdę dobry, zasugerowałem, że programowanie może nie być tym, do czego jesteś przygotowany. Pierwsze 10 lat dorosłego życia spędziłem jako mikrobiolog. Nie byłem w tym zbyt dobry i byłem znacznie szczęśliwszy, kiedy zmieniłem się na programistę.
Neil Butterworth,
3
Przyjazne przypomnienie dla wszystkich: jeśli nie zgadzasz się z odpowiedzią, możesz użyć wyrażeń negatywnych, aby to wyrazić. Ataki osobiste z obu stron zostaną usunięte.
Adam Lear
3
Ostatecznie wydaje mi się, że odpowiedź jest dość surowa, ale komentarze sprawiają, że nie czuję się tak ostro. Być może powinieneś to edytować.
DeadMG