Le abilità di debug sono importanti per diventare un buon programmatore?

Insieme alle altre qualità un programmatore dovrebbe avere bisogno di buone capacità di debug? Se ho un candidato che non è stato in grado di trovare l'errore nel programma dato, ma è stato in grado di risolvere tutti i puzzle e i programmi, dovrei considerarlo per il lavoro?

EDIT: - I puzzle sono normali palle rosse, blu e rosso-blu come. I programmi sono come trovare zeri continui in un array. Il programma di debug è qualcosa che fallisce a causa della condizione che dovrebbe essere> =, ma invece è>. Tutto è sulla carta.

Sì, è molto importante

A proposito di quel particolare candidato, è possibile che non abbia abbastanza familiarità con la base di codice x per eseguire il debug.

Un buon risolutore di problemi dovrebbe essere in grado di eseguire il debug, in quanto tutto ciò che di solito è necessario è avere un metodo / approccio molto logico.

Se non riesci a eseguire il debug non sei praticamente un programmatore, per non parlare di un buon programmatore.

Il debug è un'applicazione reale e pratica non solo delle capacità tecniche ma anche delle capacità di analisi e dei processi di pensiero. Di conseguenza lo classificherei come un test molto più utile e pertinente rispetto alla lavagna o alle domande di intervista.

A meno che il lavoro che svolgi non implichi il passare tutto il giorno a rispondere alle domande della teoria, hai bisogno di qualcuno che possa applicare qualunque abilità abbia.

Quello che devi fare, però, è chiederti se è stato un giusto test di capacità di debug: potrebbero eseguire il codice, mettere in break points e così via come farebbero nel mondo reale? Che tipo di errore è stato? È qualcosa che il compilatore avrebbe raccolto e contrassegnato (nel qual caso è una domanda piuttosto inutile in quanto non avrebbero mai dovuto individuarlo)?

Se è stato appena scritto su carta, in pratica è solo un test di lettura dettagliato e questa è un'abilità ancora più astratta della tua normale domanda di intervista tecnica e direi, praticamente senza valore.

Principale regola di assunzione - in ogni caso dire di no.

Se hai bisogno di implementare un sacco di nuovo codice a buon mercato, puoi procurartelo, ma personalmente continuerei a cercare.

A meno che lo sviluppatore non sia in grado di scrivere codice pulito tutto il tempo (assolutamente impossibile) e di lavorare solo su progetti "green field" (non sarà mai il caso), quindi sì, le competenze di debug sono assolutamente essenziali. Assolutamente. Ho avuto esperienza con gli sviluppatori a cui non piaceva eseguire il debug, quindi sono diventati pigri e hanno lanciato codice sul muro per il controllo qualità per farli testare. Ma quegli sviluppatori non durano molto a lungo.

Lo sviluppo del software è un'abilità e una capacità di problem solving. Tali problemi comprendono sia i problemi aziendali, sia i problemi con il loro (e altri) codice. A proposito, molti progetti di manutenzione riguardano specificamente la correzione di bug, quindi il debug è un'abilità assolutamente essenziale.

Tengo a mente che ci sono molti siti web di tipo "intervista" ed è del tutto possibile studiare per molte domande e puzzle. Una cosa per cui non puoi studiare è il codice di debug che non hai mai visto prima. O hai scritto abbastanza codice da sapere come eseguire il debug o no. Se si tratta di una posizione entry-level, non escluderei il candidato, ma se affermano di avere esperienza con la lingua e non riescono a eseguire il debug del codice in essa, sicuramente alza una bandiera rossa.

La principale differenza che ho visto tra programmatori junior e programmatori senior è la loro abilità nel debug. L'abilità nel debug è qualcosa che viene solo con la pratica e l'esperienza.

