È ragionevole aspettarsi che uno sviluppatore esperto sappia quali sono i modelli di progettazione OOP? [chiuso]

Le probabilità sono di di conoscerle. Semplicemente non li conoscono come "modelli di progettazione"; cioè, potrebbero non avere familiarità con la terminologia accademica per tali cose. Ciò che vedete come una "macchina a stati" potrebbe semplicemente essere un approccio di buon senso a un problema per un programmatore più vecchio e più esperto. Non ho mai prestato molta attenzione ai "modelli di design", ad esempio, ma quando ho appreso cosa fosse una macchina di stato, ho dovuto ridere perché lo facevo da anni. Chi sapeva che ero un tale accademico? Ho sempre considerato l'abilità di codifica di base e non un "modello di progettazione".

Il punto non sta assumendo che i tuoi sviluppatori esperti conoscano i termini del libro di testo per le cose; invece, chiedi loro come strutturerebbero le classi o come si avvicinerebbero a un compito.

Le tue aspettative sono abbastanza ragionevoli per uno sviluppatore OO senior. Chiunque si chiami che senza conoscere Design Patterns dimostra semplicemente che l'esperienza non viene portata automaticamente dagli anni che passano :-( Certo, ci sono molti sviluppatori là fuori che hanno trascorso anni o addirittura decenni sul campo, senza mai parlare di design modelli - che mostrano semplicemente che non erano interessati ad apprendere nuove idee, migliorando se stessi e adottando le migliori pratiche.

Should a senior developer have prior experience with design patterns, or would you say that design patterns are such a simple topic that every decent developer can pick them up during training?

L'esperienza IMO conta molto. In teoria, uno sviluppatore decente può leggere su modelli di progettazione in un libro, o anche su Wikipedia, e capire il concetto di base in 15 minuti. Tuttavia, l'applicazione dei concetti richiede l'esperienza meritata. È facile infatuarsi di schemi, cercando di inserirli in ogni possibile pezzo di codice, l'arte per l'arte. È anche facile ignorarli dicendo che "i modelli non sono un proiettile d'argento, basta usare la cosa più semplice che potrebbe funzionare". Trovare la via di mezzo tra i due estremi con imparare quando e come utilizzare i modelli per risolvere i problemi reali, e quando non usarli, richiede anni di esperienza .

what questions would you ask instead to gauge their design abilities?

In accordo con quanto sopra, aggiungerei solo queste domande alla tua lista:

• Quali sono gli svantaggi dei modelli di progettazione (in generale e di quelli che menzionano esplicitamente)?
• Quando non per usarli, e perché?

Aggiornamento

@GrandmasterB ha un buon punto in quanto alcuni sviluppatori potrebbero utilizzare schemi di progettazione specifici senza conoscerne il nome. In un certo senso ha ragione in quanto questa è una domanda terminologica / di comunicazione. Tuttavia, l'altra faccia della medaglia è che è davvero una domanda terminologica / di comunicazione :-) Cioè, uno dei principali vantaggi di Design Patterns è quello di dare un vocabolario comune agli sviluppatori, migliorando enormemente la comunicazione . (Cerca di spiegare l'idea di base di Adapter senza usare la parola stessa oi suoi sinonimi "wrapper" et al!) Quindi, per quanto talentuoso e competente un candidato possa essere, senza conoscere l'ampiamente accettato terminologia (s) introdurrà un problema di comunicazione nella tua squadra.

Uno sviluppatore senior ? Decisamente. Un junior dovrebbe. Ho 15 anni, non ho un'educazione formale sull'argomento e anche io li capisco. Non è solo ragionevole aspettarsi che li conoscano, sarebbe inaccettabile se non lo sapessero. Supponendo che sappiano qualcosa sulla programmazione orientata agli oggetti, che probabilmente fanno.

In un'intervista dovresti chiedere cosa è importante sapere per il candidato per svolgere il lavoro.

Se devono conoscere i nomi dei pattern come se fossero di Gang of Four, allora questo è un requisito valido.

