Pierwszy poważny projekt - jak zacząć?

Cześć,

Po poznaniu podstaw języka C# i biorąc pod uwagę rady wszystkich żeby jak najwięcej pisać, chciałem napisać swój pierwszy "poważny" projekt, który też być może stanie się wizytówką w CV. Mam natomiast trochę problem jak się do tego wszystkiego zabrać, jest mnóstwo materiałów, które opisują podstawy składni, bardziej zaawansowane tematy. Nie mogę niestety znaleźć ani nie wiem jak się zabrać za rozpoczęcie pisania takiego projektu, do rzeczy:

1. Czy na początku powinienem rozpisać klasy, metody i wszystko co powinny zawierać - tylko w sumie nie jest przekonany co powinny zawierać żeby to miało ręce i nogi.
2. Czy potrzebna jest mi do tego baza danych? Jak ją praktycznie połączyć z tym co chce zrobić?
3. Jak to wszystko podpiąć pod GUI?

Pomysł na aplikacje to: aplikacja do zarządzania parkingiem strzeżonym

To by było na tyle, jakoś jak próbuje coś napisać to brak wiedzy jak się za to zabrać mnie przytłacza i kończy się na jakiś prostych appkach konsolowych. Z góry dziękuję za wyrozumiałość i pomoc.

Pozdrawiam.

zawsze zaczynam od rzeczy której potrzebuje na początek a na początek najczęściej potrzebuje chociaż część interfejsu, więc wyklikuje odpowiednie buttony menu itp potem podstawowe akcje typu zamknięcie aplikacji po wybraniu zamknij z menu i tak rozszerzam idąc powoli od tego co wiem aż w końcu wiem też to czego nie wiedziałem zaczynając. Tak przynajmniej robię apki desktopowe na C# + winforms

Dzięki wielkie za odpowiedź! Dużo to dało i już coś zaczyna się dziać, powstaje interfejs i zaczynam to wszystko spinać. Jeżeli jesteś wstanie coś jeszcze dodać w temacie, nawet najmniejsze szczegóły, mogą być istotne.

Będę również wdzięczny za odpowiedzi innych osób.

P.S. Szybkie pytanie nr 1, po prawej stronie interfejsu chciałbym żeby było okno w którym będą się wyświetlać biężace informacje tzn. jak klikne na button odpowiadający za miejsce parkingowego to wyświetli tam informacje o pojeździe, kliencie, daty itp., jakiego view'a do tego najlepiej użyć?

Szybkie pytanie nr 2, po kliknięciu dodaj rezrwacje lepiej będzie jak wyskoczy okno, w którym wpiszemy wszystkie dane i tym samym dodamy klienta czy może wykorzystać do tego miejsce po prawo, które opisuje w pytaniu nr 1?

Pozdrawiam.

Interfejs to pierdoła. W przeszłości zawsze zaczynałem od interfejsu. Któregoś dnia postanowiłem zacząć z drugiej strony. I to mi się spodobało dużo bardziej. Interfejs może Ci podpowiedzieć, czego faktycznie potrzebujesz, ale równie dobrze możesz go sobie narysować na kartce.

Ja to robię tak, że siadam z jakimś zamysłem aplikacji. Myślę, jakie klasy powinna zawierać. Projektuję taką klasę na kartce (lub w jakimś prostym programie do UML) - wpisując do niej PUBLICZNE metody, o których wiem, że raczej na pewno będę potrzebował. Dzięki temu mogę już się dowiedzieć, czy klasa nie robi czasem za dużo. Potem robię kolejną klasę - powiązaną z tą w jakiś sposób. Itd itd. W końcu mam jakiś diagram klas, który mniej - więcej spełnia swoje zadania. Na tym etapie też wyjdzie Ci kilka problemów, więc od razu przemyślisz kilka rozwiązań i pozmieniasz trochę strukturę.

Jestem bardzo niecierpliwy i zawsze od razu chciałbym usiąść i pisać kod. Ale walczę z tym na rzecz diagramu klas, bo przekonałem się, że to bardzo dużo daje.

Więc jak już jest w miarę gotowy diagram klas... gdy dojdziesz do wniosku, że ten diagram powinien się sprawdzić, to zaczynasz pisać. W trakcie pisania okazuje się, że jednak coś jest nie tak (za mało metod, za dużo metod, za mało klas, za dużo klas, złe powiązania...). Więc robisz pewne zmiany. Na tym etapie dobrze jest uwzględnić te zmiany w diagramie klas. I tak to sobie piszesz.

