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

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.

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.

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”

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.

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.

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.

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.

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.

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.

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 .

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.

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.

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.

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ć.

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 .

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.