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ść