Se, d'altra parte, vuoi che mostrino un'adeguata conoscenza operativa dell'architettura del programma, penso che sia meglio dare loro un problema e chiedere loro come strutturerebbe il codice. Se ti danno la soluzione di pattern appropriata, hai la prova che lo sanno, indipendentemente dal nome utilizzato.

Ogni volta che intervengo per posizioni Senior tendono ad essere più "pratici" di Q & A. Voglio una chiara dimostrazione di abilità e conforto nella programmazione. Voglio anche una solida base nei concetti CS, che significa competenze più generali su come applicare concetti come incapsulamento, algoritmi, accoppiamento / coesione, ecc. Esperienza e familiarità in più linguaggi e paradigmi.

Dipende dall'area della loro esperienza. Non mi aspetto che uno sviluppatore C incorporato conosca molto dei modelli di progettazione. Se stiamo parlando di uno sviluppatore Java o .NET, dovrebbero avere familiarità con i modelli di progettazione, e soprattutto come non essere troppo portati via con loro.

Supponendo che tu cerchi l'anzianità in OOP, la risposta è sì sì. I modelli di progettazione sono lessici del linguaggio OOP.

Inoltre oggi è irragionevole pensare che un programmatore OOP decente con 10 anni di esperienza non possa nominare un modello di progettazione, essendo modelli di progettazione largamente adottati in API standard, librerie e framework di sviluppo.

Sono anni che ho fatto questa domanda durante le interviste ed è uno showstopper quando il candidato non fornisce risposte soddisfacenti sull'argomento.

Sì, ma probabilmente dovresti ottenere la loro comprensione chiedendo domande a design piuttosto che chiedere alle persone di elencare gli schemi di progettazione di cui hanno sentito parlare. Sono piuttosto a mio agio con gli schemi descritti in PoEAA, GoF e persino alcuni schemi di programmazione funzionale e ancora non penso che tu possa imparare molto di più sul mio approccio alla risoluzione dei problemi chiedendomi di nominare alcuni modelli.

Dato una domanda come "disegnami un editor di testo" con follow-up del tipo "Come stai andando a supportare oggetti incorporati come le immagini? Grassetto e corsivo? Annulla?" Probabilmente alla fine avrai sentito abbastanza per riconoscere il pattern di comando, il pattern composito, lo schema di memento e pochi altri con una breve conversazione.

I modelli di progettazione sono stati scoperti e quindi descritti in modo da avere un linguaggio comune con cui comunicare le decisioni di progettazione.

Ho sfortunatamente lavorato per qualcuno per cui ogni uso di un modello di progettazione doveva essere spiegato e giustificato, non a causa della dovuta diligenza, ma semplicemente perché non li conosceva. Non è divertente Ma gli sviluppatori più seri hanno, per caso o per progetto, imparato i nomi dei modelli OO più comunemente usati, se non altro, e la maggior parte degli sviluppatori di applicazioni aziendali vale la pena sapere almeno qualcosa sui più comuni pattern PoEAA.

ragionevole. Sicuramente. Necessario. No

Chiedo ai potenziali candidati se conoscono i modelli di progettazione. È solo uno dei tanti criteri da considerare nel suo complesso. Non trascurare l'immagine totale.

Sì, molti sviluppatori utilizzano inconsapevolmente alcuni schemi di progettazione, senza dubbio.

Non è questo il motivo per cui pongo la domanda.

È importante sapere che posso comunicare rapidamente ed efficacemente con un altro sviluppatore. Non voglio passare 20 minuti su una lavagna per spiegare una macchina a stati solo per scoprire che l'hanno "usata prima, ma non sapeva mai come chiamarla". Questo non è produttivo.

Aiutano anche nel processo di refactoring. Sfogliando il codice si potrebbe a malapena implementare una qualche forma di modello di fabbrica, ma il modello di fabbrica GoF ha resistito alla prova del tempo. Ecco perché il suo il modello di fabbrica, non ANCORA UN ALTRO fp (reinventare la ruota non è preferibile, Joel sul software ha molti svantaggi di farlo).

