Odmiana wszystkim dobrze robi. Dzisiejszy artykuł będzie w trochę innym stylu. Żadnych technicznych treści, tylko moje przemyślenia na temat przeżytej przeze mnie sytuacji. Poproszono mnie o przygotowanie i sprawdzanie zadań rekrutacyjnych dla osób, które ubiegały się o stanowisko Programisty .NET w Polskim Radiu. Postanowiłem stworzyć typowo praktyczny test umiejętności, bez skomplikowanych algorytmów czy struktur danych. Chodziło o to, by odnosił się do codziennej, standardowej pracy.

Opis Zadania

Zadanie składało się z napisania API udostępniającego możliwość zarządzania artykułami. Powiedzmy, ze to taki mikro serwis do zarządzania artykułami, umożliwiający komunikację synchroniczną. Powinien udostępniać takie akcję na artykule jak:

  • Dodanie
  • Edycję
  • Kasację
  • Publikację

Dodatkowo załączona była przykładowa encja artykułu:

Title (string)
Lead (string)
Content (string)
CategoryId (int)
Tags (IEnumerable<int>)

Nie wygląda to zbyt skomplikowanie, prawda?

Ostatni element to opisanie i uzasadnienie wyborów technologicznych jak i architektonicznych. To wszystko w kwestii samego zadania. Szacowałem czas potrzebny na wykonanie takiego zadania na jakieś 2 – 3 wieczory. Teraz mój drogi czytelniku mam do Ciebie prośbę. Zatrzymaj się na chwilę i zastanów jak byś podszedł do tego zadania 🙂

CRUD-okalipsa

W głowie miałem wiele schematów rozwiązania. Nikt nie spodziewał się wydarzeń, które nastąpiły. 100% przybyłych prac to aplikację typu CRUD. Oczywiście, niektóre z nich były bardzo fajnie napisane, wykorzystywały Architekturę Portów i Adapterów lub Czystą Architekturę. Niemniej jednak ciągle to były aplikacje CRUD-owe.

Trochę to rozumiem. Wszystkie akcję udostępnione za pomocą API są kwintesencją aplikacji CRUD-owej. Spodziewałem się ich dużej przewagi, aczkolwiek monopol mnie zaskoczył.

Najgorszym przypadkiem był człowiek, z którym mam nadzieje, nigdy nie będę musiał pracować. Zamiast gotowej aplikacji odpisał: “No mógłbym wam takiego CRUD-zika postawić, ale po co?”. Ręce opadły, kakałko się rozlało…

Miałem ogromną nadzieję, że w trakcie rekrutacji padną pytania uściślające, jak na przykład:

  • Czy wystarczy implementacja repozytoriów w pamięci? (Definiuje implementację warstwy bazy danych)
  • Czy podczas edycji artykułu serwis ma zachować jego wcześniejszą wersję? (Dodanie historii do encji zdecydowania podwyższa poziom złożoności)
  • Jak ma wyglądać obsługa błędów? (Format zwracania błędów etc.)

Jak idę do knajpy na kakałko to pytają, czy chce bitej śmietany. Tutaj – zero, nic, null. Sam nie jetem fanem wybiegania przed szereg z pytaniami, co nie znaczy, że tego nie robię. Uważam, i to raczej obiektywnie, że częściowe zbieranie informacji na temat zadania należy do obowiązków programisty (a już na pewno, gdy brak analityka biznesowego w procesie). Pamiętam kilka przypadków (a pewnie więcej mi uciekło), gdy ktoś wbiegał do pokoju, rzucał kilka haseł dotyczących nowej funkcjonalności i wychodził. Mogłem zacząć rzeźbić i poprawiać wielokrotnie, byłaby to jednak strata mojego czasu jak pieniędzy pracodawcy – trzeba dopytywać.

Jak nie CRUD to co?

Ten artykuł nie ma za zadanie hejtowanie aplikacji typu CRUD. Zważając na wymagania i treść zadania rekrutacyjnego była to po prostu jedna z dróg do jego wykonania. Trzeba jednak pamiętać, że:

  • w programowaniu występują też inne architektury pozwalające na skuteczniejsze radzenie sobie czy to ze złożonością procesów, czy też z ich wydajnością. Oczywiście CRUD też powinien być w naszym repertuarze, jednak pamiętajcie by zastanowić się, czy najprostsza droga zawsze spełnia wymagania klienta.
  • należy zawsze przemyśleć zadanie, zanim przysiądziemy do próby rozwiązania. Jeśli natrafimy na coś niejasnego – należy pytać.

Dzięki za przeczytanie tego artykułu.
Do następnego!

Cześć