Czy normalne jest myślenie o problemie projektowym przez wiele dni bez napisanego kodu? [Zamknięte]

52

Czasami patrzę tępo w przestrzeń lub szkicuję pomysły i piszę pseudo-kody na papierze. Następnie wykreślam go i zaczynam od nowa, a kiedy myślę, że mam właściwe rozwiązanie problemu, zaczynam pisać kod.

Czy myślenie przez wiele dni bez pisania kodu jest normalne? Czy to znak, że podchodzę do problemu zupełnie źle? Denerwuje mnie to, że nie dostaję żadnego namacalnego kodu zapisanego w moim IDE.

Kim Jong Woo
źródło
9
To zależy od problemu i twojego indywidualnego procesu myślowego. Jeśli dotrzymasz terminów, nie ma znaczenia, ile czasu poświęciłeś na myślenie i ile kodujesz.
yannis,
4
Próbowałeś narysować komponenty na tablicy? Czasami, gdy mam do czynienia z dylematem projektowym lub złożonym algorytmem, po prostu zaczynam rysować. Jeśli utkniesz, być może próbujesz za dużo przetrawić w swoim umyśle. Spróbuj rozłożyć rzeczy na małe i łatwo przyswajalne składniki, a następnie narysuj, jak te różne elementy oddziałują. Nie ma potrzeby formalnych standardów, robię coś w rodzaju UML Poor Man, kiedy jestem na tablicy.
wałek klonowy
2
raczej pomyśl o projektowaniu przez kilka dni niż o szybkim wdrażaniu złego projektu
Chani,
4
Tak to jest! I czasami patrzę na kod, który już napisałem i chciałbym pomyśleć o projektowaniu przed jego napisaniem :-)
Giorgio
2
Jak na ironię informatyka często jest niezależna od komputerów
Ryan Kinal 10.11.11

Odpowiedzi:

60

W zależności od problemu, który próbujesz rozwiązać, faza projektowania może potrwać tygodnie i miesiące (jeśli nie lata), a nie tylko dni.

Doświadczenie nie wymaga natychmiastowego wypuszczania kodu. Myślenie o architekturze i projektowaniu na wysokim poziomie powinno zająć dni, jeśli nie dłużej - zdecydowanie coś, co powinno się zdarzyć, zanim zaczniesz pisać kod.

Oded
źródło
1
+1 przez lata. Był zaangażowany w grupę, w której w następnym pokoju był zespół, który był zaangażowany w zbieranie wymagań dotyczących nowego systemu przez 5 lat, bez końca. Poważnie wątpiliśmy, czy kiedykolwiek pójdą dalej.
jwenting
8
@jwenting ... to też nie jest dobre, ci faceci powinni chyba zacząć pisać.
Grady Player
8
@jwenting, tak, to się nazywa metoda wodospadu i każdy z nich powinien zostać zwolniony. Jeśli nie możesz zrozumieć, co próbujesz zrobić w ciągu roku, nigdy nie będziesz w stanie wprowadzić go na rynek, zanim sama technologia stanie się przestarzała.
riwalk 10.11.11
1
Obawiam się, co by się stało, gdyby zaczęli wypuszczać kod, wszyscy byli analitykami biznesowymi, nie
znającymi się na
24

Jest to powszechnie określane jako „paraliż analizy”

To powszechne, ale złe. W pewnym momencie musisz przetestować różne pomysły, aby zobaczyć, co będzie dla ciebie najlepsze, a następnie stopniowo je poprawiać.

Zalecane przeczytanie programisty Pragmatic, a konkretnie rozdziału 2 sekcji „Pociski śledzące”