Un team che utilizza e riconosce l'importanza dei modelli di progettazione aumenta la comunicazione e la produttività. Se la tua squadra, come unità, non usa i dp, perde la loro rilevanza.

Parlando della mia esperienza, ho ignorato per un po 'i segni del design. Sapevo che esistevano, non ho mai letto su di loro. Una volta che ho finalmente morso il proiettile, mi sono reso conto che avevo sempre utilizzato il design pattern e non me ne ero reso conto o non sapevo che le mie soluzioni di design avessero effettivamente un nome comune.

Sarei più propenso a presentare una serie di problemi in cui un particolare modello di progettazione si adatta bene alla soluzione e vedere lo sviluppatore presentarsi con qualcosa di simile al modello. Se lo fanno, bene. Potrei essere ancora più incline ad assumere uno sviluppatore che usasse modelli di progettazione inconsapevoli, poiché vedo molti sviluppatori che hanno conoscenza del modello di progettazione che cercano di adattare una soluzione a un modello quando non è appropriato piuttosto che realizzare un particolare schema per risolvere il problema problema bene.

Penso che una domanda migliore sarebbe: dato un nome di un pattern, e una descrizione del pattern, ad esempio un Pattern Factory dal libro Gang of Four, il candidato dovrebbe essere in grado di creare uno scenario in cui il modello sarebbe un approccio ragionevole.

Ci sono sviluppatori con 5-10 anni di esperienza e ci sono sviluppatori senior. Non sono affatto la stessa cosa. Sì, se stai assumendo a livello senior e ti aspetti che le persone sappiano e utilizzino modelli di design, allora non assumerei una persona anziana che non conosceva. Sarebbe come assumere uno specialista di database che non capisca i join di sinistra. È roba piuttosto di base per un vero sviluppatore senior. Probabilmente assumerei comunque una persona junior.

Sì, in effetti dovrebbero avere familiarità con il termine e dovrebbero anche essere in grado di nominare alcuni dei modelli, ma non fare l'errore di confondere le conoscenze teoriche con l'esperienza.

Ci sono molte persone che prima di un colloquio rispolverano i modelli di progettazione e riescono a snocciolarli con una breve descrizione - ma questa è solo la teoria. È un vero sviluppatore senior in grado di individuare quando usarne uno, o senza la conoscenza di un modello formale risolverebbe il problema in un modo classico di progettazione.

Il modo migliore per controllare è lasciare che progettino qualcosa di fronte a te e facciano domande approfondite .. uno sviluppatore senior è qualcuno che può pensare in modo naturale a livello di astrazione. Queste sono le persone che "creano" i modelli di design.

Come la classe Peopleware che parla di assumere un giocoliere senza chiedere loro di destreggiarsi - solo perché dicono che possono fare non significa molto .. provali.

Come già detto, credo anche che sia giusto se non ricordano le parole d'ordine a memoria. Ma poiché questa è una posizione di alto livello, dovrebbero sapere quando applicare un modello per risolvere un problema in modo ottimale invece di utilizzare le soluzioni peggiori. Quindi, dai loro un problema che dovrebbe essere risolto usando un pattern (ad esempio, come creare un oggetto senza hard-coding della sua classe, come accedere agli elementi di un oggetto senza avere dettagli sulla sua implementazione, ecc.) E vedere come lo attaccheranno.

Sicuramente dovrebbero conoscere i modelli, ma non necessariamente le parole d'ordine.

Ad esempio MVC ha molte alternative molto simili come PAC, 3 livelli. Pochi anni fa un'altra popolare parola d'ordine di MVC era "Modello 2". In realtà conosco sviluppatori molto bravi che conoscono perfettamente questo modello, ma non sapevo che la parola d'ordine corrente per questo è MVC.

