@V-2: fakt, nigdy nie robiłem jakiś większych researchów na temat wiadomości w commitach, najwyższa pora.
Jeśli chodzi o private w metodach testowych dodałem je jedynie dlatego żeby intellij nie krzyczał (albo SonarLint, nie pamiętam), ponieważ najzwyczajniej w świecie mnie to drażniło, tym bardziej, że nie wydaje mi się by zrobiło to jakąś różnicę. Jeśli chodzi o testy - tutaj też raczkuję dopiero - nie poświęciłem najwidoczniej odpowiednio dużej ilości czasu na teorie i przyznam szczerze, że nie raz się gubiłem co mam testować, weryfikować - dlatego tam takie babole. Jeśli chodzi o zacytowany kod:
Kopiuj
assertTrue(user.isNew());
user.setId(ID);
assertFalse(user.isNew());
jest dokładnie tym samym co:
Kopiuj
user.setId(ID);
assertFalse(user.isNew());
Uznałem, że gdyby ze względu na jakieś zmiany domyślnie nowy user nie byłby nowy dodatkowa asercja by na to wskazała. Rozumiem co masz na myśli i jak wcześniej wspomniałem - zbyt mało teorii (po prostu preferuję praktykę). A podesłane przez Ciebie materiały z pewnością obadam, dzięki! :)
@Shalom: jak już powyżej wspomniałem - zbyt mało teorii przed praktyką jeśli chodzi o testy. Jeśli chodzi o testy integracyjne - to wynika stąd, że gdy chciałem je napisać wygooglowałem, znalazłem pierwszy 'lepszy' gotowiec na którym się wzorowałem i oto rezultat :) Wspominając jeszcze na temat nazewnictwa - tutaj też się zwyczajnie gubiłem jak je poprawnie nazywać. Dzięki!
@danek:
2. Jeśli chodzi o strukturę projektu wzorowałem się po prostu na na znalezionych na githubie projektach, jak również z kursów udemy. Przyznam szczerze, że nie spotkałem się z taką strukturą projektu (bądź nie zauważyłem zwyczajnie), w każdym razie przy następnym projekcie eksperymentalnie obadam jak wyjdzie :)
3. Tutaj to samo co wyżej - wzorowałem się innymi, sam w tym specjalnego sensu nie widziałem. Chociaż w założeniu miałem nieokreślenie daleką rozbudowę projektu, więc może jeszcze w niedalekiej przyszłości się to opłaci
4. Tak, kilkakrotnie w serwisach rzucam wyjątkami przy pomocy optionali na prawo i lewo - po prostu wygodne, mało kodu. A nie cierpię sprawdzać warunkami czy obiekt jest nullem, czy też nie, stąd takie ich zastosowanie. Generalnie w całym projekcie starałem się nie dopuścić do sytuacji gdzie funkcja zwraca null żeby tego nie robić
7. Znam zasadę, tutaj jednak się pokusiłem na wyjątek (trochę z lenistwa)
8. W poprzednium projekcie używałem MapStruct'a, z którego w ogóle zadowolony nie byłem, bo generował więcej problemów niż rozwiązywał, a ostatecznie większość mapowań sam musiałem nadpisać. Z pewnościa obadam modelMappera. Chociaż nie ukrywam - oprócz faktu, że musiałem markupowe interfejsy zastosować jestem bardzo zadowolony ze swojego rozwiązania.
9. Nie wiem jak - ale o tym sposobie i nie słyszałem i nie pomyślałem, przyda się! Miałem wielokrotnie rozkminę jak nie stworzyć niechcący hybrydy, chociaż tak bardzo byłoby to wygodne. Tylko czy w połączeniu z podpunktem 4 nie doprowadzi to do 'eksplozji' klas?
I tak - pierwszy, który bym jako większy określił. Dzięki! :)
Swoją drogą - na podstawie tego projektu czy jest to już poziom (pomijając testy, na których się teraz skupię) na którym mogę się powoli przymierzać do szukania pracy na juniora? A jeśli nie co powinienem jeszcze od strony praktycznej w ramach nauki wykonać?
Spring 
Java 
ShalomPodziel klasy na pakiety wedlug tego co robią, a nie tego czym są (czyli nie na pakiety service, controller itp tylko np photo, user)-> Ja się nie zgadzam trochę, ja bym tu raczej pomyślał o modułach jeśli już ;)