rev Morons
źródło
12
mylisz się, zakładając, że niekoniecznie źle jest spędzać czas na projektowaniu systemu. W przypadku czegoś trywialnego dni mogą wydawać się długim czasem, w przypadku dużych systemów, które obejmują dziesiątki tysięcy lub setki tysięcy wierszy kodu, jest to zdecydowanie za mało czasu, aby uzyskać podstawową architekturę na papierze.
jwenting
3
Czas poświęcony na myślenie jest bezpośrednio związany ze złożonością problemu. Ale jeśli „denerwuje się, że nie dostanie żadnego namacalnego kodu zapisanego w moim IDE, zrobię to”, uważam, że bezpiecznie jest założyć, że musi zacząć.
Morons,
7
W ŻADNYM SPOSÓB NIE POWIEDZIAŁEM, że „źle jest spędzać czas na projektowaniu systemu”
Morons,
4
@ Morons: nie ma znaczenia, co mówisz, ważne jest to, co ludzie słyszą, a ludzie słyszeli, jak mówisz, że to, co robi OP, jest złe.
whatsisname 10.11.11
5
Termin „paraliż analityczny” implikuje, że analizowanie decyzji poświęca zbyt dużo czasu. To rzeczywiście prawdziwy problem, ale z oryginalnego postu wcale nie jest jasne, czy tak jest w obecnej sytuacji. Jeśli spędzasz kilka dni na przemyśleniu, jak napisać funkcję odwracającą łańcuch, to jest paraliż analizy. Jeśli spędzasz kilka dni zastanawiając się, jak napisać nowy kompilator c ++ przed rozpoczęciem, to przynajmniej możesz to zrobić.
PeterAllenWebb
10

Jest to całkowicie powszechne. Jeśli jednak zastosujesz podejście „Najpierw przetestuj” lub TDD, jest to mniej powszechne i może pomóc w lepszym sformułowaniu pomysłów.

Kok
źródło
5

Nawyki są zwykle wynikiem prób i błędów w podejściu do rzeczy i kontynuowania tego, co daje nam pożądane wyniki i unikania tego, co nie. W grę wchodzi również robienie tego, co lubimy i unikanie tego, czego nie lubimy. To działa do pewnego momentu, ponieważ w końcu zrobimy coś, co nam się nie podoba, aby opłacić czynsz.

To zależy od tego, co Cię do tego doprowadziło, i twoich powodów. Tu jest kilka:

  • Zbyt często trzeba było zmieniać kod z powodu zmian w projekcie
  • Nie zmieniasz złego projektu, ponieważ mniejsze rozwiązanie zostało już zakodowane
  • Wolisz rysować i projektować niż pisać odkładanie kodu
  • martwienie się o składnię i szczegóły kodowania odwraca uwagę od myślenia o lepszych projektach.

Mamy nadzieję, że odkryłeś, że jeśli projektujesz dłużej, Twój kod jest lepszy. Jeśli spojrzysz wstecz i zobaczysz, że nie ma znaczenia, ile czasu spędzasz na projektowaniu, możesz to zmienić. Innym zagadnieniem jest to, jak często wykrywacie problemy po napisaniu kodu w porównaniu do pracy z projektami. Jeśli nie znajdziesz problemów, dopóki nie napiszesz kodu, powinieneś rozważyć równowagę i zacząć kodować coś wcześniej niż później. Być może to podejście może być zastosowane do zastosowania nowszych technologii lub bardzo złożonej funkcji.

Nie wiem, czy mam dyscyplinę, by trzymać się jednego lub drugiego podejścia, nawet jeśli odkryję, że jedno działa lepiej od drugiego. Czasami czuję potrzebę pójścia na białą tablicę; inni klawiatura.

JeffO
źródło
4

Jest to bardzo powszechne i uważam, że jest to lepszy sposób na radzenie sobie i rozumienie rzeczy. Podczas pracy nad projektem wielokrotnie utknąłem i zrozumienie, w jaki sposób mogę podejść do niego lepiej, zajmuje dzień lub dwa. Nawet po rozwiązaniu problemu czekam na upływ dnia. To sprawia, że ​​jestem bardziej odświeżony i zaczynam.

Jest to naturalne zjawisko i dobre dla dewelopera przechwytywanie jego czasu i pomiędzy.

Pankaj Upadhyay
źródło
4

Kiedy wziąłem kurs zarządzania projektami, jedną z rzeczy, które instruktor opowiedział nam o planowaniu, która utkwiła mi w głowie, było to, że podstawową zasadą, której nauczali w wojsku, było 1/3 czasu na planowanie . Więc jeśli miałeś operację, która wymagała ukończenia za 3 miesiące, pomyśl o poświęceniu miesiąca na planowanie przed rozpoczęciem realizacji.

Scott Whitlock
źródło
4

