![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 859 Pomógł: 177 Dołączył: 29.10.2009 Ostrzeżenie: (0%) ![]() ![]() |
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 |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 23 Dołączył: 23.04.2013 Ostrzeżenie: (0%) ![]() ![]() |
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! ; ) |
|
|
![]() ![]() |
![]() |
Aktualny czas: 7.10.2025 - 08:38 |