Welche Art von Einsichten oder Fragen würde Sie dazu bringen, die OOAD-Fähigkeiten einer Person zu bestimmen?
Antworten:
Sie könnten ein halbherziges OO-Design eines einfachen Problems zeigen und diskutieren, was es tut, was gut und was schlecht daran ist, ob es flexibel genug ist, was verbessert werden könnte und wie.
Wenn Sie die Diskussion in Gang bringen möchten, fragen Sie, was die Person über einen Aspekt des Codes denkt, aber nicht mit einer Leitfrage.
Es ist wichtig, sich daran zu erinnern, dass die Diskussion wichtig ist und nicht, dass Sie die Antworten vorher gekannt haben. Jeder anständige Entwickler sollte in der Lage sein, auf etwas über den Code hinzuweisen, an das Sie vorher noch nicht einmal gedacht haben.
Besprechen Sie ein offenes Designproblem mit der Person. Sehen Sie, wie er / sie ein Modell des Systems erstellt, welche Art von Fragen gestellt werden und wie sich das Design als Reaktion auf neue Informationen ändert.
Ein gutes Beispiel - von Steve Yegge in einem seiner Blog-Beiträge erwähnt - ist die Aufforderung an die Person, ein Objektmodell für XML zu erstellen.
Eine gute Kenntnis aller gängigen Entwurfsmuster kann beweisen, dass der Kandidat tatsächlich nach Lösungen für seine Entwurfsprobleme gesucht hat.
In der Lage zu sein, sie zu diskutieren und zu wissen, wann man sie anwendet oder nicht, ist ein guter Hinweis darauf, dass er sie versteht.
Es kann auch hilfreich sein, ihn zum Beispiel nach Verwendungen in seinen früheren Erfahrungen zu fragen.
Gib kein Vokabeltest. "Vererbung definieren" oder "3 Merkmale des OO-Designs benennen" sind Fragen, die nichts über die Fähigkeiten des Einzelnen aussagen, sondern nur darüber, wie lange er / sie zuletzt ein Lehrbuch gelesen hat. Ich habe mehrere großartige Programmierer getroffen, die diese Fähigkeiten jeden Tag nutzen, aber ersticken würden, wenn sie gebeten würden, die formale Definition zu geben.
Wenn möglich, fragen Sie nach einem Beispielcode.
Suchen Sie andernfalls einen prozeduralen Code als Beispiel (oder einen schlecht gestalteten OO-Code) und fragen Sie sie, wie sie ihn neu entwerfen, verallgemeinern und verbessern würden. Stellen Sie sicher, dass das Programm über einen zusätzlichen Kontext verfügt, damit das Redesign sinnvoll sein kann.
Letztendlich ist das, was Sie testen - Design - subjektiv. Daher sollte Ihre Bewertung offen sein, um mehrere mögliche gute Lösungen zu ermöglichen, und nicht nur eine einzige. Denken Sie dann über mögliche Änderungen an Anforderungen nach, die eine Änderung der Schnittstelle erzwingen würden: Wie gehen sie damit um?
Lesen Sie das Buch Head First Design Patterns. Alle Beispiele im Buch beginnen mit einem objektorientierten Problem und enden dann im Entwurfsmuster. Sie erklären auch, warum bestimmte OOP-Konzepte begrenzte Ergebnisse erzielen und warum bestimmte besser sind als andere.
Obwohl es sich um ein Design Pattern-Buch handelt, ist dieses Buch voller Probleme von OOP :-)
Fangen Sie einfach an: Worum geht es bei OOP?
Sie könnten zunächst nach den Grundvoraussetzungen von OOP fragen: Abstraktion, Polymorphismus, Vererbung und Kapselung. Gutes Denkanstoß, um sie aufzuwärmen.
Gib ihnen ein Problem
Stellen Sie ihnen als Nächstes ein Problem vor, bei dem es wahrscheinlich um Muster geht. Es ist nicht notwendig, Muster zu benennen oder zu verwenden, aber ihr Ansatz wird wahrscheinlich einige ergeben, wenn sie Erfahrung in diesem Bereich haben.
Möglicherweise dynamische Validierung der Texteingabe. Sie möchten in der Lage sein, die Eingabe zeichenweise zu überprüfen, um festzustellen, ob es sich um ein gültiges Datum, eine gültige Uhrzeit oder ein gültiges Datum und eine gültige Uhrzeit im ISO8601-Format handelt. Sie erhalten jedes Mal eine Kopie der Eingabezeichenfolge, wenn eine Taste gedrückt wird, und Sie können einen Booleschen Wert zurückgeben, um anzugeben, ob der Text in mindestens einem der Formate gültig bleibt. Bitten Sie sie, ein Design anhand der OO-Designprinzipien zu besprechen und zu skizzieren.
Bis Sie fertig sind
dann hast du eine ziemlich gute Idee, wenn sie OOD verstehen.
Geben Sie ihnen wieder das gleiche Problem, aber fragen Sie diesmal nach einem anderen Design
Bitten Sie sie nun, das System ohne Verwendung eines Observer-Musters (falls erwähnt) neu zu gestalten. Sie können sich für einen Chain-of-Responsibility-Ansatz oder ein Befehlsmuster entscheiden. Es ist dir egal, welche, du weißt, dass sie ein vernünftiges Verständnis für die Prinzipien haben.
Selbst wenn sie sich nicht für einen musterbasierten Ansatz entscheiden, führt das Hören der Art und Weise, wie sie versuchen, das Problem in die zugehörige Funktionalität zu zerlegen, zu den gewünschten Ergebnissen.
Ich neige dazu, ein reales Szenario auszuwählen, das jedem bekannt ist †, und sie zu bitten, die Entitäten zu identifizieren. die beteiligten Akteure; Welche Wechselwirkungen gibt es zwischen ihnen? wo gemeinsame Merkmale abstrahiert werden könnten; Welche Eigenschaften müssen berücksichtigt werden?
Ja, Sie könnten sie bitten, sich zu setzen und UML zu zeichnen. Ja, Sie könnten ihnen Fragen zu einigen OOP-Implementierungsspezifikationen stellen, um zu sehen, ob sie "den ersten Schritt machen" können.
Was ein Arbeitgeber in seinem Team wirklich braucht, ist ein Geist, der die Konzepte versteht und sie auf alles anwenden kann, was auftaucht. Besonderheiten können schnell erlernt werden, wenn Konzepte eingebettet sind.
† Tiefe Vertrautheit und das Fehlen einer Verbindung mit Code helfen: Die Benutzung eines Badezimmers durch eine Familie am Morgen; Abendessen kochen; eine Buslinie zur Arbeit; die Montage eines Autos.
Etwas, das ziemlich gut zu funktionieren scheint und eigentlich nur ein paar Sekunden dauert: Bitten Sie sie, ein Objektmodell zu entwerfen. Es ist egal für was. Es kann absolut trivial sein. In der Tat sollte es wahrscheinlich trivial sein, den Test nicht unnötig herauszuziehen.
Wenn das erste, was sie schreiben, ein Objekt ist, sind sie in ihrem Verständnis von OO bereits 99% ihrer Kollegen voraus. Wenn das erste, was sie schreiben, eine Klasse ist, bitten Sie sie, den nächsten Kandidaten einzusenden und darüber nachzudenken, warum er OOP und nicht COP heißt.