Molto semplicemente: se li stai usando, devi chiedere ai tuoi candidati. Se conoscono i pattern, allora dovrebbe aggiungere alcuni punti in più; ma non saperlo non dovrebbe necessariamente escluderli, specialmente se mostrano buone capacità OOD. È improbabile che gli sviluppatori che hanno partecipato a progetti di manutenzione conoscano molto i modelli di progettazione rispetto a coloro che sono stati incaricati di progettarli. dipende anche dal fatto che siano stati insegnati a disegnare modelli al college. Nella mia esperienza è improbabile che lo faranno. La maggior parte delle università e dei corsi privati ti insegnano OOP ma non OOD. Le probabilità che abbiano studiato DP sono ancora meno.

Personalmente, non avevo studiato DP fino a quando il mio progetto non ha richiesto anche me. Anche allora ho scoperto che avevo usato alcuni dei modelli, almeno in un modo simile se non nella maniera esatta descritta nel libro. Sono stato sorpreso di sapere che sono stati codificati. Quindi cerca buone capacità di progettazione se non conoscono DP. Se conoscono DP è probabile che siano bravi nel design ma li testano ancora. Potrebbero aver appena dato qualche ronzio sulla DP o scoperto da alcuni addetti ai lavori e hanno appena studiato alcuni modelli senza averli applicati.

È ragionevole aspettarsi che le persone che fanno domanda per un posto di lavoro con te sappiano (o apprendano) le cose che sono necessarie nella tua posizione di lavoro, indipendentemente dal fatto che siano o meno standard del settore. Altrimenti ti condanni per la mediocrità. Ma attenzione a fare della conoscenza (o abilità) un requisito di lavoro, se non è veramente necessario.

Diciamo che hai due candidati con sfondi approssimativamente simili, e uno è in grado di parlarti di schemi di progettazione, e l'altro no. Che cosa ti dirà su come si esibiranno sul lavoro?

Dici che il software esistente utilizza schemi di progettazione. È un vantaggio? Se é cosi, come? Il tuo obiettivo è che il nuovo software scritto sia conforme ai modelli esistenti o che vengano introdotti nuovi modelli? Perché?

Posso pensare a uno sviluppatore senior che non conosce i modelli di progettazione nella seguente situazione:

1. Ci sono solo un libro sui modelli di design. È il libro che li ha resi popolari in primo luogo. Se la persona non ha letto questo libro, è possibile che non sappia dei modelli di progettazione, o che ne abbia sentito parlare, ma non sa bene a cosa servono
2. Invece, dovrebbero sapere qualcosa come uml ....
3. Trovare informazioni utili sui modelli di progettazione da Internet non è facile. Sei molto fortunato se colpisci la pagina web corretta che ha una buona conoscenza dei modelli di design. Venire semplicemente al software dopo il 1995 potrebbe far sì che una persona non conosca il libro dei modelli di design, perché il libro è vecchio.

Perché uno sviluppatore in un ambiente non OO dovrebbe conoscere i modelli di progettazione OO? Ho lavorato in negozi solo Cobol, solo PL / SQL, solo Progress 4GL, ecc. I principi di progettazione OO sono irrilevanti lì, mi aspetterei che gli anziani di quegli ambienti avessero conoscenze rilevanti per quegli ambienti, non per i modelli di progettazione OO.

Essere in grado di citare senza pensieri da un catalogo di pattern non ti rende un buon sviluppatore (in effetti, nella mia esperienza, produce alcuni dei peggiori pezzi di codice che abbia mai visto). Eppure è questo che ti aspetti di essere il marchio di uno "sviluppatore senior". Ho lavorato nel settore per 15 anni, eppure non mi chiedono di disegnare un diagramma del modello. Non gli ho mai dedicato molto tempo, non ne ho bisogno. Ho acquisito abbastanza esperienza per trovare ciò che funziona senza dare un nome specifico ad esso, e se ho bisogno della definizione formale so dove cercarlo (e sì, ho i libri di riferimento nella mia biblioteca personale). Questo è il marchio dello sviluppatore esperto, non la conoscenza meccanica acquisita dal cramming di alcuni libri scolastici.