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

Sto preparando domande per colloqui di lavoro per una posizione di sviluppo senior. Il lavoro includerebbe la progettazione orientata agli oggetti e il software esistente utilizza modelli di progettazione, quindi vorrei chiedere ai candidati di spiegare alcuni modelli di progettazione che conoscono, hanno usato, come li hanno usati, perché hanno li ho usati e così via. Tuttavia, nelle precedenti interviste quando ho chiesto agli sviluppatori senior con almeno 5-10 anni di esperienza sui modelli di progettazione, quasi nessuno ne ha mai sentito parlare. Penso che due sviluppatori su venti possano nominare un unico modello di progettazione (rispettivamente Singleton e MVC).

Quindi la mia domanda è: ha senso porre queste domande? O è un argomento così oscuro che non puoi aspettarti che i nuovi assunti li conoscano già?

Uno sviluppatore senior dovrebbe avere una precedente esperienza con i modelli di progettazione o diresti che i modelli di progettazione sono un argomento così semplice che ogni sviluppatore decente può prenderli in considerazione durante la formazione? In tal caso, quali domande faresti invece per valutare le loro capacità di progettazione?

Aggiungi Dopo aver letto le risposte finora, dovrei dare alcuni chiarimenti:

• Il lavoro è per uno sviluppatore .NET con esperienza in OOP / OOD
• Il codice esistente utilizza nomi di classi come IParameterGraphVisitore IStorageFactoryin molti punti
• Come chiedi alle persone le loro esperienze passate con i progetti OO che hanno creato, se non hanno il vocabolario per spiegare i loro progetti? Questo è quello che voglio fare, e tutto quello che posso inventare è "per favore, disegna sulla lavagna la gerarchia di design / oggetto del tuo ultimo progetto".

Le probabilità sono che fanno loro sapere. Forse non li conoscono come "modelli di progettazione"; cioè, potrebbero non avere familiarità con la terminologia accademica per tali cose. Ciò che vedi come una "macchina a stati" potrebbe essere semplicemente un approccio di buon senso a un problema per un programmatore più anziano ed esperto. Non ho mai prestato molta attenzione ai "modelli di progettazione", ad esempio, ma quando ho imparato cos'è una macchina statale, ho dovuto ridere perché lo facevo da anni. Chi sapeva che ero un tale accademico? L'ho sempre considerato un'abilità di programmazione di base e non un "modello di progettazione".

Il punto non è presumere che i tuoi sviluppatori esperti conoscano i termini del libro di testo per le cose; invece, chiedi loro come strutturerebbero le classi o come affrontare un compito.

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

Uno sviluppatore senior dovrebbe avere una precedente esperienza con i modelli di progettazione o diresti che i modelli di progettazione sono un argomento così semplice che ogni sviluppatore decente può prenderli in considerazione durante la formazione?

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

quali domande faresti invece per valutare le loro capacità di progettazione?

In accordo con quanto sopra, aggiungerei solo queste domande al tuo elenco:

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

Aggiornare

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

Uno sviluppatore senior ? Decisamente. Un junior dovrebbe. Ho 15 anni, non ho un'istruzione formale in materia 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, ciò che molto probabilmente fanno.

Durante un colloquio dovresti chiedere cosa è fondamentale per il candidato sapere per svolgere il lavoro.

Se devono conoscere i nomi degli schemi come quelli di Gang of Four, questo è un requisito valido.

Se, d'altra parte, vuoi che mostrino le conoscenze di lavoro appropriate sull'architettura del programma, penso che tu stia meglio dando loro un problema e chiedendo loro come strutturare il codice. Se ti danno la soluzione di modello appropriata, allora hai la prova che lo sanno, indipendentemente dal nome utilizzato.

Ogni volta che intervisto per posizioni senior tendono ad essere più "pratiche" delle domande e risposte. 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ù lingue e paradigmi.

Dipende dall'area delle loro competenze. Non mi aspetterei che uno sviluppatore di C incorporato sapesse molto sui modelli di progettazione. Se stiamo parlando di uno sviluppatore Java o .NET, dovrebbero avere familiarità con i modelli di progettazione, e in particolare come non lasciarsi trasportare troppo da loro.

Supponendo che stai cercando l'anzianità in OOP, la risposta è decisamente sì. I modelli di progettazione sono un lessico del linguaggio OOP.

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

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

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

Alla domanda come "progettami un editor di testo" con follow-up come "Come hai intenzione di supportare oggetti incorporati come immagini? Grassetto e corsivo? Annulla?" Probabilmente alla fine sentiresti abbastanza per riconoscere il modello di comando, il modello composito, il modello ricordo e alcuni altri con persino 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.

Purtroppo ho lavorato per qualcuno per il quale ogni uso di un modello progettuale doveva essere spiegato e giustificato, non per la dovuta diligenza, ma perché semplicemente non li conosceva. Non è divertente. Ma gli sviluppatori più seri hanno, per caso o design, appreso i nomi dei modelli OO più comunemente usati, se non altro, e la maggior parte degli sviluppatori di applicazioni aziendali che meritano il loro sale almeno sanno qualcosa sui modelli PoEAA più comuni.

Ragionevole. Sicuramente. Necessario. No

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

Sì, molti sviluppatori usano inconsapevolmente alcuni modelli di progettazione, senza dubbio.

Non è per questo che faccio la domanda.

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

Aiutano anche nel processo di refactoring. Guardando attraverso il codice si potrebbe implementare a casaccio una qualche forma di modello di fabbrica, ma il modello di fabbrica GoF ha resistito alla prova del tempo. Ecco perché è 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, allora perde la sua rilevanza.

