W tym artykule opiszę pułapki i zagrożenia związane z szablonem CRUD tworzonym w Spring Boot, którego uczy się na Bootcamp. Od razu zaznaczę, że nie jestem przeciwnikiem Bootcamp’ów. Po prostu wiem z własnego doświadczenia z czym zmagają się moi uczniowie, którzy na Bootcamp nauczyli się lub nie nauczyli jak tworzyć aplikacje CRUD z użyciem Springframework.Tak, wiele osób na różnym etapie Bootcamp zgłasza się do mnie.

Wstęp

Dlaczego wymieniam Bootcamp? Tam właśnie zaczęła się idea “projektów typu CRUD” i rozpowszechniła się na pozostałe obszary internetu, a następnie były one kopiowane i powielane. Czym jest CRUD i jak napisać jego kod wyjaśniłem w artykule Pierwsza klasa jako serwis CRUD – kod Java, IntelliJ, krok po kroku.

Powtarzalność i powszechność rozwiązań powielanych w projektach

Pierwszą pułapką jest powtarzalność i powszechność rozwiązań powielanych w projektach realizowanych na Bootcamp. Dlaczego jest, to takim dużym problemem? Spójrzmy na, to z perspektywy osoby prowadzącej rekrutację i przeglądającej dużą ilość CV. Kiedy rekruter widzi w CV kolejny projekt o podobnie brzmiącej nazwie i wyglądające podobnie do poprzednich. Zaczyna się zastanawiać, co daną osobę może wyróżniać spośród innych jej podobnych? Dlaczego akurat, to CV ma przejść do kolejnego etapu selekcji?

Tak, jak pisałem w Jak znaleźć pierwszą pracę jako Junior Java Developer? “Osoba rekrutująca, przeglądając CV, może stworzyć dwie grupy jedna, to studenci, np. po studiach informatycznych, a druga grupa, to osoby kończące Bootcamp. Niestety „pierwszeństwo” mają studenci.”. Jeżeli nasze CV przejdzie do dalszego etapu, to należy zrobić wszystko, aby wyróżnić się spośród innych z szablonem CRUD z Bootcamp.

Jak rozwiązać problem?

Jak rozwiązać problem powszechności aplikacji CRUD powielanych na Bootcamp? Pisałem już o tym w Własne portfolio – jak zbudować dobre portfolio i gdzie je umieścić?. “Dobre portfolio moim zdaniem powinno zawierać zarówno jeden „większy” projekt z wykorzystaniem Spring Framework jak również „mniejsze” projekty prezentujące np. właściwości języka Java. Projekt w Spring Framework, to niekoniecznie wspomniany wcześniej CRUD, jeżeli już robimy CRUD’a, to ważne, aby miał on dobrą dokumentację w pliku READ.ME oraz sam kod zawierał testy jednostkowe, np. w JUnit i był zgodny z SOLID i DRY.”. Rozwiązaniem jest po prostu nieszablonowy projekt.

Przykład nieszablonowego projektu opisałem w Jak znaleźć pierwszą pracę jako Junior Java Developer?. “Projekt będzie składał się z aplikacji serwerowej i łączącej się z nią aplikacji mobilnej. Możemy np. stworzyć aplikację mobilną, która dla bieżącej pogody i lokalizacji przygotuje propozycję ubrań na dany dzień. Brzmi skomplikowanie, ale tak na prawdę nie jest.”.

Schematyczne i wierne odzwierciedlanie wyuczonego szablonu

Pułapką numer dwa jest “schematyczne i wierne odzwierciedlanie wyuczonego szablonu CRUD”. Osoby, które widzą kod z artykułu Pierwsza klasa jako serwis CRUD – kod Java, IntelliJ, krok po kroku często zadają mi pytanie “dlaczego tak pisać kod, a nie w sposób jaki nauczyłem się na Bootcamp lub z tutorial’a?”. Z takimi samymi pytaniami spotykam się podczas moich zajęć z uczniami.

Zastanówmy się nad powyższymi pytaniami. Dlaczego nazwałem metody: create, read, update i delete, zamiast: createCar, getCar, modifyCar, removeCar. Dlaczego dla klas nie użyłem sufiksu Dto lub Model? Dlaczego główna klasa nazywa się CarService, a nie CarCrud? Za chwilę odpowiem na powyższe pytania, ale najpierw zobrazuję, to za pomocą kodu Java.

// 1. poprawna konwencja nazewnicza według mnie
public class CarService {
    public Car create(Car car) {
        return null;
     }
}
// 2. poprawna konwencja nazewnicza według Bootcamp, tutorial
public class CarCrud {
    public CarDto createCar(CarDto carDto) {
        return null;
     }
}

W powyższym fragmencie kodu problemem jest schematyczne podejście do konwencji nazewniczej. Rzadko kiedy w różnych projektach konwencja nazewnicza jest taka sama lub chociaż podobna do tej, którą widzieliśmy w innym projekcie lub nas nauczono. Konwencja nazewnicza wskazuje, a nie narzuca jak powinno nazywać się klasy, metody i zmienne. Takie schematyczne podejście zaciemnia i zamazuje sens tworzenia klasy typu CRUD.

Tak, jak pisałem w Pierwsza klasa jako serwis CRUD – kod Java, IntelliJ, krok po kroku: “Bardzo wiele aplikacji jest tzw. CRUD’ami, czyli udostępnia podstawowe operacje tworzenia (create), odczytu (read), modyfikacji (update) oraz usuwania (delete) obiektów jakiejś klasy. Dla przykładu weźmy katalog samochodów, gdzie mamy klasę Car.”. Właśnie na tym należy się skupić i dostosować szablon CRUD do projektu.

Wyjaśnię dlaczego “1. poprawna konwencja nazewnicza według mnie” jest lepszym rozwiązaniem. Dodawanie “Car” do nazwy metody, co daje nam “createCar()” jest zbędne. Po pierwsze, działamy w obrębie klas CarService i przekazujemy do metody parametr typu “Car”, czyli create(Car car). Moim zdaniem jest, to wystarczające, aby wiedzieć, że metoda “create()” dotyczy obiektów klasy “Car”, czyli jest w kontekście danej klasy. To jest powielanie już istniejących informacji, czyli tzw. masło maślane.

Oczywiście stosowanie nazw np. CarDto, CarModel, itp. ma sens, jeżeli tworzymy aplikację wielowarstwową, a zakładam, że taką tworzymy. Wtedy będziemy mieli kilka różnych klas z tą samą nazwą np. Car. Więcej o aplikacjach, które posiadają warstwy napisałem w Aplikacje Java mają warstwy jak tort urodzinowy – aplikacja trójwarstwowa.

Jak rozwiązać problem?

Jak rozwiązać problem schematycznego i wiernego odzwierciedlania wyuczonego szablonu CRUD? Przede wszystkim należy traktować szablon jak zbiór wytycznych, które rozwiązują konkretny problem, a nie jak sposób rozwiązywania wszystkich zagadnień programistycznych. To tak jak z montażem drzwi wiadomo, że w większości przypadków będą one prostokątem, który należy zamontować w ścianie. Wtedy pojawia się zamawiający i mówi, że mają, to być np. drzwi przesuwane z okienkiem dla jego kotów.

Podsumowanie

Tworzenie aplikacji typu CRUD należy ćwiczyć. Trzeba znaleźć kilka tutoriali, kursów przedstawiających jak, to należy robić i wykonać każdy z nich. Jeżeli da się, to można wydzielić z nich część wspólną i stworzyć własny przepis na szablon CRUD.