Zadanie architektoniczne na rozmowę kwalifikacyjną dla Go i Java

Zadanie architektoniczne na rozmowie kwalifikacyjnej: sprawdzenie myślenia systemowego

To zadanie testuje zrozumienie zasad SOLID, SRP oraz elastyczności systemu. Kandydat ma rozszerzyć istniejącą strukturę (lub klasę) obliczania wynagrodzenia pracownika, która generuje również raport PDF, dla menedżera. Kluczowe warunki: ten sam procent KPI i premii od wynagrodzenia, ale wyższe wynagrodzenie podstawowe u menedżera. System musi być łatwy do modyfikacji w długim terminie.

W Go zadanie brzmi jako stworzenie struktury, w językach z klasami — klasy. Choć wygląda prosto, to zadanie sprawdza zdolność do wykrywania naruszeń zasad projektowych i tworzenia skalowalnej architektury.

Analiza typowych błędów i rozwiązania AI

Większość kandydatów ignoruje naruszenie SRP: pierwotna struktura łączy obliczanie wynagrodzenia i generowanie raportu. Prawidłowy podejście to rozdzielenie odpowiedzialności.

Rozwiązanie AI wykorzystuje kompozycję i interfejsy:

• Podstawowa struktura Employee z wspólnymi polami (stawką, procentem KPI, procentem premii) i metodami (CalculateBase, CalculateKPI, CalculateBonus).
• Interfejs SalaryCalculator z metodą CalculateSalary() *Report.
• Manager komponuje Employee, stosuje współczynnik wzrostu wynagrodzenia.
• Oddzielny ReportGenerator przyjmuje SalaryCalculator.
• Konstruktory NewEmployee, NewManager do inicjalizacji.

Problem: jednolity generator raportów nie uwzględnia przyszłych różnic (liczba podwładnych u menedżera, schemat KPI u pracownika). Wymaga on ponownego pisania lub logiki warunkowej, co narusza OCP.

Problemy w treści zadania

Treść zawiera celowe pułapki:

• Naruszenie SRP: "klasa licząca wynagrodzenie ... i tworząca raport". Kandydat powinien zaproponować rozdzielenie.
• Iluzja uogólnienia: "ten sam procent KPI i premii". Formuły mogą się zmieniać niezależnie dla różnych stanowisk.
• Uproszczenie ról: "różni się tylko wynagrodzeniem podstawowym". Menedżer to osobna jednostka biznesowa z unikalnymi KPI i obszarami odpowiedzialności.

Dobry kandydat zadaje precyzyjne pytania: jak zmieniają się formuły, jakie pola są w raporcie, plany na nowe role.

Kryteria oceny kandydatów

Ocenia się nie kod, a sposób myślenia:

• Pytania: Uściśla wymagania, wykrywa ukryte zmiany.
• Argumentacja: Uzasadnia wybór (SOLID, kompozycja vs dziedziczenie).
• Elastyczność: Plan ewolucji systemu (dodawanie ról, formatów raportów).
• Zalety i wady: Samokrytyka rozwiązania.
• Testowalność: Izolacja komponentów do testów jednostkowych.

Zalecane rozwiązanie

Możliwa architektura (dla Go, analogicznie dla języków z klasami):

• Interfejsy:

- SalaryCalculator z metodami obliczania (podstawowe, KPI, premia, całkowite).

- ReportDataProvider z danymi do raportu (wynagrodzenie, dodatkowe pola).

- ReportTemplate z metodą Generate(ReportDataProvider) PDF.

• Realizacje:

- EmployeeSalary i ManagerSalary implementują SalaryCalculator.

- EmployeeReport i ManagerReport implementują ReportTemplate, przechowują referencję do odpowiedniego SalaryCalculator.

• Fabryka: NewReport(templateType string, calc SalaryCalculator) ReportTemplate.

Zalety:

• Łatwe dodawanie nowych ról (nowa DirectorSalary + DirectorReport).
• Brak logiki warunkowej w generatorze.
• Kompozycja zapewnia ponowne wykorzystanie.

Co jest ważne

• Podział SRP: Obliczanie i raportowanie — osobne interfejsy.
• Zgodność z OCP: Nowe role bez zmiany istniejącego kodu.
• Kompozycja > dziedziczenie: Elastyczność dla długotrwałego systemu.
• Fabryki do inkapsulacji: Ukrywają szczegóły tworzenia.
• Pytania kandydata: Wskaznik głębokiego myślenia.

— Editorial Team