Parlando per la mia esperienza, ho ignorato per un po 'gli schemi di progettazione. Sapevo che esistevano, non ne ho mai letto. Una volta finalmente morso il proiettile, mi sono reso conto che avevo sempre usato il modello di progettazione e non me ne sono reso conto o non sapevo che le mie soluzioni di progettazione avevano effettivamente un nome comune.

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

Penso che una domanda migliore sarebbe: dato un nome di un modello e una descrizione del modello, ad esempio un modello Factory dal gruppo Gang of Four, il candidato dovrebbe essere in grado di elaborare 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 conoscano e utilizzino i modelli di progettazione, non assumerei una persona senior che non avesse familiarità con loro. Sarebbe come assumere uno specialista di database che non capisse i join di sinistra. È roba piuttosto semplice per un vero sviluppatore senior. Probabilmente avrei assunto una persona più giovane però.

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 la conoscenza teorica con l'esperienza.

Ci sono molte persone che prima di un'intervista rispecchiano i modelli di progettazione e possono sconcertarli con una breve descrizione, ma questa è solo la teoria. È un vero sviluppatore senior in grado di individuare quando utilizzarne uno, o senza la conoscenza di un modello formale risolverebbe il problema in un modo di design classico.

Il modo migliore per verificare è lasciare che progettino qualcosa di fronte a te e porre domande di sondaggio. Uno sviluppatore senior è qualcuno che può pensare naturalmente a livello di astrazione. Queste sono le persone che "creano" i modelli di progettazione.

Come la classe Peopleware che parla dell'assunzione di un giocoliere senza chiedere loro di destreggiarsi - solo perché dicono che non possono significare molto ... provali.

Come già detto, credo anche che sia OK se non ricordano le parole d'ordine a memoria. Ma poiché si tratta di una posizione senior, 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 modello (ad esempio, come creare un oggetto senza codificare a fondo la sua classe, come accedere agli elementi di un oggetto senza avere dettagli sulla sua implementazione, ecc.) E vedere come lo attaccheranno.

Sicuramente dovrebbero conoscere gli schemi, ma non necessariamente le parole d'ordine.

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

Molto semplicemente: se li stai usando, devi chiedere ai tuoi candidati. Se conoscono schemi, allora dovrebbe aggiungere qualche punto in più; ma non sapere non dovrebbe necessariamente eliminarli, specialmente se mostrano buone capacità di OOD. È improbabile che gli sviluppatori che hanno partecipato a progetti di manutenzione conoscano molto i modelli di progettazione rispetto a quelli che hanno partecipato alla loro progettazione. dipende anche se è stato insegnato loro a progettare 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 lo richiedesse anch'io. Anche allora ho scoperto di aver usato alcuni dei modelli, almeno in modo simile se non nell'esatto modo descritto nel libro. Sono stato sorpreso di sapere che erano codificati. Quindi cerca buone capacità di progettazione se non conoscono DP. Se conoscono DP è probabile che siano bravi nel design ma comunque li testino. Potrebbero aver appena parlato di DP o scoperto da alcuni addetti ai lavori e aver appena studiato alcuni schemi senza averli applicati.

È ragionevole aspettarsi che le persone che fanno domanda per un lavoro con te sappiano (o imparino) le cose che sono necessarie nel tuo spazio di lavoro, indipendentemente dal fatto che siano standard del settore o meno. Altrimenti ti condanni alla mediocrità. Ma attenzione a rendere alcune conoscenze (o abilità) un requisito di lavoro, se non è realmente necessario.

Supponiamo che tu abbia due candidati con sfondi più o meno simili e uno è in grado di parlarti di modelli di design, e l'altro no. Cosa ti dirà su come si esibiranno sul posto di lavoro?

Dici che il software esistente utilizza modelli 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é?

Mi viene in mente uno sviluppatore senior che non conosce i modelli di progettazione nella seguente situazione:

1. C'è 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 conoscano i modelli di progettazione o che possano averne sentito parlare, ma non sanno bene a cosa servono
2. Invece, dovrebbero sapere qualcosa come uml ....
3. Trovare buone informazioni sui modelli di progettazione da Internet non è facile. Sei molto fortunato se raggiungi la pagina web corretta che ha una buona conoscenza dei modelli di progettazione. Il semplice fatto di venire a conoscenza del software dopo il 1995 potrebbe indurre una persona a non conoscere il libro sui 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 facendo solo Cobol, solo PL / SQL, solo Progress 4GL, ecc. I principi di progettazione OO sono irrilevanti lì, mi aspetto che gli anziani in quegli ambienti abbiano conoscenze pertinenti a quegli ambienti, non alla progettazione OO modelli.

Essere in grado di citare inconsapevolmente da un catalogo di modelli non ti rende un buon sviluppatore (in effetti, nella mia esperienza, produce alcuni dei peggiori pezzi di codice che abbia mai visto). Eppure è quello che ti aspetti di essere il marchio di "sviluppatore senior". Lavoro nel settore da 15 anni, ma non chiedermi di disegnare uno schema. Non ci ho mai dato molto tempo, non ne ho bisogno. Ho acquisito abbastanza esperienza per trovare ciò che funziona senza assegnargli un nome specifico e, se ho bisogno della definizione formale, so dove cercarla (e sì, ho i libri di riferimento nella mia biblioteca personale). Questo è il segno dello sviluppatore esperto, non della conoscenza acquisita acquisendo alcuni libri di scuola.