quel genre de points de vue ou de questions vous amènerait à déterminer les compétences OOAD d'une personne.
Réponses:
Vous pouvez montrer une conception OO à moitié réfléchie d'un problème simple, et discuter de ce qu'il fait, de ce qui est bon et mauvais à ce sujet, s'il est suffisamment flexible, ce qui pourrait être amélioré et comment.
Si vous avez besoin de lancer la discussion, demandez ce que la personne pense d'un aspect du code, mais pas avec une question directrice.
Il est important de se rappeler que la discussion est importante, pas que vous connaissiez les réponses à l'avance. Tout développeur décent devrait être capable de signaler quelque chose sur le code auquel vous n'aviez même pas pensé auparavant.
Discutez d'un problème de conception ouvert avec la personne. Voyez comment il procède à la construction d'un modèle du système, quels types de questions sont posées, comment la conception change en réponse à de nouvelles informations.
Un excellent exemple - mentionné par Steve Yegge dans l'un de ses articles de blog - est de demander à la personne de proposer un modèle d'objet pour XML.
Une bonne connaissance de tous les modèles de conception les plus populaires peut prouver que le candidat a réellement recherché des solutions à ses problèmes de conception.
Être capable d'en discuter et de savoir quand les appliquer ou non est une bonne indication qu'il les comprend.
Lui demander par exemple des utilisations dans ses expériences passées peut également aider.
Ne donnez pas un quiz de vocabulaire. «Définir l'héritage» ou «nommer 3 caractéristiques de la conception OO» sont des questions qui ne vous diront rien sur les compétences de l'individu, mais combien de temps depuis sa dernière lecture d'un manuel. J'ai rencontré plusieurs grands programmeurs qui utilisent ces compétences tous les jours, mais s'étoufferaient si on leur demandait de donner la définition formelle.
Si possible, demandez un exemple de code.
Sinon, trouvez du code procédural à utiliser comme exemple (ou du code OO mal conçu), puis demandez-leur comment ils le repenseraient, le généraliseraient et l'amélioreraient. Assurez-vous que le programme a un contexte supplémentaire, afin que la refonte puisse être significative.
En fin de compte, ce que vous testez - la conception - est subjectif. Ainsi, votre évaluation doit être ouverte pour permettre plusieurs bonnes solutions possibles, et pas seulement une seule. Réfléchissez ensuite aux modifications possibles des exigences qui forceraient un changement d'interface: comment les gèrent-elles?
Lisez le livre Head First Design Patterns. Tous les exemples du livre commencent par un problème orienté objet et se retrouvent ensuite dans le modèle de conception. Ils expliquent également pourquoi certains concepts de la POO obtiendront des résultats limités et pourquoi certains sont meilleurs que d'autres.
Même si un livre Design Pattern, ce livre est plein de problèmes de POO :-)
Commencez simplement: qu'est-ce que la POO?
Vous pouvez commencer par poser des questions sur les prémisses de base de la POO: abstraction, polymorphisme, héritage et encapsulation. Bonne nourriture pour réfléchir pour les réchauffer.
Donnez-leur un problème
Ensuite, présentez-leur un problème susceptible d'impliquer des régularités. Il n'est pas nécessaire de nommer ou d'utiliser des modèles, mais leur approche en donnera probablement s'ils ont une expérience dans le domaine.
Peut-être une validation de saisie de texte dynamique. Vous souhaitez pouvoir valider le caractère saisi caractère par caractère pour voir s'il s'agit d'une date, d'une heure ou d'une date et heure valides au format ISO8601. Vous obtenez une copie de la chaîne d'entrée chaque fois qu'une touche est enfoncée et vous pouvez retourner un booléen pour indiquer si le texte reste correct dans au moins un des formats. Demandez-leur de discuter et d'esquisser une conception en utilisant les principes de conception OO.
Au moment où vous avez fini de discuter
alors vous aurez une assez bonne idée s'ils comprennent OOD.
Donnez-leur à nouveau le même problème, mais cette fois demandez un design différent
Maintenant, demandez-leur de repenser le système sans utiliser de modèle Observateur (s'ils l'ont mentionné) - ils peuvent choisir d'adopter une approche de chaîne de responsabilité ou peut-être un modèle de commandement. Peu vous importe, vous savez qu'ils ont une compréhension raisonnable des principes en jeu.
Même s'ils n'adoptent pas une approche basée sur un modèle, le simple fait d'écouter la façon dont ils tentent de décomposer le problème en ses fonctionnalités connexes donnera les résultats que vous recherchez.
J'ai tendance à choisir un scénario du monde réel, quelque chose de bien connu de quiconque † et de leur demander d'identifier les entités; les acteurs impliqués; quelles interactions il y a entre eux; où des caractéristiques communes pourraient être résumées; quelles propriétés doivent être prises en compte.
Oui, vous pouvez leur demander de s'asseoir et de dessiner UML, oui, vous pouvez leur poser des questions de recherche sur certaines spécificités de mise en œuvre de la POO pour voir si elles peuvent "commencer à fonctionner".
Mais ce dont un employeur a vraiment besoin au sein de son équipe, c'est d'un esprit qui comprend les concepts impliqués et peut les appliquer à tout ce qui se présente. Les détails peuvent être appris rapidement, lorsque les concepts sont intégrés.
† Connaissance approfondie et absence de connexion avec l'aide du code: utilisation d'une salle de bains par une famille le matin; préparer le dîner; une ligne de bus pour se rendre au travail; l'assemblage d'une voiture.
Quelque chose qui semble plutôt bien fonctionner et qui ne prend en fait que quelques secondes: demandez-leur de concevoir un modèle d'objet. Peu importe pour quoi. Cela peut être absolument trivial. En fait, cela devrait probablement être trivial, pour ne pas faire traîner le test inutilement.
Si la première chose qu'ils écrivent est un objet, ils sont déjà en avance sur 99% de leurs pairs dans leur compréhension de l'OO. Si la première chose qu'ils écrivent est une classe, veuillez leur demander de sortir et d'envoyer le prochain candidat, et de réfléchir à pourquoi cela s'appelle OOP et non COP.