Ad esempio, pensa a uno strano bug in cui un programma Java funziona correttamente sulla console in modalità interattiva, ma non riesce quando si tenta di utilizzare una pipe Unix per lo stesso input. Se hai riscontrato questo problema in precedenza, potresti verificare che new Scanner(System.in)venga chiamato solo una volta; il bug è che consuma il buffer quando viene reindirizzato, ma ovviamente non in modalità interattiva. Mi aspetterei che un programmatore più anziano identifichi più rapidamente questo errore. Forse perché l'hanno già sperimentato prima o perché in passato hanno avuto altri problemi con il buffering.

Per quanto riguarda la risoluzione di enigmi e la scrittura di nuovo codice, mentre l'esperienza è importante, questo è qualcosa in cui un programmatore di livello junior può forse esibirsi proprio come, o anche meglio di, un programmatore più senior. Cioè, l'intelligenza e l'abilità possono avere un effetto maggiore, indipendentemente dall'esperienza.

Se sei in grado di investire in un programmatore junior, che può avere nuove idee e può aiutare il team a "gelare", e sembra che stiano bene scrivendo un nuovo codice, vai avanti e assumili. Se stai cercando un programmatore di livello senior, questa mancanza di abilità di debug può essere un segnale di avvertimento importante: potrebbero avere un'esperienza di dieci anni che equivale a sperimentare il primo anno dieci volte.

Come nota a margine, ci sono modi per migliorare il debug senza prima avere 10 anni di esperienza. Raccomando il libro di Andres Zeller Perché i programmi falliscono: una guida al debugging sistematico come un modo per apprendere i principi scientifici e capire meglio come riprodurre, trovare e correggere i guasti.

Dipende dal tuo ambiente. Se giochi a sodoku e altri puzzle tutto il giorno, forse sarebbe un buon candidato.

Se tuttavia, a volte hai dei bug nel tuo codice, o non funziona sempre esattamente come previsto, ti suggerisco di ottenere qualcuno bravo nella risoluzione dei problemi.

Assumi ciò di cui hai bisogno, non l'ideale di ciò che dovrebbe essere un programmatore.

Insieme alle altre qualità un programmatore dovrebbe avere bisogno di buone capacità di debug?

Sì.

Il debug del codice fa parte della risoluzione dei problemi. Non ho mai incontrato uno sviluppatore che ha scritto codice perfetto e zero bug. Uno sviluppatore eseguirà il debug del suo codice o di qualcun altro. È una necessità.

dovrei considerarlo per il lavoro?

Forse dipende.

Non essere in grado di eseguire il debug di un programma in un'intervista probabilmente non dovrebbe essere un rompicapo se il richiedente è stato in grado di completare tutti gli altri enigmi e programmi nell'intervista. Dipende molto dalla profondità e dal respiro dell'intervista.

Quanto debug comporta la posizione? Se molto, allora forse più peso dovrebbe essere messo nel modo in cui un richiedente può rispondere alla domanda di debug. Ma dal momento che hai detto solo che è stata posta una domanda di debug, non sembra che sia così.

un programmatore dovrebbe avere buone capacità di debug?

Sì. Detto questo, ti chiederei di considerare la metodologia nell'intervista (cioè quiz / test-style) meno che perfetta (ok, imperfetta) in quanto molte persone trovano il codice su carta un'esperienza strana e non familiare.

