projektowanie - java

hej,

mam do Was prosbe o kilka rad. Chcialabym nauczyc sie dobrze projetowac. Tzn - przykladowo mamy do zrobienia aplikacje A. Wiadomo, na poczatku trzeba siasc, przemyslec, wybrac narzedzia, zaprojektowac. Ciagle brakuje mi dobrych skilli projektowych. Wiem, ze to jest przede wszystkim praktyka, doswiadczenie i kolejne projekty, no ale chcialabym sie polepszyc. Powiedzcie mi, znacie moze jakas dobra, godna polecenia lekture w tym temacie? Ewentualnie artykuly?
a moze moglibyscie napisac mi pare 'zlotych zasad' ktore zawsze trzeba przemyslec i omowic, bez wzgledu na to czego tyczylby sie projekt?

        pozdrawiam,
                misty

Swego czasu na sieci była fajna stronka poświęcona wzorcom projektowym w javie.
Nie wiem ,czy jeszcze istnieje, ale spróbuj poszperać w google java design patterns, czy coś.
Powinny być opisy, kiedy stosować jakie wzorce itp.

hej,
dzieki za odpowiedz ale nie chodzi o mi o wzorce projektowe. tylko o to, jak dobrze nauczyc sie projektowac, jak dobrze zaplanowac projekt. Rozklad klas, dziedziczenie itd. hmm.. inzynieria oprogramowania? chcialabym, po otrzymaniu hasla pt "zrob projekt A" umiec siasc, przemyslec wszystkie (albo prawie wszystkie) mozliwosci, zaprojektowac schemat klas, interfejsow. tzn umiem to zrobic oczywiscie. Ale uwazam ze ciagle mi od tej strony projektowej brakuje. zawsze po zaczeciu projektu wychodzi gdzies, ze cos mozna bylo wyjac na wyzszy poziom abstrakcji, etc. Nie wiem czy dobrze opisuje to, o co mi chodzi..

W moim doswiadczeniu nie da sie usiasc i zaprojektowac wszystkiego na poczatku, zawsze cos sie znajdzie co dziala inaczej. Mowie o relatywnei duzych projektach, ktore maja pare rzeczy / technologii ktorych nie znam / nie jestem specjalista. Dlatego masz agile.

agile, czyli ze po malym kawalku sie robi-testuje,a pozniej nastepny kawalek itd? u nas niestety nie ma takiego podejscia. dlatego szukam literatury/artykulow ktore nauczylyby mnie przewidziec juz na poczatku jak najwiecej mozliwych zagrozen i wymagan (jasne, wiem ze nie da sie wszystkich). jakis czas temu robilam pewien projekt wspolnie z kolega. tj wpierw ja robilam swoja czesc, po paru tygodniach (nie bylo czasu wczesniej) On przysiadl do swojej czesci (ktora miala wspolgrac z moja). Okazalo sie ze niestety, to co On musi zrobic wymagalo jednak troche innego podejscia z mojej strony. Tzn (to oczywiscie moja wina byla, przynamniej w wiekszosci) ja skupilam sie, by zrobic swoja czesc, by dzialalo poprawnie, wystawilam Mu klase w ktora On mial sie niby wpiac. Wydawalo mi sie, ze to wystarczy. Teraz jednak okazuje sie, ze to bylo duzo za malo, ze nie przewidzialam wielu rzeczy ktore powinnam byla, aby On sie mogl wpiac. tj. jesli ten projekt to bylaby tylko ta moja czesc-to mogloby to zostac bez problemu. ale jesli mialo to wspolgrac z Jego czescia, to powinno to byc jednak troche inaczej zaprojektowane. Oczywiscie, mozna troche zwalilic na brak komunikacji miedzy Nami (nie rozmawialismy w sumie o tym, poza tym ze ustalilismy ze wystawie Mu te klase), ale On zarzuca mi, ze to ja powinnam przewidziec to, co On bedzie potrzebowal i tak to zaprojektowac by pasowalo tez do Jego czesci. Raczej sie tutaj z Nim zgodze. Tego mi wlasnie czesto brakuje, takiej wyobrazni, przewidywania, dobrego zaprojektowania.. stad moje pytania do Was o literature i rady.

