Come posso eliminare rapidamente i programmatori "copia e incolla"? [chiuso]

15

Chiuso. Questa domanda è fuori tema . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che sia in argomento per Software Engineering Stack Exchange.

Chiuso 4 anni fa .

Ho bisogno di un modo per filtrare i curriculum di persone che semplicemente copiano e incollano il codice, quindi sperano che funzioni, e controllalo se funziona. Tutto ciò accade senza avere una comprensione (o cura) per comprendere il resto del codice nel sistema.

Certo, so che copiare e incollare il codice fa parte dell'apprendimento di un nuovo oggetto, controllo, ecc ... ma come si può sapere se questo rappresenta il 70% (o più) della loro carriera di sviluppo?

Ho incontrato alcuni ragazzi di livello senior, forse le cui abilità sono così obsolete o irrilevanti per il progetto, che tutto ciò che fanno è google, copia e incolla del codice senza pensare alla soluzione nel suo insieme. Di conseguenza abbiamo un miscuglio di JSON, AJAX, callback, ASMX, WCF e postback nello stesso progetto. È chiaro che non c'è coerenza o logica dietro dove viene utilizzata ogni tecnologia.

Nel peggiore dei casi, questo tipo di sviluppatore crea problemi di sicurezza e vettori di attacco.

Domanda

Come consiglieresti di filtrare le persone con un background di programmazione scadente? Posso farlo a livello di curriculum? In caso contrario, come posso farlo durante l'intervista.

code-quality management skills

— goodguys_activate
fonte

Sembra che tu abbia bisogno di un architetto tecnologico per il tuo progetto. Qualcuno deve stabilire la legge WRT secondo gli standard utilizzati, le tecnologie utilizzate e allontanarla dall'idea-pet-della-settimana.

— quick_now

47

Ho incontrato alcuni ragazzi di livello senior, forse le cui abilità sono così obsolete o irrilevanti per il progetto, che tutto ciò che fanno è google, copia e incolla del codice senza pensare alla soluzione nel suo insieme. Di conseguenza abbiamo un miscuglio di JSON, AJAX, callback, ASMX, WCF e postback nello stesso progetto. È chiaro che non c'è coerenza o logica dietro dove viene utilizzata ogni tecnologia.

Non credo che il problema siano le competenze dei tuoi sviluppatori. Il tuo problema risiede altrove, forse un caposquadra o un architetto che non ha la fiducia in se stessi per "incoraggiare" migliori discipline di codifica, o un team di gestione che non capisce l'importanza della gestione del debito tecnico e non dà loro gli sviluppatori il tempo e le risorse per farlo. La tua azienda detiene recensioni di codice?

La leadership potrebbe essere il problema, non gli sviluppatori di copia-incolla.

— Robert Harvey
fonte

16

+1 Leadership may be the problem, not copy-paste developers. Questa era precisamente la mia interpretazione.

— George Marian,

Sul serio. Qualcosa è gravemente AWOL nel dipartimento di comunicazione.

— MIA,

+1: Idem sui commenti di George Marian. Molto ben detto, Robert.

— Jim G.

è buono. Spero che raggiunga tanto quanto gli intervistatori, reclutando manager.

— Saar,

sembra esserci molto consenso su questa risposta, ma non ragazzi di livello "senior" dettano la funzionalità e quindi l'implementazione è lasciata ai programmatori, giusto? Voglio dire, il ragazzo di livello senior potrebbe dire "Ehi, non usare un'orda di tecnologie, basta usare <questi due>", ma gli sviluppatori di copia incolla faranno copia incolla! Ho sbagliato ?

— Chani,

13

Il modo per eliminare i programmatori che non possono programmare è di metterli in una pratica esercitazione di programmazione come parte della fase di screening o di intervista. (Quest'ultimo è probabilmente migliore perché puoi controllare l'ambiente per evitare imbrogli.)

Ma non penso che risolverà davvero il tuo problema.

... abbiamo un miscuglio di JSON, AJAX, callback, ASMX, WCF e postback nello stesso progetto. È chiaro che non c'è coerenza o logica dietro dove viene utilizzata ogni tecnologia.

IMO, il vero problema qui è che la tua squadra non sta facendo abbastanza revisione del codice interno e non sta sviluppando un "libro di gioco" di soluzioni preferite a problemi noti. Questo è in parte un problema di cultura, in parte un problema di comunicazione e (probabilmente) in parte un problema con le scadenze del progetto.

