HazeBankCredit System. Czyli witaj JavaZawansowana.

pytanie zadane 28 marca 2017 w Nasze projekty przez ShiroUmizake Nałogowiec (46,300 p.)

Na początek link do repo:

https://github.com/PatrykMaternicki/dev_HazeBankCreditSystem

By uruchomić projekt potrzebujesz: Maven. Port 8080.

Reszta sama się zbuduje ;).

Środowisko uruchamiające:

A teraz o samym projekcie.

Projekt polegał na zbudowaniu logiki po stronie servera , ja do tego dołożyłem klienta. Zadaniem tego małego projekciku było pobieranie raportu pdf oraz wyświetlanie się raportu w postaci tabeli HTML. Oczywiście wszystko napisane w JAVIE, którą szczerze powiedziawszy lepiej się pracowało niż w php. Sama budowa tabeli HTML nie była trudna. Ale pdfy to już inna historia (no troszkę trzyba było posiedzieć w dokumentacji). Choć, muszę trochę ponarzekać na samo budowanie obiektu Response. Brakowało mi w nim trochę opcji (dodawanie arkuszy, skryptow itd), owszem mamy setContentType, ale on tylko działa z meta. Tak czy siak języka nie udało mi się ustawić.

To teraz może o działaniu:

Dane pierw przelatują przez klienta tu następuje wstępna validacja. Gdy się wszystko uda prawidłowo, serwer bierze się do roboty. Dane są ponownie validowane. Następnie konwertowane na właściwy typ danych. Następnie kalkulator rozpoczyna swoją pracę. Oblicza i wpakuje dane w model RaportOfCredit. I tu następuje wyświetlanie się tabeli, bądż budowa raportu PDF. Proste co nie?

Co w przyszłości planuje dodać.

Jak czas pozwoli to możliwość dodawania klientów do bazy danych (sterownik HSQL) czyli UOW + Repository, budowa różnych widoków zależności od użytkownika (Controler + filter). Również, są to wytyczne do naszego kolejnego zadania.

Jest również parę testów, ale one ... hm twierdzą coś innego niż wynika z kodu (może dlatego, że jest mockowany serviceMenager?).

Ah na pytanie czemu ikonki są krzywo położone, cóż grafikiem nie jestem, a za pomocą mojego profesjonalnego programu czytaj: paintNet, za bardzo nie wiedziałem jak pościnać przestrzenie nie używane...

Pomysłu na wygląd za bardzo również nie miałem.

.

1 odpowiedź

odpowiedź 28 marca 2017 przez event15 Szeryf (93,790 p.)

Jest również parę testów, ale one ... hm twierdzą coś innego niż wynika z kodu (może dlatego, że jest mockowany serviceMenager?).

Niesamowite stwierdzenie rozwiniesz je? Bo na moje, jeśli z testów wynika coś innego niż z kodu oznacza to dwie rzeczy. Albo testy mają dług technologiczny, albo kod jeś źle napisany i nie da się go stestować.

komentarz 28 marca 2017 przez event15 Szeryf (93,790 p.)

Swoją drogą kod jest dość brzydki

komentarz 28 marca 2017 przez ShiroUmizake Nałogowiec (46,300 p.)

Rozwń stwierdzenie dług technologiczny?

Api, przechodzi przez serviceMenager i z tego wynika że test jest ok. Ale jak patrząc na to jak na zwrot ValidateService to testy nie mają sensu.

komentarz 28 marca 2017 przez ShiroUmizake Nałogowiec (46,300 p.)

Która częśc?

komentarz 28 marca 2017 przez event15 Szeryf (93,790 p.)

Test musi sprawdzać działający kod. Mocki, stuby i fakeobiekty mają na celu udać zachowanie. Mock może wpłynąć na stan testu a stub zawsze daje ten sam response.

Test sprawdza wejście i weryfikuje to co fejkowany obiekt powinien zwrócić. Jeśli response w teście różni się od response w kodzie źródłowym oznacza to tylko tyle, że test jest źle napisany lub jest daleko w tyle za aktualnym kodem.

Testy są po to by jasno w jednym miejscu pokazać że kluczowe funkcjonalności aplikacji działają lub by wykazać że coś nagle przestało działać i wskazać miejsce tego błędu.

Kod jest brzydki.

https://github.com/PatrykMaternicki/dev_HazeBankCreditSystem/blob/master/src/main/java/com/Services/CalculatorService.java

Zakomentowany kod, dziwna konwencja nazewnictwa metody "credit.getCONSTANT_FEE()" niezastosowanie strategii dla dwóch dość dużych odpowiedzialności klasy, do tego metody które robią dużo więcej niż 1-2 czynności.

Mnóstwo białych przestrzeni.

https://github.com/PatrykMaternicki/dev_HazeBankCreditSystem/blob/master/src/main/java/com/domainModels/Credit.java

Bez sensu model - raz że nikt tego nie nazwie modelem domeny bo nie ma w sobie żadnej logiki biznesowej a dwa, po co tworzysz prywatne pola skoro do każdego masz akcesory i mutatory publiczne. Cały obiekt jest bez sensu i bez znaczenia jeśli chodzi o dziedzinę zagadnienia. Tak samo się to tyczy wszystkich innych "modeli".

https://github.com/PatrykMaternicki/dev_HazeBankCreditSystem/blob/master/src/main/java/com/Servlets/SummaryServlet.java

Brak jakichkolwiek builderów czy fabryk które bydowały by ważne dane. Do tego wmieszałeś tu kod HTML.

