Architektonická úloha na pohovor pro Go a Java

Architektonická úloha pro testování myšlení vývojářů na pohovoru

Úloha testuje pochopení principů SOLID, SRP a pružnosti systému. Kandidátovi je předloženo rozšíření stávající struktury (nebo třídy) pro výpočet mzdy zaměstnance, která zároveň generuje PDF-protokol, pro manažera. Klíčové podmínky: stejný procentuální podíl KPI a odměny z mzdy, ale u manažera je základní mzda vyšší. Systém musí být snadno upravitelný i v dlouhodobém horizontu.

Pro jazyk Go se formulace týká vytvoření struktury, pro objektově orientované jazyky pak třídy. Na první pohled jednoduchá úloha ověřuje schopnost rozpoznat porušení principů a navrhnout škálovatelnou architekturu.

Analýza typických chyb a řešení AI

Většina kandidátů ignoruje porušení SRP: původní struktura kombinuje výpočet mzdy a generování protokolu. Správný přístup spočívá v oddělení odpovědností.

Řešení AI využívá kompozici a rozhraní:

• Základní struktura Employee s běžnými poli (sazba, % KPI, % odměny) a metodami (CalculateBase, CalculateKPI, CalculateBonus).
• Rozhraní SalaryCalculator s metodou CalculateSalary() *Report.
• Manager komponuje Employee a aplikuje koeficient pro zvýšení mzdy.
• Samostatný ReportGenerator přijímá SalaryCalculator.
• Konstruktory NewEmployee, NewManager pro inicializaci.

Problém: jednotný generátor protokolů nebere v úvahu budoucí rozdíly (počet podřízených u manažera, grafik KPI u zaměstnance). Vyžaduje přepsání nebo podmínkovou logiku, což porušuje OCP.

Problémy v zadání úlohy

Zadání úmyslně obsahuje pasti:

• Porušení SRP: "třída, která počítá mzdu ... a vytváří protokol". Kandidát by měl navrhnout oddělení.
• Iluze obecnosti: "stejný procentuální podíl KPI a odměny". Vzorce mohou být nezávisle změněny pro různé role.
• Zjednodušení rolí: "liší se pouze základní mzda". Manažer je samostatná business entita s unikátními KPI a odpovědnostmi.

Dobrý kandidát položí upřesňující otázky: jak se mění vzorce, jaká pole jsou v protokolu, plány pro nové role.

Kritéria hodnocení kandidátů

Hodnotí se nekód, ale myšlení:

• Otázky: Upravuje požadavky, odhaluje skryté změny.
• Argumentace: Odůvodňuje volbu (SOLID, kompozice vs dědičnost).
• Pružnost: Plán evoluce systému (přidání rolí, formátů protokolů).
• Pozitiva a negativa: Samokritika řešení.
• Testovatelnost: Izolace komponent pro unit-testy.

Doporučené řešení

Možná architektura (pro Go, analogicky pro třídy):

• Rozhraní:

- SalaryCalculator s metodami pro výpočet (base, kpi, bonus, total).

- ReportDataProvider s daty pro protokol (mzda, další pole).

- ReportTemplate s Generate(ReportDataProvider) PDF.

• Implementace:

- EmployeeSalary a ManagerSalary implementují SalaryCalculator.

- EmployeeReport a ManagerReport implementují ReportTemplate, uchovávají odkaz na příslušný SalaryCalculator.

• Továrna: NewReport(templateType string, calc SalaryCalculator) ReportTemplate.

Výhody:

• Snadné přidání rolí (nová DirectorSalary + DirectorReport).
• Žádná podmínková logika v generátoru.
• Kompozice zajišťuje opakované použití.

Co je důležité

• Oddělení SRP: Výpočet a protokol – samostatná rozhraní.
• OCP dodržení: Nové role bez změny stávajícího kódu.
• Kompozice > dědičnost: Pružnost pro dlouhodobě živý systém.
• Továrny pro inkapsulaci: Skrývají detaily tvorby.
• Otázky kandidáta: Ukazatel hlubokého myšlení.

— Editorial Team