Un altro problema è che il progetto ha in genere una lunga durata, e durante quella durata, appariranno nuove tecnologie / tecniche e quelle vecchie potrebbero cadere in disgrazia. Se si desidera evitare un uso "tecnologico della prima colazione dei cani" di tecnologie / tecniche, è necessario:

impostare e applicare un elenco di tecnologie / tecniche che possono essere utilizzate per progetto, o
investire gli sforzi per aggiornare le tecnologie utilizzate da un progetto.

— Stephen C
fonte

1

Se durante l'intervista non fai una prova scritta, potresti spararti al piede. Li ho avuti nei miei ultimi quattro datori di lavoro e spesso sono rimasto sorpreso da quanto fossero semplici alcune delle domande. Ad un certo punto, mi è stato detto che un altro candidato è partito senza completare il test, piangendo.

— Adrian J. Moreno,

1

Sono assolutamente d'accordo che una prova scritta durante l'intervista è l'unico modo per essere sicuri che le tue reclute abbiano davvero buone capacità di programmazione. Ma il principale obiettivo della mia risposta è che le competenze degli sviluppatori da sole non sono sufficienti per affrontare il problema della SO.

— Stephen C,

Sono stato catturato dal timer di modifica. Concordo pienamente sulla necessità di standard e revisioni. Di recente abbiamo pubblicato un nuovo documento sugli standard di codifica e combinato con alcuni nuovi processi di revisione del codice, abbiamo riscontrato che molti meno bug arrivano al QA. Uno se il mio prossimo obiettivo è quello di creare un team di allenamento interno.

— Adrian J. Moreno,

10

Assumi persone in libertà vigilata per 3 mesi. Licenziali se fanno schifo.

Se non ISPEZIONA non puoi ASPETTARE. Revisioni del codice, strumenti di controllo. Un server CI può eseguirli automaticamente.

Poni domande reali nelle tue interviste, come in domande dal codice reale.

Fagli scrivere il codice sulla lavagna.

Se sei un manager non tecnico, non sei qualificato per giudicare questo.

Se non sei qualificato, chiedi a un consulente professionista senior affidabile di eseguire i test. Chiedi alle persone esistenti e ai concorrenti aziendali se conoscono una persona produttiva 100 volte. Pagali per fare il colloquio.

Se vuoi gestire un ospedale senza un capo di chirurgia, vai avanti.

— Tim Williscroft
fonte

stai parlando di uno esperto? Perché uno dovrebbe lasciare il suo lavoro e unirsi a un posto in cui hanno bisogno di 3 mesi per lasciarli succhiare o no :) Perché ci sono risorse umane?

— Saar,

Sto parlando di persone esperte e competenti. Sono più economici a lungo termine. Le risorse umane ti impediscono di essere denunciato per violazione del diritto del lavoro. Originariamente lì per fare cose permalose per i gestori numerici di Henry Ford. Storia vera, cercala. Se sai già che la persona si allenerà bene, beh, sei meglio di me. La persona cambierà lavoro perché sei così bravo a lavorare, c'è un ottimo ambiente di lavoro e dopo la libertà vigilata ottengono un grosso bonus. Se vengono licenziati come permanenti, la tua azienda paga altri tre mesi. Qualcosa del genere

— Tim Williscroft il

9

Ho trascorso gli ultimi anni a intervistare persone e scoprire che il 90% dei candidati semplicemente non è in grado di programmare. La mia tecnica di intervista per determinare la programmazione è di dare al candidato un brief troppo semplice e lasciare che il candidato lo risolva usando un pennarello e una lavagna.

Le modalità di errore includono:

escogitare un design e quindi implementare qualcosa di diverso. Questi candidati vengono respinti perché pericolosi per una squadra. non seguire le specifiche, scrivere bug ecc ...

Non essere in grado di inventare un design. Un numero sorprendente di candidati "esperti" ha bisogno di una specifica per includere la progettazione dell'implementazione.

non conoscere il linguaggio di programmazione, nonostante l'esperienza di rivendicazione di CV.

Non porre ulteriori domande per estrarre specifiche più complete.

Non essere in grado di spiegare le decisioni di progettazione. Questo è importante. Se qualcuno non può spiegare il perché, allora ogni volta lo farà in modo diverso e la coerenza viene persa.

Il risultato finale è stato che ho trascorso molto tempo a intervistare e non a reclutare molto spesso. tuttavia, il team di sviluppo è stato molto bravo e ha avuto il pieno rispetto di tutta l'azienda e ha prodotto risultati!

— Michael Shaw
fonte

La tua esperienza sembra abbastanza normale.

— quick_now

