Rozplanowanie etapów tworzenia projektu.

Siemka, jakie macie sposoby na planowanie tego co ma sie znalezc w projekcie?

Dobrym pomysłem bedzie poswiecenie 30-60minut, aby wszystko rozpisac sobie np. na kartce i zacząc od tego jakie funkcje ma mieć, nastepnie podzielic to na klasy i na koncu na metody, ktore w tej klasie maja sie znalezc?

Co mozna jeszcze wrzucic do takiego planowania? Jest to dobry sposob na usprawnienie procesu samego pisania kodu?

Dobrym pomysłem bedzie poswiecenie 30-60minut - bardzo optymistycznie zważywszy na to, że zdarzało się czasem, że samo zbieranie potrzebnych funkcjonalności trwało całe tygodnie...

Myślę, że powinieneś nieco przybliżyć jaki to projekt bo w zależności od jego rozmiaru można dobierać różne metody tworzenia projektu. Czasem nie da się przewidzieć co będzie dalej jak nie dojdziemy do pewnego etapu..

@40naKlate: Ciężko powiedzieć. Jak wiesz, że twój system generalnie nie potrzebuje skomplikowanej persystencji to najlepiej skupić się na YAGNI i odraczać decyzje do samego końca

@slsy: ale nie przeginajmy w drugą stronę, bo pisanie wszystkiego w totalnej improwizacji może baaaardzo szybko doprowadzić do sytuacji, w której jakikolwiek dalszy rozwój czy modernizacje będą wymagały rewolucji.

Czasem myślę sobie, czego jeszcze brakuje i notuję w notesiku.
Dodaję też taski na GitHubie do issues.
Pytam ludzi, czego ich zdaniem brakuje w obecnej wersji projektu.

Im więcej czasu poświecisz na projektowanie, tym mniej na kodowanie po kilka razy tego samego. Ja staram się rozbijać projekt na małe zadania tak długo, jak nie potrafię takiego zadania wycenić. Oczywiście jak nabierzesz doświadczenia pewne rzeczy po prostu będziesz wiedział jak zrobić - bedziesz miał wzorce na typowe rozwiązania. Moim zdaniem warto przemyśleć projekt. Oczywiście na początku nie ustrzeżesz się błędów i będziesz robił niektóre rzeczy po klika razy - ale to normalna droga nauki.
Cytując Linkolna: Gdybym miał osiem godzin na ścięcie drzewa, spędziłbym sześć na ostrzeniu siekiery

Pamiętaj, że 2 tygodnie implementacji pozwala zaoszczędzić 15 minut planowania!

• Zacznij od zebrania danych dotyczących problemu i dobrego zrozumienia tego problemu
• Doświadczenie na tym etapie powinno podpowiedzieć, w którą stronę iść - zacznij mniej więcej planować
• Zacznij pisać z takim założeniem, żeby jak najszybciej wypuścić JAKĄŚ wersję
• Cofnij się do punktu pierwszego - upewnij się, że dobrze zrozumiałeś problem
• Sprawdź, czy to co napisałeś rozwiązuje problem
• Pomyśl o tym, co napisałeś. Jak będzie z dalszym rozwojem. Czy będzie łatwy, trudny, niemożliwy. Teraz dąż do tego, żeby był łatwy. Może to wymagać lekkiego przeprojektowania lub otworzą Ci się nowe pomysły/drogi.

Tworzenie systemu nigdy się nie kończy. System nigdy nie będzie idealny - nie dąż do tego, żeby był idealny. Wyciągaj wnioski, ucz się, poprawiaj. Działaj iteracyjnie.

Na początku faktycznie bardzo dobrą zasadą jest YAGNI (You Ain't Gonna Need It) - czyli pisz tylko to, czego faktycznie potrzebujesz i co faktycznie używasz. Przykładowo, jeśli potrzebujesz zmienić wszystkie litery w stringu na wielkie, to napisz tylko metodę, która zmienia wszystkie litery na wielkie. Nie idź w kierunku: "A to napiszę jeszcze przy okazji .ToLower(), bo pewnie się przyda"

40naKlate napisał(a):

Siemka, jakie macie sposoby na planowanie tego co ma sie znalezc w projekcie?

Dobrym pomysłem bedzie poswiecenie 30-60minut, aby wszystko rozpisac sobie np. na kartce i zacząc od tego jakie funkcje ma mieć, nastepnie podzielic to na klasy i na koncu na metody, ktore w tej klasie maja sie znalezc?

Raczej nie uda ci się w ten sposób dobrze zaprojektować większego projektu, który zahacza o tematy, których nie znasz dobrze.

Jednak od czegoś trzeba zacząć, więc owszem, dobrym pomysłem może być na początku poświęcenie 30-60 minut na rozpisanie na kartce, a następnie spędzenie kilku tygodni na zrobienie prototypu, a później wrócenie do punktu wyjścia i rozpoczęcie projektowania od nowa (ale z większą wiedzą na temat rzeczywistych wymagań i problemów). Czynność można powtarzać później ileś razy, mieszając bardziej koncepcyjne myślenie z bardziej praktycznym kodzeniem (no i kodząc też często można mieć jakiś fajny pomysł na refaktor czy wydzielenie jakichś modułów, funkcji, klas, więc na spontanie też można czasem coś zaprojektować niechcący, co okaże się dobrym pomysłem)

Więc wychodząc od "poswiecenie 30-60minut, aby wszystko rozpisac sobie np. na kartce", można rzeczywiście później osiągnąć fajny wynik, pod warunkiem podejścia iteracyjnego. Czyli nie łudzić się, że pierwszy projekt apki napisany na kolanie przez 60 minut będzie tym ostatecznym. (jakbyś spędził kilkadziesiąt godzin na samym planowaniu, też pewnie byś to słabo zaprojektował, bo jak zaczynasz pisać kod, to często bardzo szybko się okazuje, że o czymś nie pomyślałeś).

Czyli:

• iteracje
• dwustronny wpływ na siebie projektowania i implementacji (tj. jak projektujesz, to projekt wpływa na to, w jaki sposób będziesz to implementował, ale i odwrotnie - często w czasie implementacji może wyjść coś, co sprawi, że będziesz musiał zmienić projekt).