Projektowanie aplikacji od zera

0

Dzień dobry, przeglądałem internet, so, se, ale jedynie znalazłem takie hasła jak OOD/OODA i design patterns. Czy są w internecie jakieś opracowania lub książki do kupienia, które wytłumaczą jak zabrać się do tworzenia aplikacji od zera? Lub może jakieś konkretne przykłady. Czytałem o kilku patternach, ale z tego co zrozumiałem to one raczej służą do konkretnych przypadków, a nie całej aplikacji webowej.

Więc skąd taki szarak jak ja ma wiedzieć jak zaprojektować aplikację, rozumiem, że tym zajmuje się architekt w zespole, ale chciałbym poznać chociaż podstawy by samemu coś napisać.

Proszę o pomoc.

2
Javaluke Scriptwalker napisał(a):

Dzień dobry, przeglądałem internet, so, se, ale jedynie znalazłem takie hasła jak OOD/OODA i design patterns. Czy są w internecie jakieś opracowania lub książki do kupienia, które wytłumaczą jak zabrać się do tworzenia aplikacji od zera? Lub może jakieś konkretne przykłady. Czytałem o kilku patternach, ale z tego co zrozumiałem to one raczej służą do konkretnych przypadków, a nie całej aplikacji webowej.

Więc skąd taki szarak jak ja ma wiedzieć jak zaprojektować aplikację, rozumiem, że tym zajmuje się architekt w zespole, ale chciałbym poznać chociaż podstawy by samemu coś napisać.

Proszę o pomoc.

Head First Object-Oriented Analysis and Design:
http://helion.pl/ksiazki/head-first-object-oriented-analysis-and-design-edycja-polska-rusz-glowa-brett-d-mclaughlin-gary-pollice-david-west,hfooad.htm#format/e

Head First Software Development. Edycja polska
http://helion.pl/ksiazki/head-first-software-development-edycja-polska-dan-pilone-russ-miles,hfsode.htm

Proszę.

0

Swoje aplikacje od 0... ale dokładnie od jakiego zera? Masz jakiś framework i opierasz o to aplikacje czy w ogóle bez frameworka i wszystko klepiesz od pierwszej najmniejszej linijki?

2

Musisz klepnąć kilka aplikacji, popełnić sporo błędów, a w końcu będziesz wiedział, co w danym wypadku będzie złe, a co dobre. Innej możliwości raczej nie ma. Teorię możesz sobie wyczytać, na pewno nie zaszkodzi (zwłaszcza jeśli chodzi o ogarnięcie UML), ale w praktyce jest tak, jak Ci napisałem. Innymi słowy: nie bierz się za projektowanie drapacza chmur, jeśli nigdy nie zrobiłeś chociażby małej chatki w lesie.

4

Ja polecam - nie zaczynaj od modelowania w UML dziedziny - bo to przeważnie czysty nonsens i sztuka bezużytkowa. To dobrze wygląda na studiach i później ewentualnie w celu poniżania klientów.
(Nie kojarzę kiedy ostatnio widziałem diagram UML, który być chociaż trochę odpowiadał prawdzie... ( chyba, że to z reverse engineeringu był :-) ) Najważniejsze jest ustalenie wymagań. (przy okazji UseCase w UML to IMO kolejny nonsens- możesz olać ( Gdyby chociaż ludziki miały buzie to- można by im dorysowywać wąsy)).

Bo o ile to WEB to absolutnie najważniejszy jest Look and feel - UX.!
Jakie są strony, pociski, jak reagują itp.?. - i tu najlepiej "Pixel Genau" im dokładniej -> tym lepiej. Mało kto to robi (dobrze/w ogóle) - (bo to trudne !)- ludziki i strzałki rysuje się dużo łatwiej.

Pomocą do tego może być prześledzenie procesów i np. event storming (zależy czy to mała czy duża aplikacja).
Jak to zrobisz to reszta jest prosta.

To tyle jeśli chodzi o aplikację- jeśli jesteś architektem to musisz teraz zając się takimi rzeczami jak:

  • testowalność systemu,
  • budowanie zespołu,
  • build,
  • CI,
  • technologie,
  • narzędzia,
  • wymagania niefunkcjonalne,
  • security.
  • konfiguracja,
  • documentacja,
    -hardware

I jeszcze w cholerę ... zależy od wielkości aplikacji, zespołu, budżetu itp.

Model obiektowy, dziedzina , sequence diagramy itp. ... przydają się w małej skali - zresztą książki raczej Cię tego nie nauczą (chyba, że jesteś wyjątkiem).

Jak nie wiesz co robić - to zrób prototyp. Najlepiej w moim życiu wyszły te projekty, które miały jakiś prototyp, POC itp. Często po kilkutygodniowym obrabianiu prototypu okazywało się, że klient to w zasadzie chce czegoś zupełnie innego - zupełnie innego niż opisane w 500 stronicowym zamówieniu z załącznikami. O wiele lepiej pracuje się przy czymś co widać, że sprawia radość użytkownikom i jest przez nich rozumiane niż wymyśloną przez analitykow kobyłę, której nawet programiści nie mogą ogarnąć. A dodatkowo z prototypu nawet biednego, w którym mnóstwo rzeczy jest pofejkowane czasem rodzą się dobre pomysły na architekturę.

I jeszcze - architektura to nie jest statyczna rzecz - zmienia się wraz ze zmianami w wymaganiach, zdobywaniem wiedzy i doświadczenia przez zespół. Czyli nie staraj się zaprojektować wszystkiego od początku do końca - bo i tak się nie uda. Raczej przygotuj się na stałe zmiany. Dlatego testowalność ,CI itp. są tak ważne.

A good architecture maximizes the number of decisions NOT made

Po tym wstepie przydługim rada praktyczna:
ściągnij jakiś przykład i analizuj jak działa.

1

A ja się nie zgadzam, jeśli chodzi o UML. W momencie, gdy zacząłem tworzyć aplikację od tworzenia zwykłego diagramu klas (innych jakoś nie ogarnąłem jeszcze), to stało się to dużo prostsze. Czasami od razu widać pewne problemy. Pewne części systemu można od razu w miarę dobrze zaprojektować. Jeśli chodzi o to, jak wygląda produkt końcowy, a jak diagram - zgoda - wyglądają trochę inaczej ;) Chyba, że w miarę robienia zmian w aplikacji, robisz zmiany w UML. Ale komu by się chciało. Grunt, żeby UML odzwierciedlał mniej więcej budowę systemu.

1

Umla tykam tylko w problematycznych miejscach np skomplikowane przejścia statusów w innych wypadkach nie widziałem nie widzę i nie będę widział potrzeby jego stosowania.

1 użytkowników online, w tym zalogowanych: 0, gości: 1