5

Suggerirei FizzBuzz che Jeff Atwood menziona nel post all'indirizzo http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html .

Scrivi un programma che stampa i numeri da 1 a 100. Ma per multipli di tre stampa "Fizz" invece del numero e per multipli di cinque stampa "Buzz". Per i numeri multipli di tre e cinque stampare "FizzBuzz".

— Jetti
fonte

9

-1. FizzBuzz rileva gli idioti totali. Per copiare e incollare i codici, non puoi essere un totale idiota.

— back2dos

@ back2dos - Dovresti già eliminare gli "idioti totali" quando arrivi a un'intervista faccia a faccia. FizzBuzz fa riflettere qualcuno sul problema e su come risolverlo al meglio. Non è difficile, quindi dovrebbe esporre coloro che copiano e incollano, poiché quelli che copiano e incollano non imparano il "perché" dietro le cose.

— Jetti,

3

+1. FizzBuzz rileva più di un totale idiota. Rileva anche le persone che compensano la mancanza di competenze tecniche con abilità sociali superiori alla media. Quelle persone hanno buone probabilità di superare un primo test di screening. Ad esempio, possono benissimo avere titoli legittimi.

— MSalters il

1

Bene, mi chiedi fizzbuzz e me ne vado immediatamente. :) L'IMO nella categoria junior non è davvero utile, in quanto allenerai comunque i ragazzi, e nella categoria senior è inutile + offensivo. dovresti essere in grado di far diventare alte le persone intelligenti + che ottengono risultati con altri mezzi. La codifica su domande simili a spot è un'indicazione dell'IME delle aziende agricole donnole. Se in realtà sono interessato alle abilità di programmazione di qualcuno, faccio una domanda di revisione del codice . E ottieni tutte le risposte pertinenti senza frustrazione.

— Balog Pal

@BalogPal: Riderei e inizierei a scrivere come un matto per due minuti, e poi mi vergognerei di me stesso se non si compila, non corro e non funzioni la prima volta.

— gnasher729,

2

Faccio tre domande per l'intervista

Scrivi un elenco collegato in grado di memorizzare alcuni tipi numerici in Java senza importare nulla dal framework delle raccolte
Scrivi il codice che mostra come aggiungere / rimuovere nodi da quell'elenco
Scrivi il codice che mostra come ottenere il massimo / minimo da quell'elenco

Ho visto persone completare questo in 5 minuti e ho visto persone che lottano per 30 minuti prima di arrendersi.

— sal
fonte

Il primo requisito dovrebbe essere più specifico. java.util.LinkedList l = new java.util.LinkedList()non importa nulla, ma sicuramente utilizza le raccolte integrate.

— Barry Brown,

Questa è una domanda giusta soprattutto per i neolaureati. Se hai prestato attenzione o hai trascorso del tempo a programmare, questo dovrebbe essere quasi banale. Presumo che non debba essere esatto, ma abbastanza vicino.

— Bryan Harrington,

3

@Bryan, nessuno ci ha ancora provato. E davvero non mi interessa se la risposta è corretta al 100%. Solo che comprendono il problema e sono in grado di affrontarlo in modo competente. Il problema più comune è quello in cui aggiungere / rimuovere non funzionerebbe in testa o in coda alla lista. Ho raccomandato alle persone di essere assunte in base alla loro reazione a me sottolineandolo.

— sal

2

Non puoi farlo a livello di curriculum in quanto hanno essenzialmente un tempo infinito per scriverlo, ma puoi farlo su un'intervista telefonica se fai alcune domande che richiedono approfondimenti tecnici in quello che fanno. Questo ti dà sia la risposta (buona o cattiva) che il tempo impiegato per arrivarci.

Durante un'intervista, fagli scrivere codice. È l'unico modo per sapere se possono programmare davvero. Semplifica il problema, dai loro un computer con una connessione a Internet e l'IDE che usi installato, lascia che facciano qualsiasi domanda (tranne gimme-hte-codez) e guarda come funzionano.

EDIT: per l'analisi post mortem sembra che PMD abbia un rilevatore copia / incolla per trovarlo: http://pmd.sourceforge.net/cpd.html

Ho accettato con te fino a "... e l'IDE che usi." I programmatori sono particolarmente attenti ai nostri ambienti di lavoro e probabilmente non conosceranno $ random-IDE. Scrivo codice da oltre 20 anni e sprecherei i primi 10 minuti cercando di capire come lavorare un IDE se me ne lanciassi uno. Uso un editor (bluefish quando faccio cose webby, emacs per tutto il resto) e strumenti da riga di comando per tutto il resto (controllo di revisione, compilazione quando necessario, ecc.). Non uso affatto debugger. Mi è stato insegnato che se hai bisogno di un debugger stai sbagliando: questo è il codice di debug!