Moim zdaniem istnieją trzy podejścia, każde dostosowane do konkretnej sytuacji kodowania

  1. Wcześniej widziałem podobny problem, więc mam całkiem dobre pojęcie o zastosowanych wzorcach i jasne, jak rozwiązanie powinno zachowywać się i reagować.

    => Użyj BDD / TDD, zaczynając od pożądanych rozwiązań i pracując nad kodem. (Ok, czasem oszukuję i piszę trochę kodu, a potem test - rodzaj zagnieżdżonego podejścia 2. -> 1.).

  2. Mam dobry pomysł na zastosowanie wzorców, ale nie jestem pewien, jak powinno wyglądać rozwiązanie.

    => Prototyp, aby zobaczyć, jakie ciekawe rzeczy wyskakują. Przejdź do 1., kiedy wymyślę, które interesujące rzeczy są pożądane.

  3. Nie jestem pewien, jakie wzorce zastosować.

    => Pomyśl o tym problem i jak różne sposoby podejścia do problemu wpływają na kod. Przejdź do 2) lub 1) w zależności od wyniku tego ćwiczenia.

Innymi słowy, odpowiedź jest ulubiona przez inżyniera: to zależy.

forforf
źródło
3

Lepiej spędzić miesiąc na myśleniu i projektowaniu niż na szybkim prototypie opartym na projektach niespełniających standardów, które następnie trzeba uformować. Zwłaszcza jeśli jesteś w zespole; gdy inne zaczną działać w zależności od twojego kodu, znacznie trudniej jest zaimplementować lepszy projekt z innym API.

TMN
źródło
2

Zgadzam się z innymi odpowiedziami, że w zasadzie dobrym pomysłem jest poświęcenie czasu na przemyślenie problemu / rozwiązania. Jeśli jednak czujesz, że utknąłeś, mam kilka zaleceń dotyczących sposobów, aby proces planowania był bardziej spójny:

  • Twórz artefakty projektowe. A co jeśli nie napiszesz kodu? Może po prostu zapisujesz dziennik swoich myśli. Lub szkic ogólnego rozwiązania. Lub nawet naprawdę dobre podsumowanie problemu, który udoskonalasz w miarę upływu czasu. Gdy zastanawiasz się nad pomysłami i je akceptujesz / odrzucasz, przechowuj logikę swojego rozumowania na ten temat. W ten sposób pod koniec dnia nadal możesz wskazać rzeczywiste produkty jako dowód swojej pracy.

  • Rozmawiać z ludźmi! Nie ma to jak mieć żywą, oddychającą istotę ludzką, z którą można dyskutować o pomysłach. Jeśli uważasz, że utknąłeś, porozmawiaj z kimś. Złap kogoś - kogokolwiek! - i wyjaśnij mu problem. Naszkicuj swoje przemyślenia na temat rozwiązania problemu. Nawet jeśli wdychają, wydychają i mrugają przez dziesięć minut podczas bełkotania, istnieje szansa, że ​​odkryjesz nowy wgląd w trakcie wyjaśniania problemu .

Stephen Gross
źródło
1

Jak powiedziała Satchel Paige: „Czasem siedzę i myślę, a czasem po prostu siedzę”.

Wydaje mi się, że miał na myśli to, że czasem dobrze jest oczyścić umysł, ponieważ może to skłonić cię do myślenia o swoim problemie w inny sposób. Tak więc, jeśli nie obijasz się o kod, możesz wymyślić rozwiązanie lub pomysł, który w innym przypadku mógłby cię ominąć. Tak, to normalne i dobrą praktyką jest nieskakiwanie do kodowania.

Są dwa sposoby, aby samodzielnie wykonać ten proces. Tworzę folder, w którym mam plik tekstowy i wszelkie rysunki związane z projektem. Zapisuję tam swoje pomysły i staram się zapisać cały proces myślowy najlepiej jak potrafię. Stworzę również projekt notatnika, w którym mogę szybko przetestować proste pomysły, od algorytmów po układy CSS.

jfrankcarr
źródło
1

Program = algorytm + struktura danych

IMHO, proces projektowania (rozwiązywania problemów) całkowicie rządzi. Szczegóły implementacji (problemu technicznego) następują i rozwiązują w naturalny sposób.

Terry Li
źródło
Bardzo podoba mi się to uproszczone równanie. +1
Kim Jong Woo
1