pozdrawiam

Misty - byłoby za prosto siąść przeczytać 2 książki i już umieć projektować. Niestety (stety) trzeba posiadać wiedzę na temat wszystkich warstw w danym projekcie plus spory zapas doświadczenia.

Co czytać by się rozwijać w tym temacie? Książki takie jak Object-oriented software guided by tests, Clean code, książki na temat np architektury jee, integracja systemów (np ESB), webserwisy. Projektant musi umieć spojrzeć 'z góry' jak i znać poszczególne technologie żeby nie wpaść na minę. Chyba dlatego trzeba przejść swoje by się takim projektantem stać

ja wiem ze po przeczytaniu 2-3 ksiazek nie bede super projektowac i przewidywac z gory wszystkiego :) Ja mam 2 lata doswiadczenia zawodowego w programowaniu. Nie jest to duzo moze, ale chyba jednak juz cos. Tak sobie mysle ze teraz juz powinnam wiedziec wiecej, powinnam lepiej przewidywac bo mam pare projektow za soba. Moze nie mega wielkich, ale jednak. Doswiadczenie i wiedze zdobywa sie latami, ale chcialabym to troche "wyprzedzic". Dzieki za tytuly, mam nadzieje ze bez problemu znajde na torrentach.

misty napisał(a)

(...)Oczywiscie, mozna troche zwalilic na brak komunikacji miedzy Nami (nie rozmawialismy w sumie o tym, poza tym ze ustalilismy ze wystawie Mu te klase), ale On zarzuca mi, ze to ja powinnam przewidziec to, co On bedzie potrzebowal i tak to zaprojektowac by pasowalo tez do Jego czesci. Raczej sie tutaj z Nim zgodze.(...)

troche offtop ale moim zdaniem w tym przykladzie oboje ponosicie wine, jak zakladasz ze piszesz projekt z kims to musicie jasno okreslic z gory interfejsy komunikacji miedzy waszymi czesciami, skad ty masz wiedziec czego on pozniej bedzie potrzebowal ? przy podejsciu 'kazdy robi swoje a pozniej jakos sie to polaczy' to pozniej np dwie czesci autostrady mijaja sie o 15km zamiast polaczyc :)

hmm,
wiesz co On za bardzo nie mial czasu by ze mna to omawiac (byl na prawde zawalony). No a pozniej stwierdzil ze jednak powinnam byla to przewidziec sama poniewaz wiedzialam na czym Jego wpiecie bedzie polegalo. Ja mysle ze ma racje, koles ma bardzo duze doswiadczenie wiec wie co mowi. Stad moj temat do Was o literature, trzeba sie edukowac :)

@eee, tyle tylko, że autostrady nie zepniesz szyną ESB. Nie napiszesz adaptera czy jakiejś protezy komunikacyjnej "na szybko". Programowanie wybacza nawet poważne błędy.