Poiché il debug è un processo , non la risposta o il risultato (ad esempio l'errore ), suggerirei di utilizzare un dialogo o una discussione interattivi come mezzo migliore per valutare le capacità di debug dei candidati. Mentre la maggior parte delle persone utilizza un sistema informale di debug ad hoc, i buoni candidati avranno un modello simile in generale, di porre domande per comprendere il sistema, i presupposti e i requisiti, quindi isolare il problema (spesso dividere e conquistare) e confrontare metodicamente il codice delle esigenze, e valuta prevede input / output, piuttosto che una voglia o no cambiare un sacco di cose contemporaneamente casaccio finché non funziona.

Esprimo anche riserve sui problemi di puzzle durante le interviste, in particolare in forma scritta, come se il candidato non avesse le giuste ipotesi di quadro di riferimento (il trucco), il puzzle potrebbe essere irrisolvibile per loro. Vale a dire Molti puzzle di interviste soffrono di avere un unico percorso corretto, mentre la vita è complicata e i pensieri più creativi sono quelli che adottano approcci sorprendentemente nuovi per risolvere un problema che potrebbe non funzionare con un determinato puzzle precotto, con una soluzione prevista . È come aspettarsi che tutti i trombettisti suonino jazz. Questo può essere gestito ponendo la domanda come discussione interattiva non conflittuale (la pressione può confondere la creatività). Ancora una volta, per me, la risposta è secondaria nel vedere un buon processo di pensiero espresso. Probabilmente dovrai chiedere loro di pensare ad alta voce, ma questo tende ad essere più produttivo nella mia esperienza.

Non ho letto o valutato il motivo per cui i programmi di Zeller falliscono , ma posso consigliare il debug di Agans come una lettura breve e veloce che può aiutare a consolidare il processo di debug ad hoc in uno sforzo più strutturato, concreto e organizzato, che può aiutare a essere più efficiente nel debug. Stampa anche una copia e appendila al tuo cubicolo o soluzione alternativa, il poster delle regole di debug , è un promemoria perfetto per quei brutti giorni in cui nulla sembra andare per il verso giusto. Ho pochi brutti giorni e dedico meno tempo al debug attivo (leggi: grattarmi la testa in confusione ) cercando di seguirli nello spirito se non nella lettera.

Direi che il debug è essenziale, a meno che il programmatore non sia così bravo da non commettere errori. Non sono convinto che sia impossibile, ma non riesco a immaginarlo con le lingue e gli strumenti popolari attuali.

Non mi piace l'idea di essere messo sul posto in quel modo in un'intervista. Se il candidato è nervoso (e chi non lo è), potrebbe tracciare un luogo vuoto come programmatore che potrebbe essere in grado di gestire sistematicamente tali problemi. Quindi, se si trattasse di un noto colloquio o di un problema con il test di scienze scientifiche, il candidato potrebbe conoscere il risultato a memoria, ma non avere la capacità di pensare a un nuovo problema. Inoltre, se il candidato non ha familiarità con la lingua, dovrà lottare. Molti bug sono difficili perché un buon programmatore sa cosa intendeva scrivere e il suo cervello prende scorciatoie durante la lettura del codice. Non riesco a trovare l'uso in stile C di = dove == avrebbe dovuto essere usato dall'ispezione, perché so quale fosse l'intento e il mio cervello prenderà una scorciatoia per l'analisi leggendolo.

Una buona parte della programmazione della risoluzione dei problemi e per risolvere un problema devi conoscere il problema principale non solo i sintomi o le incoerenze. Il debug è l'arte di identificare il problema principale.

• identificare il problema principale
• meglio in grado di visualizzare il flusso

e molti altri.

Aggiungerei un po 'di più alla situazione nel sottolineare l'errore e vedere quale reazione ha la persona. Sono eccessivamente drammatici per il tipo "D'oh! Sono un idiota, che era così stupido ...", eccessivamente apatico nel campo "Sì, qualunque ragazzo" o c'era un ascolto attivo su ciò che era sbagliato con qualche tipo di scusa o osservazione per indicare che ottengono che hanno incasinato qualcosa che avrebbero dovuto risolvere? Solo qualcosa a cui pensare nelle situazioni future.

Debug in modo tempestivo è una grande abilità. Questo è un po 'diverso dal dare a qualcuno un problema in cui viene risolto quando viene risolto. A volte devono essere adottate misure aggressive per salvare il sistema, il che dovrebbe essere riconosciuto poiché immagino che la maggior parte delle aziende non vorrebbe che le vendite venissero interrotte per settimane mentre qualcuno corregge un bug nel software di contabilità che l'azienda utilizza.

Il debug è un'abilità fondamentale. In realtà, direi di più che la risoluzione dei problemi è l'abilità critica. Qualcuno dovrebbe sapere come definire il problema (incluso quali informazioni utente chiedere e quali registri guardare), come riprodurlo, quali fonti di dati ha a disposizione per diagnosticare il problema e come eseguire il debug e come risolvere una cosa senza rompere qualcos'altro. Tuttavia, determinare che durante un'intervista è difficile.

Gli darei un vero problema da trovare e l'opportunità di utilizzare gli strumenti disponibili e poi chiedere quali passi ha preso per trovare il problema o cos'altro potrebbe fare se non fosse stato in grado di trovare il problema nel tempo assegnato. Stai davvero cercando qualcuno che attacca il problema in modo un po 'sistematico e che abbia più strumenti nel suo toolkit oltre al debugger e a Google (tranne a livello Junior quando dovrebbe almeno provare entrambi (qualcuno che non riesce a pensare provare queste due cose probabilmente non è competente o almeno non ne avrei avuto la possibilità) ma probabilmente non ha ancora molti strumenti avanzati per la risoluzione dei problemi).

Darei più peso alle abilità di Troublshooting che alle risposte ai puzzle (beh, non lo chiederei affatto) o alle capacità di programmazione dimostrata. Raramente ho visto uno sviluppatore che può risolvere bene i problemi che non possono anche scrivere un buon codice o fare le correzioni necessarie. Ho visto molte persone che sono in grado di mettere insieme del codice per ottenere un prodotto "funzionante" ma non possono risolvere un problema se la loro vita dipendesse da questo. Principalmente perché non capiscono veramente cosa stanno facendo o capiscono il problema che stanno cercando di risolvere. I buoni cacciatori di truppe sanno come identificare il vero problema, non solo il sintomo. E loro sanno quali domande porre per definire il problema anche per i nuovi sviluppi.

Ci sono da 4 a 5 competenze chiave in ogni lavoro e la programmazione non è diversa. A livello professionale devi essere bravo in tutte le competenze fondamentali chiave. Se ne hai 4 su 5, ti trattengono comunque.

Riesci a immaginare un venditore in grado di presentare, convincere, articolare, qualificare i clienti, ma non può chiudere l'affare? Sono là fuori e non li vuoi nel tuo team di vendita.

Il debugging è sicuramente un'abilità fondamentale di cui un programmatore non può fare a meno.

Ho un tale stile di codifica, che richiede un debug di tipo miminale. Quando ho finito con 3 righe di codice, lo eseguo e lo collaudo, spesso stampando un paio di variabili. Nei casi, quando ho ottenuto risultati o comportamenti indesiderati, ho inserito molti dump nel mio codice, anziché eseguire il debug. Uso un debugger reale molto raro. Strano ma vero.

Il debug è la fase dello sviluppo del software che viene dopo che un determinato test è stato effettuato sul tuo software e che è stato scoperto un bug. È l'atto di cercare e correggere il bug nel tuo software. In molti casi, trovare il bug di solito richiede più tempo che risolverlo.

È il processo di rimozione dei bug (le vulnerabilità) inerenti all'applicazione / sistema del computer. Se ciò non viene fatto, gli hacker possono trarre vantaggio dai bug e possono svolgere una varietà di attività dannose:

1) Possono esporre la vulnerabilità al pubblico portando a una perdita di entrate, affari e reputazione per gli sviluppatori e i fornitori.

2) I worm cercano sistemi vulnerabili che possono sfruttare e quindi si copiano su quei server. per esempio. Nel gennaio 2003, il worm Slammer ha sfruttato la vulnerabilità in MS SQL Server.

3) Dove sono stati menzionati i worm come possiamo dimenticare i virus. I virus vengono anche persi dai loro sviluppatori che sfruttano i bug presenti nel programma allo scopo principale di un'esposizione indecente ...

4) E se i programmi non sono correttamente sottoposti a debug, i consumatori non manterranno mai abbastanza se non ottengono il valore del loro denaro. In quel caso non hai nemmeno bisogno di un hacker per fare il lavoro sporco, potresti anche fidarti del buon vecchio pubblico.