Tâche architecturale pour entretien pour Go et Java

Défi d'entretien architectural : évaluer la pensée architecturale des développeurs

Cette tâche évalue la maîtrise des principes SOLID, de la SRP et de la flexibilité du système. Les candidats doivent étendre une structure (ou classe) existante de calcul de salaire des employés — qui génère également un rapport PDF — afin d’intégrer les managers. Contraintes clés : mêmes KPI et pourcentages de prime par rapport au salaire de base, mais les managers ont un salaire de base plus élevé. Le système doit supporter les évolutions futures avec le minimum de perturbations.

Pour Go, cela signifie créer un struct ; pour les langages orientés objet, une class. Bien que simple en apparence, cette tâche teste la capacité à détecter les violations de conception et à construire une architecture évolutif.

Erreurs courantes et solution pilotée par l’IA

La plupart des candidats négligent la violation de la SRP : la structure initiale mélange le calcul du salaire et la génération de rapport. La bonne approche consiste à séparer les responsabilités.

La solution IA utilise la composition et les interfaces :

• Un Employee de base avec des champs partagés (taux, % KPI, % prime) et des méthodes (CalculateBase, CalculateKPI, CalculateBonus).
• Une interface SalaryCalculator avec une méthode CalculateSalary() *Report.
• Manager compose Employee et applique un multiplicateur pour augmenter le salaire de base.
• Un ReportGenerator dédié accepte n’importe quel SalaryCalculator.
• Des constructeurs NewEmployee et NewManager gèrent l’initialisation.

Problème : un générateur de rapport ne peut pas anticiper les différences futures (ex. : nombre de rapports directs, calendriers KPI variables). Cela oblige à des conditions ou à des réécritures — violation de l’OCP.

Pièges cachés dans l’énoncé

L’énoncé contient intentionnellement des pièges :

• Violation de la SRP : « une classe qui calcule le salaire… et crée un rapport ». Les candidats devraient proposer une séparation.
• Généralisation erronée : « mêmes KPI et pourcentages de prime ». Les formules peuvent évoluer indépendamment selon les rôles.
• Simplification abusive du rôle : « seul le salaire de base diffère ». Les managers sont des entités métier distinctes, avec leurs propres KPI et zones de responsabilité.

Les bons candidats posent des questions clarificatrices : comment évoluent les formules ? Quels données vont dans le rapport ? De nouveaux rôles sont-ils prévus ?

Critères d'évaluation du candidat

L’évaluation porte sur la réflexion, pas sur le code :

• Questions posées : clarifie les exigences, découvre les hypothèses implicites.
• Justification : explique les choix de conception (SOLID, composition vs héritage).
• Flexibilité : prévoit l’évolution du système (ajout de rôles, formats de rapport).
• Analyse des avantages/inconvénients : auto-critique de la solution proposée.
• Testabilité : composants conçus pour être isolés et testés unitairement.

Architecture recommandée

Une solution viable (style Go, adaptable aux langages orientés objet) :

• Interfaces :

- SalaryCalculator : méthodes pour calculer le salaire de base, KPI, prime, total.

- ReportDataProvider : fournit les données du rapport (salaire, champs supplémentaires).

- ReportTemplate : Generate(ReportDataProvider) PDF.

• Implémentations :

- EmployeeSalary et ManagerSalary implémentent SalaryCalculator.

- EmployeeReport et ManagerReport implémentent ReportTemplate, chacun gardant une référence à son SalaryCalculator correspondant.

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

Avantages :

• Ajout facile de nouveaux rôles (ex. : DirectorSalary + DirectorReport).
• Aucune logique conditionnelle dans le générateur de rapport.
• La composition permet une réutilisation entre composants.

Points clés à retenir

• Application stricte de la SRP : calcul et rapport sont des préoccupations distinctes.
• Conformité à l’OCP : ajout de nouveaux rôles sans modifier le code existant.
• Composition plutôt que héritage : favorise l’adaptabilité à long terme.
• Usine pour l’encapsulation : masque la complexité de création.
• Questions du candidat : signalent une analyse profonde et réfléchie.

— Editorial Team