— HedgeMage,

@HedgeMage, non ho detto che dovevano usarlo ... Vedere come una persona gestisce quella situazione è molto significativo. Notepad + javac sarà sufficiente? Scarica e installa NetBeans? Chiederà come fare X nel tuo IDE, hackerare un po 'e chiedere Y e Z?

@HedgeMage, il codice di debug è ottimo se riesci a determinare in anticipo tutte le possibili cose che potresti aver bisogno di sapere. I debugger sono utili nei casi in cui è necessario visualizzare le risposte alle domande per determinare la domanda successiva, che con il codice di debug richiede un nuovo binario e il riavvio e tornare nuovamente alla posizione.

1

@ Thorbjørn: Concesso, le mie bollette sono state pagate con il lavoro in lingue interpretate negli ultimi anni, ma anche nei miei giorni in codice C, ho respinto il debugger in favore di un buon codice di debug. Forse è solo un pregiudizio da parte mia: sono andato al college con un sacco di persone che non hanno mai imparato a programmare di per sé - hanno semplicemente schiaffeggiato qualcosa e poi riparato tutto ciò di cui il debugger ha urlato finché non ha "funzionato". Non sopporto quel tipo di codifica slipshod. Non intendevo implicare che i debugger fossero malvagi, ma solo che loro e le altre funzionalità IDE non appartenevano a tutti i flussi di lavoro.

— HedgeMage,

@HedgeMage, sono d'accordo sul fatto che l'approccio "batti fino a quando funziona" per il debug non è buono, ma concludere che i debugger sono cattivi è forse un'aconclusione un po 'troppo ampia.

1

Semplice

(1) Chiudili in una stanza + Free Oxygen.
(2) Offri loro un PC con connessione Internet + IDE di scelta + accesso a Food.
(3) Avere WireShark o un metodo simile per registrare tutto il traffico in entrata e in uscita.
(4) Dagli un incarico medio.
(5) Esaminare tutto il traffico HTTP, completare il completamento dell'assegnazione.
(6) Se il soggetto ha copiato grossi blocchi di codice sorgente, termina il soggetto .....

Modificare:

Come indicato da makerofthings7, in termini pratici si potrebbe fare una cattura video (cattura schermo).

— Notte oscura
fonte

Romanzo, ma alla fine poco pratico.

— Robert Harvey,

... o semplicemente fare una cattura video, vedere la progressione della logica. Guarda svolgersi la bellezza (o il caos).

— goodguys_activate il

1

terminare Oggetto? Ritirando l'ossigeno libero? Disordinato!

@ Thorbjørn: non così disordinato come se si sparassero sul piede, dopo aver copiato grossi pezzi di codice sorgente.

— Joe D,

1

Coloro che non riescono a utilizzare Internet a proprio vantaggio sono bloccati nelle modalità di ieri. Suppongo SEMPRE che ci siano alcuni buoni esempi là fuori per me da guardare, non importa quanto sia banale la domanda. Non copio e incollo, guardo buoni esempi e applico la migliore tecnica. Sono un programmatore full-stack, il che significa che sono un generalista e non uno specialista e faccio affidamento sul resto del mondo. Chiaramente peccaminoso!

— junky

1

Se vuoi "estirpare" programmatori scadenti puoi provare ad esempio la matrice di competenza del programmatore (utile ma piuttosto non si applica a tutte le aree possibili - ovviamente puoi crearla) o codility.com (i compiti sono molto buoni e fa risparmiare molto tempo).

Generalmente, assumere buoni programmatori è difficile e spesso richiede molti anni di pratica. Puoi avviare il tuo database di domande per le interviste, non solo chiedendo informazioni sulla programmazione, ma anche con matematica, logica, per non parlare delle domande di motivazione.

— Wojciech Sroczyński
fonte

0

Direi che il problema con i tuoi candidati non è che non possono programmare affatto, ma che non hanno la sensazione di usare lo strumento giusto per il lavoro. Il mio suggerimento è una domanda di saggio in cui verrebbero richiesti requisiti di alto livello per un nuovo sistema e cui sarebbe stato chiesto di fornire un'architettura e giustificare le loro scelte componenti. Ma conserva FizzBuzz per i candidati che non possono codificare affatto senza un browser.

— Larry Coleman
fonte