🚀 go-pugleaf

On 2015-07-10 08:53, Borneq wrote:
> Chciałbym zapytać się osób mających doświadczenie w projektowaniu nowych
> aplikacji. Jak myślę, aplikację należy projektować od góry, najpierw
> podzielić funkcjonalnie na pakiety i klasy, potem wybrać metody tych
> klas a następnie będzie można wypełniać już kodem te metody?
> Tylko jak nie widząc jeszcze aplikacji ustalić te klasy?

Generalnie, jak masz już pomysł/potrzebę na aplikację, to najpierw 
dobrze jest ją opisać. Co ma robić, po co, jakie wejścia danych, jakie 
wyjścia. Najlepiej w zespole, jak jest, bo każdy widzi to nieco inaczej. 
Dopiero jak już mniej więcej wiadomo o co chodzi, to zaczyna się 
wyodrębnianie modułów/funkcjonalności, szukanie co jest podobne a co 
inne, co można zrobić gotowymi bibliotekami, a co jest zupełnie nowe.

Na tej podstawie można zrobić zgrubny schemat aplikacji, zadecydować o 
technologiach i bibliotekach jakie mają być użyte. Ile i jakie warstwy 
będą używane, i w jakich kierunkach. Kierunkach w sensie że jak masz 
jądro aplikacji, kod biznesowy, to jednym kierunkiem jest zachowanie 
danych (warstwy [w kierunku od środka] to np. serwis/klasa 
DAO/entity/persistence manager/baza danych), kolejnym jest UI (warstwy: 
kontroler/model widoku/widok), kolejnym możne być komunikacja sieciowa 
lub z urządzeniem, lub silnik wyszukiwania czy obliczania, etc. Ważne 
jest że warstwy z różnych kierunków nie rozmawiają ze sobą, a jedynie z 
warstwą pod/nad w tym samym kierunku, jedynie centralna logika biznesowa 
komunikuje się z górnymi warstwami każdego kierunku.

Stosunkowo często technologie/biblioteki wymuszą pewne rozwiązania, 
pewien określony szkielet aplikacji. Sam z siebie taki Spring robi w 
zasadzie za szkielet, dostarczając mnóstwa bloków do budowy aplikacji, 
tudzież wyznacza sposób tworzenia pozostałych bloków.

Teraz z funkcjonalności które nie są zapewniane z gotowców trzeba 
porobić bloki funkcjonalności, pamiętając że każdy blok działa tylko w 
jednej warstwie aplikacji. Trzeba opisać co on ma robić, i jeśli to 
istotne, to jak ma to robić. Trzeba także opisać jakie dane i jak będą 
wymieniane, jaką kontrolę mają jedne bloki nad innymi, i inne metody 
komunikacji.

I teraz dopiero można zacząć projektować klasy, jak to Piotr już opisał. 
W każdym bloku skupiaj się tylko na nim, i na blokach które będą z nim 
współdziałały, w sensie że API tego współdziałania jest wspólne. 
Generalnie dobrze jest zacząć od podstawowej funkcjonalności, o ile nie 
została już dostarczona bibliotekami.

Jak już masz klasy to można je powoli zacząć wypełniać kodem. Ale dobrze 
jest zacząć od unit testów, bo będziesz musiał pomyśleć o szczegółach 
działania klas, jak ich się używa, czy wygodnie, czy może jednak API 
jest uciążliwe i warto by je zmienić. Pomyślisz też o edge case'ach, 
limitach, możliwych błędach i ich obsłudze. Po czymś taki sam kod klas 
to często jest "pikuś" ;-).

Wielu programistów tego nie docenia, ale tak naprawdę samo klepanie kodu 
to nie więcej jak 1/5 czasu pracy nad aplikacją. Często mniej.

-- 
Arivald