Oto moja przemyślana sprawa.

  1. Zaczynając od zera Najpierw należy z grubsza zorientować się, czego chcesz. Spróbuj uzyskać listę niektórych wymagań lub utwórz je. Rozumie się tutaj. Gdy masz przynajmniej kawałek, na który masz pewność, że chcesz, znając większość interfejsu tego elementu, zacznij kodować.

  2. Rozwiązywanie problemu z istniejącym kodem Najpierw prześledź problem. Może to wymagać trochę czasu, aby nie napisać prawdziwego kodu (Niektóre kody debugowania mogą zostać napisane, ale zwykle nie zostaną zachowane). Po znalezieniu problemu, w zależności od złożoności, zacznij pisać kod, aby spróbować go naprawić. Po znaniu błędu nie trzeba się zastanawiać. Jeśli problem okaże się poważną wadą projektową, zobacz następną sekcję.

  3. Zmiany w projekcie / główne cechy Jest to najprawdopodobniej ten, który będzie wymagał najwięcej przemyślenia. Należy uwzględnić myśl o zachowaniu struktury, kompatybilności wstecznej itp. Zastanawianie się nad najlepszą zmianą może zaoszczędzić znaczny czas, ale zazwyczaj dla mnie to nie więcej niż kilka dni.

  4. Dodawanie prostej funkcji Jeśli nie jest wymagana znacząca zmiana projektu, po prostu koduj swoją funkcję, używając pewnych prób / błędów. Nie powinno to generalnie wymagać dużo czasu.

PearsonArtPhoto
źródło
0

Nie zgadzam się z konsensusem w tej sprawie. Wolę zacząć prototypować coś, jak tylko będę miał najgłupszy pomysł napisany na serwetce, jak chcę, aby mój system działał. Jest prawie niemożliwe, żebym wymyślił wszystkie drobne szczegóły, które mogą powodować problemy, chyba że sprecyzuję wszystko w bardzo precyzyjny sposób. Jeśli tylko rozmawiam o projektowaniu z ludźmi, zbyt łatwo jest machać ręką wokół bardziej złożonych problemów. Kiedy określam takie rzeczy, może to być również bezpośrednio w kodzie źródłowym, a nie jakiś inny sposób wyrażania, który jest tak samo precyzyjny i formalny, ale nie można go skompilować i wykonać.

dsimcha
źródło
3
Istnieje różnica między ustaleniem szczegółów a ustaleniem podstaw. Na przykład, jeśli chcesz zaprojektować język, musisz zdecydować, czy Twój język jest proceduralny czy funkcjonalny, zanim zbliżysz się do klawiatury. Nikt nie mówi, że musisz wymyślić szczegóły podczas planowania, ale musisz wiedzieć, dokąd zmierzasz.
riwalk 10.11.11
@ Stargazer712: Całkowicie się zgadzam. Dlatego powiedziałem, że potrzebujesz przynajmniej serwetkowego pomysłu, co do cholery zamierzasz zrobić. Jednak w sposób, w jaki zadawano to pytanie, wyobrażałem sobie dni lub tygodnie formalnych, biurokratycznych spotkań, a nawet próbowałem wypracować prototyp nawet najbardziej ryzykownych / nowatorskich / interesujących elementów.
dsimcha
0

To zależy od tego, co masz na myśli mówiąc „normalny” . Mówiąc o sobie, myślę, że kod jest doskonałym narzędziem do nauki. Tak więc, w obliczu złożonego problemu, robię szkice na papierze, ale także koduję testowo. Kod mówi mi, że tablica nie może powiedzieć i na odwrót, a być może wynikiem jest wgląd lub potrzeba zadawania kilku pytań ekspertowi w tej dziedzinie.

Tak więc prawdziwa rada brzmi: „Użyj każdego narzędzia edukacyjnego, aby zbliżyć się do definicji problemu” , ale także „pamiętaj, że są to narzędzia edukacyjne, więc nie zakochaj się w nich” zarówno kod, jak i szkice mają być wyrzucane .

ZioBrando
źródło
0

W erze RAD i programowania zwinnego powinieneś zacząć rozwijać się, gdy tylko będziesz w stanie zidentyfikować główne części systemu, pojawią się szczegóły. Ponieważ oprogramowanie staje się coraz większe, przedwczesne skupienie się na każdym szczególe nie doprowadzi cię do nikąd.

Syed Aqeel Ashiq
źródło
2
A nie skupianie się na wystarczającej liczbie szczegółów może doprowadzić cię do miejsca, w którym nigdzie nie jest o wiele lepsze miejsce.
Dunk
@Dunk Użyłem trzech słów: przedwcześnie, każdy, o skupieniu się na szczegółach. Nie powiedziałem, żeby od razu waliło w klawiaturę: Get drift man.
Syed Aqeel Ashiq