Witam.

Mam w planach zrobić 3 strony internetowe. Wszystkie będą nieco rozbudowane ale znacznie się różnić od siebie.
Moje pytanie brzmi jak zaplanować tworzenie aplikacji.

Na dzień dzisiejszy zrobiłbym tak:

1) Tworze ogólną dokumentację dotyczącą funkcjonalności i działania (ogólny zarays)
2) Tworze wstępny projekt wizualny (bloki)
3) Tworze struktury w bazie
4) Zaczynam działać według specyfikacji - czyli tworze funkcjonalności aż do zamknięcia
5) Testuje, zlecam zew. osobom do testowania
6) Poprawiam
7) Udostępniam w sieci

Tak ja to widzę - a Wy w jaki sposób działacie?

Pozdrawiam

Sorry, ale muszę to tak skomentować. Ostatnio na forum pojawiają się takie błache wątki. Co to ma być za temat? Jak można pisać aplikację, nie potrafiąc zaplanować sobie pracy.

Ponieważ chcę się dowiedzieć jak planują aplikacje bardzie doświadczeni programiści Jest to dość kluczowy i podstawowy element, a być może czegoś się dowiem co ułatwi mi życie?

------- polecam nie czytać wątków które Cię nie obchodzą Taka rada na przyszłość

Pozdrawiam

Chyba od tego jest forum, żeby rozmawiać na różne tematy. Po co w ogóle się udzielasz, skoro jesteś taki cudowny?
Planowanie pracy, to dosyć ścisły temat, który z całą pewnością jest bardzo istotny

Patrzę że w weekend się wszystkim udziela Polecam maść na ból Du... od Goździkowej

Co do tematu żeby nie było że tylko spamuję.

Ja zaczynam od ogólnego zarysu aplikacji.
Potem projekt BD
Potem pisanie, refaktoryzacja, pisanie, ..., testy (tak to wszystko w tym samym etapie)
Potem testy ogólne i poprawki

Koniec

Z góry należy zaplanować całą bazę danych czy na początku podstawowe tabele kolumny, a później dostawiać kolejne kolumny?

Im więcej zaprojektujesz w BD tym mniej roboty potem masz.

Oczywiście w trakcie programowania samej aplikacji możesz nanosić poprawki.
Najlepiej jak się projektuje w jakims programie np. MySQL Workbench (diagramy) wtedy widzisz jak aplikacja ma działać.
Podczas kodowanie nie zastanawiasz się potem co gdzie, tylko zerkasz w diagram i już wiesz co masz i co musisz mieć.

Ty to tak na serio? .
---
Ja jak robie to pierw właśnie bazę danych,
Staram się z góry przewidzieć co wprowadzę na 100% w mniej niż miesiąc.
Potem to robie > i gdy mam nowe pomysły to dopiero kolejne kolumny jeśli są wymagane.
--
Ps. Też staram się ograniczać bazę,
Jeśli napewno nie będę danej kolumny wyszukiwał (np. `opis`/`description`) to staram się ją w pliki - taki szczegół

etap 1 (najtrudniejszy) dowiedzieć się do czego ma być aplikacja, jakie mam mieć funkcje i inne wytyczne (ważne by się dowiedzieć o kolory i inne szczegóły od których zależy życie lub co najmniej egzystencja!)

etap 2 (łatwiejszy) jakieś tam projektowanie, pisanie kodu, testy i inne nic nie znaczące pierdoły

pozdrawiam

są dwa główne nurty tworzenie zarządzane planem i zwinne, to zależy gdzie się wpisujesz, jak do planu to z góry zakładasz i przewidujesz co ma jak działać i wyglądać, przy metodykach zwinnych np SCRUM planujesz na bierzaco, zainteresuj się tym tematem to szybko sam znajdziesz odp

niestety w przypadku większości klientów i kończy się na programowaniu ekstremalnym

popełniając harakiri

Znam którzy są bardziej niezdecydowani od mojego 3 letniego syna, i z takimi to faza projektowania odpada.

