Intervista di programmazione: come eseguire il debug di un programma? [chiuso]

La risposta a una domanda così vaga non può mai essere completa.

Sembra una di quelle domande che sono state progettate per essere vaghe di proposito: penso che dovresti aver evitato eccessive cialde e chiesto loro di restringere il focus della domanda. Come hai detto, prima classifichi gli errori in sintassi e semantica, poi diramati la tua risposta da lì - ma dato che hai già pensato che volessero che discutessi entrambi in profondità, hai semplicemente continuato a parlare.

Sì, quello che hai detto va bene, ma qui nessuno sarà in grado di dirti se hai risposto alla domanda dell'intervista.

Personalmente, mi sarei avvicinato restituendo una domanda "perché il tipo di problema in C ++ sto eseguendo il debugging?" ( Segmentation Fault è molto diverso da Unexpected ... come sai, ma dovresti sempre chiarire le tue ipotesi in un'intervista) e portarlo da lì, una volta che la domanda è abbastanza ristretto che sarei in grado di rispondere con precisione e in gran parte nella sua interezza. Pensa in questo modo: immagina di averti appena detto "la mia macchina non funziona, puoi dirmi perché?". Inizieresti davvero a provare a rispondere con così poche informazioni?

Come intervistatore che fa spesso domande molto simili, forse posso far luce.

Prima di tutto, nelle interviste, ci sono spesso due tipi di domande: (1) dimostrare di sapere qualcosa (in pratica, queste hanno risposte "giuste" e "sbagliate" abbastanza chiare) e (2) schiudersi il tuo teschio e mostrami come funziona la tua mente (queste hanno molte più sfumature di grigio, e molte risposte molto diverse possono essere tutte buone). Cerco di assicurarmi che gli intervistati sappiano quando non cerco la risposta "giusta" e voglio solo sapere come pensano. Per me, questa domanda è nella seconda categoria.

Pensa, era la domanda "Come si fa il debug di un programma C ++?" oppure "Come si può eseguire il debug di un programma C ++?", perché la risposta che hai fornito era per la seconda domanda. In generale, nelle interviste vogliamo ascoltare il generale (cioè ci sono versioni di rilascio e debug del codice) e poi vogliamo sapere come lo ha usato tu (cioè, "sul progetto XYZ la classe Shroozlebob non si stava inizializzando correttamente, quindi ho caricato la versione di debug del codice nel debugger e ... "). Naturalmente, se avessi una risposta come la tua, avrei iniziato a chiedere degli esempi. Non mi aspetto che gli intervistati siano ben informati per il colloquio; Mi aspetto che siano programmatori esperti.

Per me, non esiste una risposta giusta a questa domanda, sebbene alcune risposte siano migliori di altre. Se mi hai dato la tua risposta, e ho chiesto degli esempi e non potresti fornirli, dovrei presumere che non hai una vera esperienza di debug. Ma se mi dai buoni esempi di ciò che hai menzionato, sarebbe una buona risposta.

Sono rispettosamente in disaccordo con @mh. Questa non è una domanda trabocchetto. Immagino che questo sia stato un tentativo di avviare una discussione sul debug e sul processo di sviluppo in generale.

La tua risposta è un buon punto di partenza, in particolare la parte relativa alle asserzioni e alle eccezioni. Ma avresti potuto scavare più a fondo. Scrivi test unitari? Se no, allora dovresti. L'errore è stato catturato da un test unitario? In caso contrario, è necessario aggiungere un nuovo test per questo. Usi un sistema di controllo della versione? (Anche in questo caso, dovresti.) Se è così, allora dovresti controllare il registro di commit recente per vedere quale modifica potrebbe aver causato il bug. Si consiglia di provare a riprodurre il bug nelle versioni precedenti per trovare il punto esatto nel tempo in cui è stato introdotto il bug.

Il tuo codice è pulito? (Vedi "Codice pulito" di Robert C. Martin). Se hai classi e funzioni ridotte con nomi descrittivi e uno scopo ovvio, allora potresti essere in grado di trovare il bug semplicemente osservando il codice. In caso contrario, potrebbe essere un buon momento per ridefinire la parte del codice in questione per renderla più chiara e meno soggetta a errori.

A proposito, dovresti letteralmente chiedere all'intervistatore quelle domande sul controllo della versione e sui test unitari. L'intervista riguarda tanto la valutazione da parte tua quanto la valutazione di te.

Direi che non è completo, ma certamente accettabile per una posizione junior. Lo strumento di debug più potente è quello di comprendere il codice e di essere in grado di ragionare correttamente su ciò che sta facendo rispetto a ciò che dovrebbe fare. Questo è tuttavia ambizioso, e non siamo tutti all'altezza. Finiamo sempre per il debug di codice che non abbiamo mai visto prima. Un debugger è perfetto per questo. Avrei anche parlato della creazione di un impianto di registrazione nelle applicazioni e della scrittura di una buona documentazione e di un codice chiaro. Sarebbe anche stato utile menzionare strumenti come Valgrind, systrace e gprof o gli equivalenti di Windows o Java.

C'è un caso che ti sei perso. Mentre il programma potrebbe non dare un errore, ci possono essere casi in cui un requisito è stato male interpretato e quindi il software deve essere modificato per riflettere questo. Il compilatore non genererà alcuna eccezione perché, per quanto riguarda il programma, non sta accadendo nulla di male.

Anche se comincerei anche con vari tipi di bug, tempo di compilazione, esecuzione e modifica dei requisiti, vorrei approfondire la questione di quale tipo di bug sto affrontando? Si tratta di un problema nel codice, nei dati o nell'infrastruttura? Ci sono più di pochi posti che potrebbero essere la fonte. Probabilmente aggiungerei che esaminerei i test scritti per il programma per vedere se questo era coperto da qualche parte o era mancato.

Questa mi sembra una domanda semi-trabocchetto, progettata per sorprenderti e intrappolarti nel dare una risposta eccessivamente complessa quando uno più semplice farebbe.

Scopri qual è il problema, prendi un caso di ripro, usa un debugger, un test di regressione una volta fatto; semplice come quello.

La tua risposta tocca gran parte di ciò in modo che sia accettabile.

Se fossi in questa domanda, sarei alla ricerca di una risposta di livello più alto. Un "bug" è un divario tra ciò che pensate che il programma stia facendo e ciò che effettivamente sta facendo. Uno strumento principale per trovare un bug è il metodo scientifico. Esegui esperimenti usando debugger, log, modifiche al codice, qualunque cosa fino a quando non puoi fare una teoria su cosa sta succedendo. Quindi prova quella teoria usando quanti più casi puoi, usando ancora tutti gli strumenti che hanno senso. Ripeti finché non riesci a smentire una teoria. Una volta che sai cosa sta succedendo, fai le modifiche e prova la tua correzione.

Quali strumenti sono coinvolti varia a seconda del bug e dell'ambiente. Ottenere una risposta di "un debugger" quando si chiede "come si trova a eseguire il debug di un programma?" mi mette alla larga. È come rispondere "usando un editor" quando viene chiesto come si scrive software. Un debugger è uno strumento e, come tutti gli strumenti del settore, varierà in termini di qualità e potrebbe anche non esistere. "Visual Studio" funziona solo se stai guardando un negozio Microsoft. Sarai paralizzato se il problema si manifesta solo in modalità di rilascio, su un dispositivo fisico che non consente gli allegati del debugger?

L'altra cosa che cercherò da intervistatore sono le domande sul problema che mostrano che hai una conoscenza su cosa cercare date determinate condizioni. Qual è il tuo approccio se il sistema si blocca in un'app con più thread? Qual è il tuo approccio quando hai un comportamento diverso nella modalità di rilascio e di debug? Qual è il tuo approccio quando hai un crash casuale che non può essere legato a una particolare riga di codice? Qual è il tuo approccio per tracciare una perdita di memoria?

Le risposte dovrebbero ovviamente menzionare gli strumenti in tutti questi casi, ma gli strumenti sono secondari rispetto al processo.

Non penso che questa domanda sia troppo vaga. Quando intervengo, adoro domande come questa, perché spesso possono tradursi in profonde conversazioni sul processo di ingegneria del software. Quando ciò accade, sai di avere la persona giusta. Non esiste una risposta "completa" o una risposta "giusta". Il punto non è quello di ottenere la domanda giusta, ma di utilizzare la domanda come un trampolino di lancio per mostrare le tue abilità. Come intervistatore, sono più interessato a darti queste opportunità di quanto io sappia che puoi risponderti con una risposta "corretta".