Prośba o sprawdzenie ułamka kodu

Cześć,

Gdyby komuś się nudziło i miał trochę czasu miałbym prośbę o sprawdzenie dotyczczasowego kodu niedokończonych paru projektów.
Dziękuję za cenne dla mnie uwagi (które postaram się wprowadzić w życie w najbliższym czasie), poświęcony czas i stracone nerwy

git: https://github.com/au7h

Pozdr0

https://github.com/au7h/WorkersManagmentTool

1. pliki idei wrzucone na GH, powinny być w gitignore
2. dzie są testy
   3.buttonsTopController konwencja mówi, że nazwa klasy powinna się zacząć także wielką litera
3. masz zakomentowany kod, usuń go, po to jest kontrola wersji żeby móc się cofnąć do danego punktu w czasie i zobaczyć jak co wyglądało
4. czemu masz statyczne metody w abstrakcyjnej klasie?
5. w utils masz rzeczy dot javyFx, a także baz danych. Da radę ładniej ogarnąć klasy w pakietach
6. albo ten kod nic nie robi albo trzymasz logikę w kontrolerach, bo nie widziałem żadnej klasy, która mogłaby sugerowac, że gdzieś trzymasz logikę, oddzieloną od jakiejkolwiek infrastruktury, dzięki czemu kod mógłby obsługiwać cokolwiek poza javafx bez modyfikacji istniejących klas

podsumowując, polecam przeczytać TDD (to nie znaczy, ze musisz pisać w TDD, ale cokolwiek od testowania by się przydało), clean code, clean coder, clean architecture

Bardzo dziękuję za uwagi

1 poprawię
2.testów póki co nie planowałem robić, bo projekt jeszcze nie jest dokończony, może powinienem po każdej dodanej funkcjonalności dawać test jednak najpierw postanowiłem dokończyć
3.poprawię
4.chciałem zapobiec tworzeniu obiektów tej klasy, ale pewnie tak się nie robi - poprawię
5.tak, w sumie klasa updateModeLInDb powinna być w dbUtils a nie utils
6.logika nie jest skomplikowana sprowadza się do połączenia z bazą, dodawania rekordów, wykonywania select i trzymana jest w kontrolerach,czyli tam powinienem umieszczać tylko kod operujący na wyglądzie? (np jak mam metodę dodawania pracownika do bazy w WorkerAddController to wrzucić to do jakiejś klasy i dać metodę statyczną?)

2. dodawanie testu po dodaniu funkcjonalności wymusi to, aby kod był testowany. Jeżeli za bardzo się zwiążesz z infrastrukturą lub popełnisz bląd projektowy i będziesz musiał zamockować cały świat by przetestować dany feature to dowiesz się o tym prędzej niż później i łatwiej będzie to naprawić
3. da radę inaczej, np tworząc prywatny konstruktor rzucający wyjątek albo pozostawienie domyślnego, klasa abstrakcyjna powinna być rozszerzana, a w twoim przypadku nie ma to sensu
4. operowanie na widoku jest OK w kontrolerze jfx, ale dodawanie pracownika możesz dodać do innego obiektu 'serwisu' oddzielając tym samym to od operowania na widoku, przez to łatwiej będzie przetestować jednostkowo kod, a w razie gdybyś chciał dodać inny sposób komunikacji z aplikacją np. rest czy cokolwiek innego to wystarczy dodać obsługę resta, a logika dodawania pracownika do bazy będzie gotowa