Po pierwsze to zaczyna się od projektowania aplikacji (UML, klasy), dopiero później bierze się za bazę danych - na samym końcu. I o tym mawiają na większości kursów o projektowaniu aplikacji. ; )

Gdy się zaczyna od bazy, wtedy ona rzutuje się na kod, co jest OGRANICZAJĄCE. Liczy się biznes (logika), a nie kontener na dane.

Co do projektowania aplikacji - polecam przestrzeganie standardowych zasad Object Oriented Design And Analysis, pomieszane z Agilem.

Zasada nr 1 - jedyna stała to ZMIANY!
Jeśli wydaje się Tobie, że dobrym pomysłem jest przesiedzenie 2 tygodni, aby przygotować piękną, błyszczącą, wspaniałą dokumentację, a później pisanie programu według niej, wtedy jesteś oczywiście w błędzie! Takie coś było kiedyś i się nie sprawdziło. Stwórz ogólny zarys projektu, podziel go na niezależne moduły, następnie zabieraj się za każdy moduł pojedynczo:
- Stwórz Backlog, czyli opisz funkcjonalność (user stories, hostoryjki typu "Jako *rodzaj uzytkownika* mogę zrobić *funkcjonalnośc*, co pozwoli na *cel funkcjonalności*)
- Każde UserStory rozbij na zadania, jakie będziesz musiał wykonać, aby je zaimplementować - tutaj możecie sobie dodać swoje ukochane "projektowanie bazy dla funkcjonalności". jednak baza danych i tak powinna być dorobiona na samym końcu, najpierw trzeba przemyśleć logikę działania itp.
- Po wylistowaniu zadań, które będą konieczne do zakończenia UserStory (np. stwórz bazę, stwórz frontend, stwórz serwis do celu XYZ), wyznaczasz sobie tak zwany Sprint, tj. ustalasz termin (1-2 tygodnie) oraz liczbę zdań, które chcesz w tym terminie wykonać.
- Po wyznaczeniu zakresu sprintu po prostu pracujesz...

Gdy skończysz daną funkcjonalność, wtedy przechodzisz do następnej i znów zaczyna się proces tworzenia listy funkcjonalności (UserStories), planowania Sprintów i pracy.

I tak tydzień po tygodniu kończymy aplikacje, projektując każdy moduł z osobna na potrzeby. Jest to Metodyka używana w większości firm zajmujących się oprogramowaniem, jest uważana jako sprawdzony sposób prowadzenia projektów.

Tak, to jest standardowy Agile, ale wielu tutaj z pewnością o tym nie słyszało. Polecam i korzystam.

Nie zaczynajcie od projektu bazy danych i tworzenia mega specyfikacji - to was będzie tylko ograniczać. Oczywiście warto jest zastanowić się nad działaniem całej aplikacji, zidentyfikować części apki, które moga na siebie wpływać, ale części niezależne od siebie można na spokojnie rozwijać osobno.

I nie zapomnijcie, aby nie zaczynać od bazy...

Nie zaczynajcie od bazy...

NIE!

Łapy precz od bazy! ; )

Bardzo zła rada. Ta rada oprócz sugerowania, żeby nie tworzyć projektu bazy danych i specyfikacji, sugeruje, że wspomniane rzeczy są wersjami ostatecznymi, których nie można/nie powinno się zmieniać.

Oczywiście jest to bzdurą - solidna dokumentacja (zwięzła i zarazem dokładna, bez lania wody jak to jest w projektach unijnych) oraz ogólny zarys bazy danych bardzo się przydają w początkowym zrozumieniu działania całego projektu przez członków zespołu. Jednak trzymanie się sztywno dokumentacji lub projektu bazy danych jest głupotą i ma się nijak do Agile. Nie odpowiada Ci tabela? Potrzebujesz 3 dodatkowych tabel? Widzisz zbędne pola? Typ zmiennych jest nie taki jak być powinien? Zmieniasz. Ewentualnie konsultujesz się z kimś i zmieniasz zgodnie z wspólnymi ustaleniami.


To jest właśnie dokumentacja.