che tipo di approfondimenti o domande ti porterebbe a determinare le abilità OOAD di una persona.
Risposte:
Potresti mostrare un disegno OO a metà di un semplice problema e discutere cosa fa, cosa c'è di buono e di male, se è abbastanza flessibile, cosa può essere migliorato e come.
Se hai bisogno di avviare la discussione, chiedi cosa pensa la persona di alcuni aspetti del codice, ma non con una domanda principale.
Importante è ricordare che la discussione è importante, non che tu conoscessi le risposte in anticipo. Qualsiasi sviluppatore decente dovrebbe essere in grado di indicare qualcosa sul codice a cui non avevi nemmeno pensato prima.
Discutere con la persona di un problema di progettazione aperto. Scopri come procede alla costruzione di un modello del sistema, che tipo di domande vengono poste, come cambia la progettazione in risposta a nuove informazioni.
Un grande esempio - citato da Steve Yegge in uno dei suoi post sul blog - è quello di chiedere alla persona di elaborare un modello a oggetti per XML.
Avere una buona conoscenza di tutti i modelli di progettazione più popolari può dimostrare che il candidato ha effettivamente cercato soluzioni ai suoi problemi di progettazione.
Essere in grado di discuterne e sapere quando applicarle o meno è una buona indicazione che le comprende.
Chiedergli ad esempio l'uso delle sue esperienze passate può essere d'aiuto.
Non fare un quiz sul vocabolario. "Define Inheritance" o "name 3 features of OO design" sono domande che non ti diranno nulla sulle capacità dell'individuo, solo per quanto tempo dall'ultima volta che ha letto un libro di testo. Ho incontrato diversi programmatori fantastici che usano queste abilità ogni giorno, ma si strozzerebbero se gli venisse chiesto di dare la definizione formale.
Se possibile, chiedere il codice di esempio.
Altrimenti, trova un codice procedurale da utilizzare come esempio (o un codice OO mal progettato), quindi chiedi loro come lo ridisegnerebbero, generalizzerebbero e migliorerebbero. Assicurati che il programma abbia un contesto aggiuntivo, in modo che la riprogettazione possa essere significativa.
In definitiva ciò che stai testando, il design, è soggettivo. Pertanto, la tua valutazione dovrebbe essere aperta per consentire diverse possibili buone soluzioni, e non solo una singola. Quindi, pensa a possibili modifiche ai requisiti che potrebbero forzare una modifica dell'interfaccia: come la gestiscono?
Leggi il libro Head First Design Patterns. Tutti gli esempi nel libro iniziano con un problema orientato agli oggetti e finiscono con il modello di progettazione. Dicono anche perché alcuni concetti di OOP raggiungeranno risultati limitati e perché alcuni sono migliori di altri.
Anche se un libro Design Pattern questo libro è pieno dei problemi di OOP :-)
Inizia con semplicità: cos'è OOP?
Si potrebbe iniziare chiedendo le premesse di base di OOP: astrazione, polimorfismo, eredità e incapsulamento. Buon cibo per pensare di scaldarli.
Dai loro un problema
Quindi, presentali con un problema che potrebbe comportare modelli. Non è necessario nominare o utilizzare i modelli, ma il loro approccio probabilmente produrrà alcuni se hanno esperienza nell'area.
Convalida forse di input dinamico del testo. Vorresti essere in grado di convalidare il carattere di input per carattere per vedere se è una data, ora o data e ora valide nel formato ISO8601. Si ottiene una copia della stringa di input ogni volta che si preme un tasto e si può restituire un valore booleano per indicare se il testo rimane valido in almeno uno dei formati. Chiedi loro di parlare e delineare un progetto utilizzando i principi di progettazione OO.
Quando hai finito di chattare
allora avrai una buona idea se capiscono OOD.
Dai loro di nuovo lo stesso problema, ma questa volta chiedi un design diverso
Ora, chiedi loro di riprogettare il sistema senza usare un modello di osservatore (se lo hanno menzionato): possono scegliere di adottare un approccio a catena di responsabilità o forse un modello di comando. Non ti interessa davvero quale, sai che hanno una ragionevole comprensione dei principi coinvolti.
Anche se non scelgono un approccio basato su schemi, solo ascoltare il modo in cui tentano di scomporre il problema nella sua funzionalità correlata produrrà i risultati che stai cercando .
Tendo a scegliere uno scenario del mondo reale, qualcosa di ben noto a chiunque † e chiedere loro di identificare le entità; gli attori coinvolti; quali interazioni ci sono tra loro; dove si potrebbero sottrarre caratteristiche comuni; quali proprietà devono essere considerate.
Sì, potresti chiedere loro di sedersi e disegnare UML, sì, potresti chiedere loro di cercare domande su alcune specifiche dell'implementazione di OOP per vedere se riescono a "correre in terra".
Ma ciò di cui un datore di lavoro ha davvero bisogno all'interno del proprio team è una mente che comprenda i concetti coinvolti e possa applicarli a qualunque cosa si presenti. I dettagli possono essere appresi rapidamente, quando i concetti sono incorporati.
† Profonda familiarità e assenza di una connessione con l'aiuto del codice: l'uso da parte della famiglia di un bagno al mattino; cucinando la cena; una linea di autobus per lavorare; l'assemblaggio di un'auto.
Qualcosa che sembra funzionare piuttosto bene e in realtà richiede solo pochi secondi: chiedi loro di progettare un modello a oggetti. Non importa per cosa. Può essere assolutamente banale. In effetti, probabilmente dovrebbe essere banale non trascinare inutilmente il test.
Se la prima cosa che scrivono è un oggetto, sono già in vantaggio del 99% dei loro pari nella comprensione di OO. Se la prima cosa che scrivono è una lezione, chiedi loro di uscire e mandare il prossimo candidato e riflettere sul perché si chiama OOP e non COP.