Projekt jest spoko, fajny. Jako wykonywalny się sprawdza jednak u mnie w firmie odpadłby już na automatycznym codereview a co dopiero na ręcznym. Nie mówię tego w złej wierze, bo nie o to chodzi, tylko samo to, że automat by tego nie puścił dalej.

komentarz 28 marca 2017 przez ShiroUmizake Nałogowiec (46,300 p.)

Zakomentowany kod, dziwna konwencja nazewnictwa metody "credit.getCONSTANT_FEE()" niezastosowanie strategii dla dwóch dość dużych odpowiedzialności klasy, do tego metody które robią dużo więcej niż 1-2 czynności.

Zastanawiałem się nad strategią, ale jakoś mi nie pasowała w sumie mamy 2 typy (html.pdf). Tak constant_fee() jest błędem z dużej. Miała być final (na wstępnym projekcie), ale wyszło że jednak nie jest final. Zapomniałem to przedytować.

Jeżeli liczymy kalkulator robi za dużo, to trochę według mnie przegięcie. Fakt, pdfBuildera mogłem trochę inaczej zbudować , ale to już była walka z czasem.

Mnóstwo białych przestrzeni.

Chodziło Ci o wygenerowane komentarze?

prywatne pola skoro do każdego masz akcesory i mutatory publiczne.

Dobra praktyka w JAVA.

http://javarevisited.blogspot.com/2012/03/private-in-java-why-should-you-always.html

Cały obiekt jest bez sensu i bez znaczenia jeśli chodzi o dziedzinę zagadnienia. Tak samo się to tyczy wszystkich innych "modeli".

Fakt, po głębszym się zapoznaniem to nie jest model, zgadza się.

Brak jakichkolwiek builderów czy fabryk które bydowały by ważne dane. Do tego wmieszałeś tu kod HTML.

Fakt, można było tu użyć jakoś fabrykę kompozytów. HTML wmieszałem świadomie, nie wiedziałem jak zrobić rozdzielnie logiki od widoku. (Nie dawno to mieliśmy).

Test sprawdza wejście i weryfikuje to co fejkowany obiekt powinien zwrócić. Jeśli response w teście różni się od response w kodzie źródłowym oznacza to tylko tyle, że test jest źle napisany lub jest daleko w tyle za aktualnym kodem.

Czyli najlepiej robić z poziomu Servelet?

Nie mówię tego w złej wierze, bo nie o to chodzi, tylko samo to, że automat by tego nie puścił dalej.

Ale ja się nie obraziłem. To jest właściwie mój tak naprawdę poważny projekt, gdzie uzyłem całej swojej wiedzy FrontEnd jak i pierwszy raz BackEnd w JAVA (wordpressa nie lliczę). Cieszę, że ktoś z większym od mnie doświadczeniem dał mi feedback. Mam nadzieję, że wersję 2.0 również ocenisz ;).

Napewno wezmę to pod uwagę co powieddziałeś i poprawie te błędy i niedociągnięcia. Ale jak narazie czas wrócić znowu do klepania wordpressa :).

komentarz 28 marca 2017 przez event15 Szeryf (93,790 p.)

Nie może być coś dobrą praktyką co jest po prostu złe.

Myślę że nie zrozumieliśmy się. Chodzi o to, że tworzysz prywatne pola, do których tworzysz PUBLICZNE setery/getery. To od razu lepiej robić publiczne pola i będzie dokładnie taki sam efekt. To jest właśnie to, dlaczego źle napisane DTO jest mocno hejtowane.

Rozumiem, że myślisz, iż zrobisz prywatne pola to już jest enkapsulacja zachowana. Jednak w Twoim kodzie tak nie jest. Po prostu to, co miało być prywatne tylko dla tej klasy jest dostępne dla każdej innej klasy. W rzeczywistości każdy programista który zacznie robić kod do tej aplikacji w każdej chwili może zmienić dane wewnątrz niej. Tak sie nie robi.

Odnośnie białych przestrzeni to chodziło dosłownie o białe przestrzenie :) Nierównomiernie formatujesz kod - część metod bardziej wcięta niż inna część. Wiele "enterów" pomiędzy metodami. Sprawia to wrażenie bałaganu.

komentarz 28 marca 2017 przez efiku Szeryf (75,160 p.)

Używasz InteliJ? :)

komentarz 28 marca 2017 przez ShiroUmizake Nałogowiec (46,300 p.)

Myślę że nie zrozumieliśmy się. Chodzi o to, że tworzysz prywatne pola, do których tworzysz PUBLICZNE setery/getery. To od razu lepiej robić publiczne pola i będzie dokładnie taki sam efekt. To jest właśnie to, dlaczego źle napisane DTO jest mocno hejtowane.

Czy to nie jest tak, że nie powinno się mieć dostęp do pól, a jedynie metody powinny dać dostęp?

Rozumiem, że myślisz, iż zrobisz prywatne pola to już jest enkapsulacja zachowana. Jednak w Twoim kodzie tak nie jest. Po prostu to, co miało być prywatne tylko dla tej klasy jest dostępne dla każdej innej klasy. W rzeczywistości każdy programista który zacznie robić kod do tej aplikacji w każdej chwili może zmienić dane wewnątrz niej. Tak sie nie robi.

Można by to ograniczyć za pomocą interfejsów.

Odnośnie białych przestrzeni to chodziło dosłownie o białe przestrzenie :) Nierównomiernie formatujesz kod - część metod bardziej wcięta niż inna część. Wiele "enterów" pomiędzy metodami. Sprawia to wrażenie bałaganu

Tak... Cięcia to jest problem. Program jakoś durnie czasami je formatuje.

Używam netbeans