Sono un po 'inesperto della programmazione (meno di un anno) e recentemente mi sono scoraggiato, soprattutto dal non essere in grado di risolvere problemi con il mio codice (non dimenticando parentesi o problemi di sintassi ma più problemi basati sulla logica ).
Volevo solo sapere, è qualcosa che si dissiperà con la pratica e il tempo o peggiorerà solo quando i miei programmi diventeranno più complessi?
Mentre i programmatori esperti fanno meno errori dei principianti, tutti i programmatori commettono errori. Ho sentito dire che dal momento che il debugging è il processo di rimozione dei bug dal codice, in primo luogo scrivere il codice dovrebbe essere chiamato bugging, perché è il processo in cui vengono aggiunti i bug.
Come principiante, stai scrivendo piccoli programmi ora e commettendo errori che ti sembreranno elementari in un anno. Se hai qualche attitudine alla programmazione, imparerai presto a non fare più quegli errori, almeno non se hai abbastanza caffè. Questo ti permetterà di scrivere programmi più grandi e più complicati .... e nel processo, farai una serie di errori più grandi e più complicati. Questo continuerà, se inserisci la professione, per tutta la tua carriera.
È possibile, in teoria, dominare un dominio della programmazione e scrivere raramente bug in quel dominio, ma ci sono sempre cose nuove da imparare, quindi sarai sempre un principiante in qualcosa, e quindi scriverai sempre bug.
Ad esempio, ogni nuovo linguaggio di programmazione che apprendi ti dà una serie di modi unici per sparare a te stesso (e agli altri) nel piede, oltre ai modi con cui hai già familiarità. Quindi, quando hai bisogno di imparare una nuova lingua, imparerai che le prime cose che dovresti fare su Google sono <language-name> pitfalls e <language-name> best practices .
Solo una frazione relativamente piccola dello sviluppo del software, forse un terzo, riguarda effettivamente la scrittura del codice. Il resto (processo, strumenti, ecc.) È, in tutto o in parte, sulla prevenzione, la rilevazione, il recupero e la correzione degli errori commessi dai programmatori (e, per essere corretti, da parte di altri soggetti coinvolti nel processo di sviluppo). Queste sono abilità che dovresti coltivare, tanto quanto coltivare le strutture con un particolare linguaggio di programmazione.
Alla luce della tua modifica, poiché la domanda è più correlata a problemi di logica di base, la risposta è: Dipende in gran parte da te.
Umani che scrivono bug di scrittura del codice: questo è un dato di fatto. Tuttavia, ci sono molte cose che puoi fare per perfezionare il modo in cui scrivi il tuo codice al fine di ridurre drasticamente il numero di bug e rendere molto più facile trovare la fonte di bug quando appaiono. Puoi decidere se sei disposto a continuare ad arrancare o se preferisci utilizzare tecniche che renderanno il tuo codice meno soggetto a errori.
Se vuoi migliorare la qualità e la vulnerabilità del codice, ecco alcune idee:
Prenditi un momento per guardare al codice che hai scritto un anno fa. Se non ti vergogni e pensi: "Santa mucca, oggi potrei fare un lavoro migliore", significa che non stai imparando abbastanza.
Un'ultima cosa: non voglio scoraggiarti perché dubito che tu cada in questa categoria, ma va detto: il cervello di alcune persone non è fatto per la programmazione. Se scopri che non stai imparando, non stai migliorando continuamente e non ti stai divertendo, potrebbe essere meglio per tutti coloro che sono coinvolti se inizi a cercare un cambiamento di carriera.
Ma tutti scrivono bug. Non scoraggiarti solo perché continui a commettere errori. È normale.
Più complesso è il tuo codice, più complessi saranno i tuoi problemi: -)
Con l'esperienza smetterai di fare altri errori banali, e troverai facilmente quegli errori banali che fai ancora (e tutti dimenticano occasionalmente una coppia di parentesi).
Ma più è complesso il tuo codice, più complessi sono i tuoi bug. Inizierai a cercare problemi di sincronizzazione, interazioni con i driver, problemi di integrazione o di progettazione architettonica ... C'è sempre qualcosa da sistemare.
Un sacco di ottime risposte già qui. Volevo solo indicare una cosa: se sei nuovo di zecca, ovviamente stai facendo degli errori stupidi. Sei un principiante. Se stavi appena iniziando a imparare uno strumento musicale, oa giocare a baseball per la prima volta, o qualsiasi altra abilità, saresti piuttosto maldestro anche a quello. È una parte normale e atteso del processo di apprendimento e tutti la affrontano. Come dice la vecchia battuta, fai le cose per esperienza, e fai esperienza facendo cose sbagliate.
Per diventare veramente bravo a qualsiasi competenza generalmente è necessario circa dieci anni o 10.000 ore di pratica seria in cui sei spingersi costantemente per imparare e crescere. Se sei disposto a dedicare tempo e sforzi, uscirai dall'altra parte come un buon programmatore.
Penso che la differenza sia che in questi giorni gli strumenti di base sono liberamente disponibili a chiunque (praticamente tutti hanno un computer e una connessione Internet) e che poche ricerche su Google sono tutto ciò che serve per iniziare a scrivere molto codice semplice che non realizza nulla di utile. E 'l'equivalente morale di imparare a suonare "Hot Cross Buns" su un flauto, ma per farlo, devi davvero fare a modo tuo per ottenere un flauto, ottenere la musica e memorizzare un mucchio di posizioni delle dita per fare il gli appunti. Ma per la programmazione, hai già un computer, e tutto ciò di cui hai bisogno è scaricare un compilatore, copiare e incollare un codice scritto da qualcun altro e hai un programma funzionante! Nessuna reale comprensione richiesta! Quindi la gente pensa "Oh, wow, questa roba di programmazione è facile!" E quando incontrano il loro primo vero problema, non hanno idea di come risolverlo e si scoraggiano.
Quando ci si avvicina ad esso, la programmazione è in realtà solo due competenze di base: scomporre un grosso problema in problemi più piccoli ed esprimere correttamente piccoli problemi nella logica formale. Gran parte dell'esperienza acquisita nel rendere qualcuno un buon codificatore sta nell'apprendere a riconoscere e risolvere un'ampia varietà di piccoli problemi.
Oggi posso ottenere una richiesta per implementare una nuova funzione, la guardo e dico "OK, questo comporta l'ordinamento di una lista, questa parte è una mappatura associativa, ho bisogno di una ricorsione per questa parte qui, e la sua memorizzazione nel database richiederà due tabelle con una relazione di chiave esterna. " Sono tutte cose che ho imparato a fare nel corso degli anni e ho imparato a riconoscere quali tecniche sono appropriate per i vari tipi di problemi.
Se studi la codifica con uno sforzo consapevole per apprendere nuovi modi per abbattere i problemi in problemi più piccoli e nuove tecniche per risolvere diversi tipi di piccoli problemi, scoprirai che diventa più interessante e più gratificante. E scoprirai che i tuoi problemi con i problemi basati sulla logica scompaiono quando impari ad affrontarli. (Ma scoprirai anche che ti viene chiesto di risolvere i problemi più difficili, sarà sempre una sfida, e se non lo è, lo stai facendo male.):)
E quando ti imbatti in qualcosa che ti blocca, chiedi su StackOverflow. Ci sono migliaia di programmatori che hanno già inserito i loro dieci anni e poi alcuni, e siamo disposti ad aiutare e dare una mano, specialmente a coloro che sono seriamente interessati all'apprendimento.
Continuerai a commettere errori, sarà solo più difficile da trovare. Con una pratica sufficiente, smetterai rapidamente di fare errori semplici, ma gli errori logici e di progettazione che sono più difficili da trovare continueranno a crescere. Essenzialmente, smetterai di fare errori "vecchi", ma continuerai a fare "nuovi".
Chiunque non stia commettendo errori almeno una volta ogni tanto non sta sfidando se stesso, quindi è quasi certo che non stanno più imparando. In altre parole, stanno stagnando.
Man mano che acquisisci esperienza, i tuoi errori tendono a diventare più grandi e più complessi, soprattutto perché tu (almeno speriamo) affrontiamo problemi che sono più grandi e più complessi. Tu fai, tuttavia, (ancora una volta speriamo) impara a riconoscere i tuoi errori un po 'prima, e in generale impari a progettare (e codificare) per il fatto che farai degli errori, quindi impari a lasciare un po' più "scioltezza" nel codice, ciò rende un po 'più facile il recupero dagli errori.
Diverse risposte qui forniscono alcuni ottimi consigli e, credo, dissipano alcuni dei miti che i programmatori con esperienza sono sempre perfetti. Voglio solo aggiungere che è importante ricordare che alcune intere metodologie di sviluppo sono strutturate in modo specifico in modo da poter "fallire velocemente" .
Agile, ad esempio, non solo considera gli errori nei processi di pensiero e di esecuzione (tra le altre cose) ma in qualche modo li assume . Va bene fallire , è il punto; il passo successivo è capire cosa è andato storto e scorrere le correzioni velocemente, ma non c'è (o non dovrebbe esserlo) un'assunzione di perfezione fin da subito.
Ciò che è implicito in un processo iterativo è che impari dai tuoi errori per non farli di nuovo, o se li fai di nuovo, li fai in modo diverso e impari qualcosa di nuovo.
Dato che sei relativamente nuovo nel campo, ti suggerisco di preoccuparti meno di fare errori, perché ognuno fa - e preoccuparti di più di imparare da loro e non di ripeterli, mentre rafforzare la comprensione e l'uso delle migliori pratiche nel tempo.
Ottenere il codice per fare ciò che intendevi è la parte facile - ad un certo punto puoi costruire l'intero programma nella tua testa in una fantastica animazione prima ancora di aprire l'editor.
Capire le tue reali intenzioni è difficile. E oh sì, ho problemi con quello. Come qualsiasi altro essere umano, immagino. Di solito ci vogliono poche ore e / o una chat con un collega per capire se stai andando nella direzione sbagliata, ma a volte solo dopo poche settimane di duro lavoro dedicato puoi guardare il risultato e rendersi conto che il tutto funziona come previsto ... e fa schifo , è brutto e dovrebbe essere buttato via . E credimi, è molto più deprimente di qualsiasi errore non intenzionale che puoi eventualmente fare.
Quindi sì, peggiora. E, naturalmente, più l'obiettivo è astratto, più difficile è concepirne il percorso. Ecco perché non inizi mai un progetto senza una specifica molto dettagliata, anche se hai piena libertà.
Ecco come valuti se uno studente ha la possibilità di continuare nell'argomento; chiediti "ho fatto meno errori questo mese di quello che ho fatto il mese scorso?"
Se la risposta è sì, anche con un piccolo margine, allora sei a posto mentre sei, molto più avanti della curva. Se la tua risposta è che è più o meno la stessa quantità ma hai continuato ad affrontare quelli diversi, allora stai andando bene, perché mentre miglioravi, i problemi che stai affrontando diventano sempre più complessi a causa delle tue aspettative personali e dell'intrinseca la complessità del problema, che aumenta il numero di potenziali bug - molti dei quali già conoscerete già dalle esperienze precedenti e sapete come evitare - e il resto sono i bug che non avete imparato a "sentire". Infine, se pensi di continuare a ripetere gli stessi errori più e più volte, è ora di riconsiderare un'altra carriera.
Quando hai iniziato a imparare, non importa quanti bug hai creato, ciò che conta è che tu stia migliorando mentre stai imparando.
I programmatori esperti hanno problemi con i problemi e creano soluzioni. Nel corso del tempo, si ha una buona idea di quali sistemi posizionare e come risolveranno i problemi. Mentre andrai, scoprirai ogni sorta di limiti o dinamiche estetiche, legate al personale, legate alla piattaforma e alla lingua che rovinerebbero ciò che pensavi avrebbe funzionato alla grande. Alla fine avrai un'idea su alcune di queste cose e il premio è ... Progetti più sofisticati e ben pagati! Lato negativo: difficoltà; al rialzo - sii più padrone e crea soluzioni o prodotti più interessanti.
A volte vorrei che ogni programmatore con cui ho lavorato funzionasse per un po 'come bug tracker. Ho avuto il vantaggio (maledizione) di lavorare a un livello inferiore per alcuni anni con un'applicazione con importanti problemi di codice legacy.
Perché è rilevante? Perché lavorare sui problemi è spesso il modo migliore per comprendere i problemi.
Per lo più, mentre lavori e diventi più esperto, migliorerai la tua capacità di correlare sintomi apparenti con cause inaspettate. Sfortunatamente, così saranno i problemi più sofisticati nei sistemi più sofisticati.
Aspettati di imbatterti costantemente in situazioni che mettono alla prova la tua pazienza. Concentrati sulle buone pratiche, sui metodi altamente iterativi e concisi e costruisci da zero (non usare il codice di altre persone così tanto) per sviluppare buone abitudini. Inoltre, potresti trovarti a fare l'amore e pensare a come una variabile o un elemento di dati viene manipolato attraverso alcune applicazioni. Questo è il tuo sistema di debug in via di sviluppo, stai diventando un robot.
Per diventare davvero bravo, dovrai andare a fondo. Può essere davvero travolgente avere tonnellate di informazioni nel cervello mentre si tenta di eseguire il debug di qualcosa apparentemente senza fonte. Nel corso del tempo ho scoperto che i vantaggi della disponibilità a farlo sono ciò che separa il decente dall'eccezionale.
Ho programmato un tempo molto lungo, e ieri ho avuto l'esperienza di leggere un codice e il mio primo pensiero è che era troppo complesso per le mie capacità. È interessante notare che il codice era un algoritmo progettato e scritto da me due settimane fa. La ragione di questo paradosso è che ho potuto capire parti molto piccole dell'algoritmo, quel tanto che basta per portarmi al passo successivo, ma era troppo complesso per comprendere l'intera cosa in una volta.
Ciò che dovresti imparare da questo non è scoraggiarsi quando non capisci qualcosa. Scomponilo in pezzi sempre più piccoli finché non lo fai.
Un breve commento: farai sempre bug, ma alcuni di questi arrivano a rappresentare meno problemi nel tempo. Considera il seguente frammento di codice C:
int c;
scanf("%d", c);
Questa è una versione errata di
int c;
scanf("%d", &c);
e scanf nel secondo (corretto) paragrafo è dato l'indirizzo di c; nel primo viene assegnato il valore di c, si presuppone che sia l'indirizzo di c, e si blocca e brucia.
La prima volta che uno studente C fa questo, questo potrebbe facilmente essere il debug delle ore; il primo esempio si legge direttamente e ha senso (confrontarlo con un codice complesso in cui gli errori non saltano fuori). Ed è un'esperienza di ebollizione del sangue. Ma nel tempo, sviluppi una lista (forse inconscia) di "soliti sospetti", e se il debugger o le istruzioni di output localizzano il problema su un scanf, controllerai naturalmente che ogni variabile abbia o meno un & prima di esso in un modo che abbia un senso. L'errore si verifica ancora, occasionalmente, ma è molto meno grave.
Avanzare rapidamente un po 'su Java, con la filosofia di "Preferisci errori di compilazione nel tempo agli errori di runtime". I riferimenti utilizzati in Java eliminano un'intera classe di bug di errore del puntatore, che in C può essere un time sink. (Le dichiarazioni Goto sono la bomba F dei costrutti del linguaggio di programmazione, ei puntatori sono l'istruzione goto delle strutture dati.) Il "preferisci errori di compilazione" è gentilezza sotto mentite spoglie, perché il compilatore punta in modo molto specifico su una riga di codice, quindi in modo drammatico riducendo il grattacapo nel capire, "Sì, so che il computer è arrabbiato con me, ma perché il computer è arrabbiato con me?"
E da allora si sono sviluppate altre lingue. Python non segue la filosofia "preferisci errori di compilazione", ma la preoccupazione principale nelle caratteristiche di progettazione più oscure è la produttività del programmatore, e mostra.
Esegui il debug finché programmi?
Probabilmente lo farai, ma potrebbe essere meno importante di quanto pensi.
La programmazione è quasi come qualsiasi altra attività / professione che potresti conoscere. Diventare un buon professionista o raggiungere un certo grado di "eccellenza" è questione di 3 cose: pratica , curiosità e sarà .
La cosa migliore che ti può capitare è proprio quello che ti preoccupa. Devi fare molti errori e vedere ancora di più da altri programmatori. L'importante è imparare qualcosa da loro.
Sai come non dovrebbe essere fatto. Ora lascia fare come dovrebbe.
Come molte persone hanno già commentato. L'errore (progressivo) passerà da semplici errori logici (relativamente facili da risolvere) a problemi architettonici. Alcuni saranno una sfida. Ridisegno, refactoring, migrazione, aggiornamenti, concorrenza, prestazioni, ...
Dal mio punto di vista, la programmazione è la profilassi di "risoluzione dei problemi". Più difficile è il problema, meglio è. Le sfide rendono questa profezia divertente e interessante. Gli errori sono come una piccola finestra aperta per continuare ad imparare e migliorare. Non ci sono troppi lavori là fuori che possono dirlo ..
Molti di noi non avevano tante risorse quante ne avevano i principianti. Ci sono innumerevoli pagine, siti, forum, blog, guide, libri per cercare soluzioni, opinioni, consigli, ...
Crea la tua personale cassetta degli attrezzi. Queste risorse ti aiutano di più. Siate curiosi e indagate da soli, esercitatevi a casa o durante le ore di lavoro extra.
Preparati, il viaggio è appena iniziato.
Rispondendo alla tua domanda principale ... continuo a fare errori. Immagino che tutti lo facciano.
Ecco perché impostiamo una fase di test in ogni progetto. Ed è per questo che ci sono anche periodi di garanzia. Come molti altri prodotti sul mercato.
Lo sviluppo del software è un commercio come gli altri, eccetto che la creazione di un software efficace è molte volte più difficile della costruzione di altre cose, come ad esempio un mazzo.
Quando un carpentiere costruisce un mazzo potrebbero esserci 10-15 variabili che lui o lei deve tenere a mente nel processo. Che tipo di legno uso? Che taglia è il mazzo? Quante persone ho bisogno per farlo in fretta?
D'altra parte, quando uno sviluppatore di software o un ingegnere costruisce un sistema software complesso, c'è un numero immenso di variabili coinvolte. Cos'è che sto effettivamente costruendo? (che da solo è spesso separato nel ruolo di analisi aziendale) Quale lingua sto usando? Sono abile con la lingua? Come dovrebbe essere la mia UI? Come dovrei strutturare il mio codice lato server in modo che non si rompa? Quale framework di test dovrei usare? E ancora e ancora e ancora.
Personalmente, ho fatto il codice per circa 5 anni e l'importo che ho imparato sul commercio in quel periodo è enorme, e non ho ancora finito. So di essere un ragazzo abbastanza intelligente, ma nel mio primo anno di sviluppo non ero capace di capire. I miei programmi erano orribili e facevo sempre errori elementari. Ma più lo facevo più imparavo, meno spesso facevo errori e più cresceva la mia abilità. Il processo è stato abbastanza organico.
Quindi la differenza chiave tra lo sviluppo e altre attività commerciali è che lo sviluppo ha una curva di apprendimento molto più lunga rispetto alla maggior parte degli altri campi. Potrebbero volerci anni solo per raggiungere il livello junior e altri anni per diventare un intermedio.
Quindi ti suggerirei se hai meno di un anno e ti senti perso, è normale. Continua a imparare seriamente quando puoi e arriverai lì.
Che cosa consideri un "errore"?
Ho sviluppato software per 15 anni.
Devo fare errori di sintassi? Si Sempre. "Oops, dimenticato .text quando si cambia un contenuto di UILabel. Oops, ho dimenticato un punto e virgola alla fine di una riga in PHP perché è una delle poche lingue che lo richiedono e ho scritto Python per tutta la mattinata. dove invece di .find_by in Rails .Oops, ho formattato di nuovo il mio JSON sbagliato Oops, ho cercato di usare la sintassi per un ciclo di Swift for in JS. Oops, i parametri sono nell'ordine sbagliato. Oops, ho dimenticato i nomi di tutti i metodi hai bisogno di un TableViewDelegate. Come diavolo gestisci una Array of Dizionari che contiene più dizionari e più array che devono poi essere convertiti in JSON prima di POST sul database e assicurandosi di gestire correttamente tutti gli optionals e la data di formattazione per MySQL, e quindi restituire i dati e trasformarli in oggetti di data, ma assicurandoti di ottenere ancora i millisecondi in modo che possano essere visualizzati sul front-end? " L'elenco potrebbe continuare all'infinito. Sei obbligato a scivolare, o dimenticare come fare le cose. Ci sono troppe cose da ricordare. Tuttavia, questi sono risolti rapidamente.
Quando sto pianificando come costruire realmente qualcosa, commetto errori ogni volta. Avrò tutto pianificato nella mia testa e poi mentre sto programmando mi rendo conto che "No, non può davvero farlo in quel modo". E poi torna al tavolo da disegno.
Quando ho ricevuto una nuova API o SDK, farò un milione di errori. Spesso la documentazione non è ben scritta / non aggiornata / qualcosa è cambiato che non funziona più / sto guardando al tutorial sbagliato. Spesso stai solo indovinando e provando tutto per farlo funzionare perché non hai tutte le informazioni corrette. Spesso ho bisogno di guardare un mucchio di risorse e tirare pezzi da ognuna per ottenere la risposta corretta.
Dimenticherò se ho aggiunto una funzione o non sempre. "Ho implementato quell'animazione richiesta dal cliente 4 mesi fa in una telefonata di 2 minuti? No."
O spesso, mi mancherà solo del tutto. "Uh, ho dimenticato di spiegare cosa succede se due dispositivi IoT sono vicini invece di uno. S #! T, e se gli utenti cercano di fare clic su quel pulsante mentre i dati vengono postati sul server? Oh F $% *, cosa succede se dieci utenti provano a cambiare lo stesso campo allo stesso tempo mentre si preme refresh e spamming il pulsante di invio? Ho tenuto conto di quello !? Che dire di quel ragazzo che sta andando a premere incrementare, incrementare, incrementare, incrementare, incrementare .. decrementa ... decrementa, incrementa l'incremento, decremento ... incrementa il che gli consentirà di iniettare valori esadecimali nel registro del server dell'FBI e prendere il controllo di tutti i memi cat di Internet!?!? Tutto questo succederà totalmente un giorno perché mi sono dimenticato di testarlo.
E poi 2 mesi dopo accidentalmente esegui l'aggiornamento dei pod quando apri il progetto che non hai toccato da allora, e improvvisamente non funziona più e ottieni 300 errori del compilatore.
In sostanza, probabilmente faccio più errori in un giorno di quanto non risolvo.
Leggi altre domande sui tag programming-practices errors source-code