@misty, w Helionie mają kilka książek (polecam te: http://helion.pl/ksiazki/analiza-i-projektowanie-obiektowe-rusz-glowa-brett-d-mclaughlin-gary-pollice-david-west,anprob.htm , http://helion.pl/ksiazki/sztuka-pisania-oprogramowania-wybor-i-redakcja-joel-spolsky-joel-spolsky,artopr.htm ) , ale to będzie tylko wprowadzenie do słownictwa. Spolskiego jak trafisz to na Allegro.
Co do samej nauki to chyba jedyną rozsądną drogą jest praktyka. Przy czym warto zarówno projektować nowe rzeczy jak i analizować to co już masz zrobione. Szczególnie druga metoda jest niezła, bo jak czegoś używasz to widzisz braki. Jak widzisz braki to potrafisz określić rzeczywiste wymagania, a to pozwala na weryfikacje projektu i wskazanie błędów.
Przypisywane v. Bismarckowi "Należy uczyć się na błędach, ale na cudzych" ma i tu zastosowanie.

Jeżeli chcesz zaprojektować aplikację - nieważne o jakiej złożoności, to przede wszystkim powinnaś zawsze skupić się na tym co taka aplikacja powinna robić. Nie jak, ale co. I można to sformułować w języku naturalnym, co daje najwyższy poziom abstrakcji. Jeżeli tego Ci się nie uda, to koncepcja utworzenia takiej aplikacji jest błędna. Najczęściej daje się taką aplikację określić jednym zdaniem. Następnie zdanie to należy rozbić na kilka i uszczegółowić - na przykład podzielić na moduły funkcjonalne oraz określić co będzie przetwarzanymi danymi w komunikacji między nimi. Od tego momentu przydaje się kilka osób oraz karteczki, które będą reprezentowały krążące dane, dzięki czemu można przeprowadzić wstępną symulację działania takiego abstrakcyjnego projektu. Następnie te kroki należy powtórzyć dla każdego elementu funkcjonalnego jaki da się wydzielić i nazwać. Po kilku lub kilkudziesięciu iteracjach poziom abstrakcji jest już na tyle niski, że daje się to zapisać jako diagramy UML lub jakikolwiek inny formalny szablon. Od tego momentu masz już wstępną dokumentację projektową. Wystarczy ją tylko uporządkować i ujednolicić występujące jednocześnie w kilku miejscach pojęcia.
Z taką dokumentacją znowu przechodzisz przez każdy element projektu i próbujesz sformułować działanie tylko tego jednego elementu. Prawdopodobnie przy rozbudowanej aplikacji trzeba będzie dokonywać kolejnych rozbić na moduły funkcjonalne i komunikację między nimi.
Po jakimś czasie dokumentacja jest już tak szczegółowa i dopięta w każdym elemencie, że implementacja wydaje się już niemal formalnością.
Tak czy inaczej zanim zostanie napisana pierwsza linijka kodu ty już wtedy powinnaś umieć powiedzieć o swojej aplikacji prawie wszystko.

dzieki za wszystkie rady!

Olamagato napisał(a)

Tak czy inaczej zanim zostanie napisana pierwsza linijka kodu ty już wtedy powinnaś umieć powiedzieć o swojej aplikacji prawie wszystko.

Mowisz o wlasnych malych projektach, czy wielkich firmowych? Jesli tak pracujesz, to albo Ci sie wydaje ze jest jak mowisz (=masz bardzo malo doswiadczenia) albo zyjesz w pieknym swiecie ktorego ja niestety nie znam (i musze pomyslec gdzie popelnilem blad), albo nie byles w zadnym projekcie wystarczajaco dlugo aby sie przekonac ze jednak wiesz na starcie o aplikacji bardzo malo. Ja rozumiem ze mozna tak powiedziec o tetrisie, ale o czyms troszke wiekszym juz raczej nie.

Tak czy inaczej zanim zostanie napisana pierwsza linijka kodu ty już wtedy powinnaś umieć powiedzieć o swojej aplikacji prawie wszystko.
W ten sposób pracuje dział marketingu: nikt ci tyle nie da, co my możemy obiecać.

Olamagato napisał(a)

Tak czy inaczej zanim zostanie napisana pierwsza linijka kodu ty już wtedy powinnaś umieć powiedzieć o swojej aplikacji prawie wszystko.

Panie takie rzeczy tylko w Erze... nie po to wymyślono agile by później nic nie zmieniać. Pamiętaj, że jedyna stałą rzeczą w każdym projekcie są zmiany. No chyba, że projektujesz waterfallem....