W między czasie możesz pisać testy. Albo w ogóle zacząć od pisania testów jednostkowych. Chociaż w moim przypadku TDD (Test Driven Development) nie zawsze się sprawdza, ale czasami podpowiada, czego tak naprawdę oczekujesz od danej klasy.

Co do parkingu - tak, potrzebujesz bazy danych. Musisz gdzieś w końcu trzymać informacje o samochodach, które wjechały, nie? Może też o tych, które wyjechały. Może będziesz robił jakieś raporty / statystyki - jak często klienci wracają.

Taka aplikacja jest stosunkowo prosta do napisania i nie powinna zająć dużo czasu. W tym przypadku może faktycznie diagram klas jest lekkim przegięciem, ale możesz to zrobić w ramach ćwiczeń.

Od ogółu do szczegółu:

1. Temat projektu (to już masz).
2. Ogólny zarys jak to ma wyglądać (tak, jak pisał @Juhas )(sam będę robić appkę; będzie to appka webowa, nakreśliłem przejścia między stronami - a'la flow diagram żeby odkryć ogólną strukturę programu, potrzebne klasy itp.).
3. Pkt. 2 da Ci ogólne pojęcie o rzeczach, które będziesz musiał zaimplementować - jakiś trochę bardziej szczegółowy schemat.
4. Kodzenie i refaktoryzacja.

IMO zaczynanie od kodzenia to zły pomysł, bo nie wiesz do końca czego tak naprawdę potrzebujesz.
Baza danych się przyda, GUI się przyda - wygoogluj sobie jak powinno się te rzeczy podpiąć w Twojej technologii.
Tak ogólnie, zacząłbym od jakiejś najważniejszej rzeczy, i potem dobudowywać do niej kolejne moduły - szybko
będzie widać efekty. :)

Moje podejście; byłbym wdzięczny, jakby ktoś wytknął błędy. :D

Myślę że jak chcesz zacząć pisać projekt powinieneś zacząć od dokumentacji. Jakiś skromny UML , opis rzeczywistości analiza przypadków użycia, diagram sekwencji. To powinno rozjaśnić całą sytuacje i podzielić projekt na mniejsze części. Mając jasno sprecyzowany cel unikniesz sytuacji i pytania siebie samego co by tu jeszcze... Wykres Gantta możesz sobie odpuścić :D

1. Czy na początku powinienem rozpisać klasy, metody i wszystko co powinny zawierać - tylko w sumie nie jest przekonany co powinny zawierać żeby to miało ręce i nogi.

Możesz, jak ci to pomoże, tylko miej świadomość tego, że projektując na sucho zwykle nie przewidzisz masy rzeczy. Olbrzymia część problemów dopiero wynika w trakcie działania programu. I potem albo musisz refaktorować (przerabiać) kod, albo czasem musisz go wręcz przepisać na nowo, bo okazało się, że źle zaprojektowałeś te swoje klasy.

Dlatego moim zdaniem nie warto się przywiązywać do konkretnych szczegółowych rozwiązań (np. do tego, że np. robisz takie a nie inne klasy z takimi metodami, które będą to i to robić), bo w praktyce i tak często będziesz musiał to całkowicie zmienić jeśli się okaże, że czegoś nie przewidzisz (wydaje mi się, że umiejętność przewidywania zawczasu problemów to bardzo ważna/najważniejsza umiejętność przy projektowaniu aplikacji - tyle, że do tego trzeba mieć praktyczne doświadczenie).

Dlatego ja bym się skupiał właśnie na ćwiczeniu się w rozwiązywaniu problemów. Projektowanie projektowaniem, ale żeby dobrze zaprojektować to trzeba spędzić długie godziny przed komputerem pisząc kod i patrząc jakie praktyczne problemy wynikają z danych rozwiązań. Musisz wiedzieć jak coś zaprojektować, a nie nauczysz się tego na sucho, w teorii.

Oczywiście myślenie też jest ważne. Dla mnie to jest coś jak takie cykle Planowanie -- Kodowanie -- Wyciąganie Wniosków -- Planowanie -- Kodowanie -- Wyciąganie Wniosków etc.

2. Czy potrzebna jest mi do tego baza danych?

To zależy. To pytanie nie ma sensu, bo nie napisałeś co chcesz zrobić (chyba, że czegoś nie doczytałem).

Jak ją praktycznie połączyć z tym co chce zrobić?

Jak to wszystko podpiąć pod GUI?

Możesz na początek poczytać o wzorcu MVC(model-view-controller). Pokazuje on jak można połączyć model danych z GUI i z logiką