Właściwe połączenie planowania i programowania nowego projektu

Zaraz rozpocznę nowy projekt (gra, ale to nieważne). Podstawowa idea tkwi w mojej głowie, ale nie wszystkie szczegóły.

Nie chcę zaczynać programowania bez planowania, ale poważnie walczę z pragnieniem, aby to zrobić. Chcę wcześniej zaplanować, aby zapobiec refaktoryzacji całej aplikacji tylko dlatego, że wymaga nowej funkcji, o której mogłem pomyśleć. Z drugiej strony nie chcę planować wielu miesięcy (czasu wolnego) i zaczynać od tego, ponieważ obawiam się, że w tym czasie stracę motywację.

To, czego szukam, to sposób na połączenie obu bez dominacji nad drugą. Czy powinienem realizować projekt na sposób scrum? Czy powinienem tworzyć historie użytkowników, a następnie je realizować? Czy powinienem pracować w oparciu o funkcje? (Mam pewne doświadczenie w scrumie i klasycznym sposobie „specyfikacji na kod”).

Aktualizacja : co powiesz na rozpoczęcie od „manekina kliknięcia” i późniejsze wdrożenie tej funkcji?

Jesteś na dobrej drodze. Nie musisz spędzać miesięcy na planowaniu, ale zdecydowanie powinieneś mieć jakiś plan.

Planowanie pomoże Ci uporządkować myśli, zidentyfikować potrzebne technologie, wyjaśnić problemy i da Ci mapę drogową do pracy, z której możesz podzielić się na mierzalne cele.

Ponadto możesz zaplanować kilka dni, aby odkryć, że jest to strata czasu. Być może podczas planowania zdajesz sobie sprawę, że jesteś daleko od swojej ligi lub że to, co próbujesz zrobić, nie może zostać sprzedane. Lepiej to teraz odkryć, abyś mógł ponownie zainwestować swój czas w inne swoje pomysły, niż iść tą drogą tylko po to, by zgubić się w lesie, otoczony przez strome winorośle i ścieżki omylnej logiki, która kręci mózg w węzły.

Zaplanuj minimalny opłacalny produkt i zaimplementuj go. Następnie posłuchaj użytkowników, zaplanuj kolejne ulepszenie logiczne i zaimplementuj je. Powtarzać.

Bez względu na to, ile czasu spędzasz na planowaniu i projektowaniu programu, zawsze i tak przepisujesz jego części. To jak grawitacja, a nie sprytne zaprzeczanie jej istnieniu.

Trzeba zdawać sobie sprawę, że refaktoryzacja jest normalną częścią rozwoju i to tylko kwestia decyzji, kiedy to zrobisz. Poczekaj długo, a skończysz z ogromną ilością spaghetti, błagając o całkowite przepisanie. Nie śmieszne.

Moją propozycją jest trochę zaplanować, ale zacznij kodować jak najszybciej i refaktoryzuj, refaktoryzuj, refaktoryzuj, aby utrzymać kod w dobrej formie. Zasada DRY (nie powtarzaj się) jest do tego świetnym wskaźnikiem.

Kiedy jestem na tej pozycji, czasami korzystam z TDD (programowanie testowe) i zaczynam planować testy dla najbardziej złożonej części opracowywanego przeze mnie systemu. Alternatywnie, mogę złożyć jakiś pseudo-kod wysokiego poziomu, ponownie dla najbardziej złożonych obszarów. Uważam, że ten proces daje mi luźny plan działania i pomaga mi określić, które obszary mogą być najbardziej czasochłonne.

Dla mnie to podejście działa, ponieważ żyje gdzieś pomiędzy kodowaniem a planowaniem. Gdy masz już pomysły na test i / lub pseudo kod, możesz przejść przez każdą sekcję logiczną i zaimplementować kod. Często najpierw stawiam czoła najtrudniejszej części proponowanego rozwiązania, ponieważ zazwyczaj najtrudniejsza część jest podstawową funkcją aplikacji i zawsze można opóźnić wszelkie dzwonki i gwizdy.

Ponieważ komentujesz, że większość kodu jest w twojej głowie i jesteś gotowy, aby zanurzyć się i zaprogramować, zastosowanie tego podejścia może pomóc ci skoncentrować się na każdej sekcji bez zmącenia umysłu przez system jako całość.

Podsumowując bardziej zwięźle, można powiedzieć: „Najpierw zmierz się z najtrudniejszą częścią, podziel i podbij za pomocą pseudo kodu i / lub planów TDD”!

Po prostu spróbuj uczynić kod modularnym. Wszystko, co planujesz, zostanie prawdopodobnie wyrzucone podczas następnej iteracji.

Poleciłbym przynajmniej zapisać swoje pomysły. W zależności od wielkości projektu może nie być wymagane wiele formalnego planowania. Jeśli jednak jest bardzo duży, możesz zaoszczędzić sobie bólu głowy i poświęcić kilka dni na bardziej szczegółowe planowanie.