Portfolio - REST API - prośba o ocenę

pytanie zadane 27 września 2019 w Nasze projekty przez WojtekW Nowicjusz (130 p.)

Hej! Chciałbym się Was spytać co myślicie o poniższym portfolio programistycznym. Czy taki ma sens chcąc aplikować na juniora? Czy przeglądając stronę Wam czegoś brakuje? Czy powinienem coś dodać do opisów projektów?

https://wojciechweg.github.io/

Z góry dziękuję za sugestię!

3 odpowiedzi

odpowiedź 27 września 2019 przez ShiroUmizake Nałogowiec (46,300 p.)

Spróbować stworzyć coś więcej niż jakiś CRUD z 3 powiązaniami. Takich to ja widzę na pęczki. Spróbuj stworzyć Np: Prosty webserwis komunikujący się z API + emaile albo Tworzenie csv na podstawie logów bazy etc. Ano i brak testów.

Podsumowując: Pokaż coś więcej. Jak na razie dla mnie to jest nic więcej jak skopiowanie tutoriala.

komentarz 27 września 2019 przez WojtekW Nowicjusz (130 p.)

Dzięki za odpowiedź. Możesz rozwinąć temat testów? Testy są ale skromne. Powiedz czy i czego może tam brakować. Nie wiem/ nie jestem świadomy co dalej mógłbym zrobić w testach.

odpowiedź 27 września 2019 przez Paweł Nąckiewicz Nałogowiec (48,990 p.)

Powiem Ci, że dawno nie widziałem tak dobrego portfolio. Jedyne co bym dodał na stronie, to krótki opis technologi wykorzystanych do projektu. Jeśli chodzi o kod źródłowy to w jednym projekcie nie masz podziału na foldery modele, controllery etc... i nie wiem czy to celowy zabieg, ale mi się to średnio podoba.

komentarz 27 września 2019 przez WojtekW Nowicjusz (130 p.)

Dzięki za odpowiedź. Tak myślałem że moje opisy nie są zbyt wylewne. Co do tego jednego projektu to celowo tak zrobiłem aby sprawdzić czy jak to się sprawdza. Niestety mi też tak średnio się to podoba i raczej nie będę tego powtarzał.

odpowiedź 27 września 2019 przez Aisekai Nałogowiec (42,190 p.)

Na szybko przejrzane. Według mnie do poprawy:

1. https://github.com/WojciechWeg/parking_meter_rest_api_redo/tree/master/src/main/java/com/wojtek/parkingmeter/helpers nazwa pakietu. helpers nic nie mówi.

2. Pakietowanie per warstwa. Bez sensu. Grupuj per funkcjonalność (albo domene) - w takim podejściu dużo łatwiej będzie przejść na architekturę mikroserwisową. Ostatnio projekt jaki widziałem był stworzony z mavenowych modułów: model, repository, core, services, services-impl. Imo - tworzenie Interfejsów na zapas jest trochę bez sensu.

3. Korzystasz z wyjątków żeby przesyłać Http error code. Ok - zdaję sobie sprawę, że w javie jest trochę utrudnione przesyłanie error codów ale jest to poniekąd uznawane za złą praktykę (alternatywą są obiekty take jak vavr'owy Either). Na razie powiedzmy może to zostać, chociaż tworzenie za każdym razem nowej klasy żeby przesłać error code, nie jest ok. Skorzystałbym raczej z ResourceException i jakiejś customowej klasy przechowującej Error code.

4. Brak DTO. Nie wypycha się encji na zewnątrz aplikacji. Dodawanie @JsonIgnoreProperty też nie jest zbyt dobrą alternatywą. Po pierwsze zaśmiecasz encję dodatkowymi adnotacjami. Po drugie ograniczasz się do tego, że jedną encję możesz wykorzystać tylko raz. Po trzecie istnieje ryzyko, że zapomnisz dodać @JsonIgnoreProperty nad jakimś wrażliwym polem.

5. Na githubie masz coś takiego jak branche. Ok, dobrze że lokalnie sobie je robisz i dobrze że dość często commitujesz, ale można też używać branchy na githubie.

6. W pom.xml możesz wszystkie wersje zależności wynieść do sekcji properties. Łatwiej potem o podmiankę wersji.

7. Nie spotkałem się jeszcze z tym, żeby ktoś nadawał klasom suffix Entity.

8. Zastanowiłbym się nad zrobieniem domeny typu Parking/Parkometr i do niej wrzuciłbym ticket i profit. Przy czym, ticket i profit nie miałyby własnego serwisu i controlera, tylko zgodnie z REST'ami dobijałbym się do nich przez Parking/Parkometr.