Projekt aplikacji internetowej

pytanie zadane 5 września 2016 w PHP przez Stiuil06 Nowicjusz (160 p.)

Witam.

Zabieram się do stworzenia wydawało by się dość prostego serwisu (w ramach ćwiczeń), jednak mam problem od czego tak naprawdę zacząć :)
Do tej pory przy bardzo prostych zadaniach zaczynałem od kartki papieru rozpisujac tabele w bazie jakich będę potrzebował, później je tworzyłem i powoli zaczynałem tworzyć kod (mieszając html i php).
Jednak już przy nieco większym projekcie zaczynam się gubić :/ tabel wychodzi naprawdę dużo, co chwile okazuje się że w każdej będę potrzebował jeszcze innych pól i wszystko zaczyna tracić na czytelności.

Prosiłbym o rady takie jak:

-kroki jakie powinno sie wykonywać przy 'projekcie' aplikacji,

-może jakieś programy które pomagają projektować 'strukturę' / 'logikę' aplikacji

Z góry dziękuje za wszystkie odpowiedzi :)

2 odpowiedzi

odpowiedź 5 września 2016 przez event15 Szeryf (93,790 p.)

zaczynałem od kartki papieru rozpisujac tabele w bazie jakich będę potrzebował

W rzeczywistości baza danych to jedno z ostatnich miejsc o których się myśli w projekcie.

Programowanie obiektowe jest "o tym w jaki sposób ma coś działać" a nie "jak i gdzie przechowywać" parafrazując Bertranda Meyera.

W projekcie strony powinieneś się skupić na elementach, które zamierzasz opisać oraz na ich przepływie, sposobie ich przepływu nie na miejscu ich przechowywania.

odpowiedź 5 września 2016 przez Thomas Frost Bywalec (2,540 p.)

Cześć,

Podstawą dużego projektu są diagramy UML. Powinieneś się z nimi jak najszybciej zapoznać.

Ta strona pomoże ci w projektowaniu diagramów UML: https://www.draw.io/
- Zakładka UML po lewej.

Pozdrawiam,
Tomek

2	komentarz 6 września 2016 przez event15 Szeryf (93,790 p.) No, mógłbym polemizować. Dużo częściej stosuje się Event Storming, czyli karteczki :) No, ale to zalezy od firmy, metodologii i projektu

komentarz 30 listopada 2016 przez HaKIM Szeryf (87,590 p.)

Przytaczając fragment z książki Bob'a:

Niektórzy uważali, że nie zachowujemy się fair w stosunku do UML. W końcu nie wykonaliśmy kompletnego projektu przed przystąpieniem do projektowania. Zabawny, niewielki diagram UML na-
kreślony na odwrocie serwetki (rysunek 6.2) nie był kompletnym projektem. Nie uwzględniłem diagramów sekwencji. Ten argument wydał mi się dość dziwny. Nie wydało mi się prawdopodobne, aby dodanie diagramów sekwencji do rysunku 6.2 skłoniło nas do zrezygnowania z klas Throw i Frame. W rzeczywistości myślę, że to utwierdziłoby nas w przekonaniu, że klasy te były konieczne.

Czy próbuję powiedzieć, że diagramy są niewłaściwe? Oczywiście, że nie. A jednak jeśli dokładniej się zastanowimy, wydaje się, że w pewien sposób są one niewłaściwe. W przypadku tego programu dia-
gramy nie pomogły wcale. Właściwie tylko przeszkadzały. Gdybyśmy je wykorzystali, doprowadziłyby nas do programu, który byłby o wiele bardziej skomplikowany, niż to konieczne. Można by się spierać, że gdybyśmy skorzystali z diagramów, powstałby program, który byłby łatwiejszy w utrzymaniu, ale ja się z tym nie zgadzam. Program, który zaprezentowaliśmy, jest zrozumiały, a przez to łatwy w utrzymaniu. Nie ma w nim źle zarządzanych zależności, które sprawiłyby, że stał się sztywny lub kruchy.

A zatem tak, diagramy czasami mogą być niewłaściwe. Kiedy są niewłaściwe? Kiedy są tworzone bez kodu, który je waliduje, oraz bez zamiaru ich przestrzegania. Nie ma niczego złego w narysowaniu diagramu, który wyjaśnia koncepcję. Jednak po stworzeniu diagramu nie należy zakładać, że jest to najlepszy projekt dla zadania. Może się okazać, że najlepszy projekt będzie ewoluował w miarę wykonywania niewielkich, małych kroków, gdy piszemy program, najpierw tworząc testy.