CodeGym /Java Blog /Random-IT /Analisi degli errori comuni commessi dai programmatori al...
John Squirrels
Livello 41
San Francisco

Analisi degli errori comuni commessi dai programmatori alle prime armi, pt. 2

Pubblicato nel gruppo Random-IT
Ciao di nuovo a tutti! Continueremo a considerare i problemi che un programmatore giovane e immaturo potrebbe incontrare nel suo primo lavoro. La prima parte la potete trovare qui . Analisi degli errori comuni commessi dai programmatori alle prime armi, pt.  2 - 1Continuiamo.

13. Mancato rispetto delle linee guida sullo stile di codifica.

I team di sviluppo di solito si attengono a un unico stile di codifica. Cioè, i singoli sviluppatori seguono determinate regole scritte o non scritte per garantire che il loro stile di codifica non differisca da quello degli altri. Non cercare di distinguerti con uno stile di codifica distintivo: questo non ti farà fare bella figura. Se sei nuovo al progetto, dovresti scoprire immediatamente se esiste documentazione che definisce le linee guida generali sullo stile di codifica. Potrebbero esserci alcuni file di stile per il tuo progetto specifico che devi richiedere e importare nel tuo IDE (ad esempio, IntelliJ IDEA), in modo che l'IDE possa fornire i suggerimenti corretti sullo stile di codifica. Ad esempio, lo stile potrebbe richiedere l'uso del modificatore finale ove possibile. Il file di stile permette a IntelliJ IDEA di evidenziare in giallo le eventuali variabili dove questa non viene rispettata.

14. Scoraggiarsi a causa degli errori

Analisi degli errori comuni commessi dai programmatori alle prime armi, pt.  2 - 2Gli errori sono qualcosa a cui devi abituarti. Sono stati, sono e saranno. Non importa se sei un principiante o un architetto serio, commetterai sempre degli errori. Il numero e la gravità dei tuoi errori possono cambiare, ma ti accompagneranno per tutta la carriera. A volte fai fatica a far funzionare qualcosa per tutta la settimana, commetti un errore, e poi è venerdì sera e sgattaioli a casa come un cane bastonato, senza riuscire a rimediare a quel maledetto errore. È una sensazione indescrivibile, ma non qualcosa che debba scoraggiarti. Dopotutto, un'altra importante differenza tra uno sviluppatore esperto e un principiante è il modo in cui questi gestisce gli errori. Gli sviluppatori esperti non li prendono a cuore, ma li considerano invece come esperienza. Nessuno ti rimprovererà per aver commesso un errore. Questo è normale: tutti a volte si mettono nei guai. Ancora una volta, puoi chiedere aiuto ai colleghi. E non dimenticare persone come i project manager (PM). Se sei bloccato su qualcosa, dovresti contattare immediatamente il PM. Lui o lei può aiutarti a trovare qualcuno che sia un esperto nell'area problematica. In ogni caso, il PM deve essere tenuto informato su eventuali problemi riscontrati nel progetto. È compito del PM aiutare a risolvere tutti i tipi di problemi, comprese la comunicazione e le interazioni tra i membri del team. Per riassumere: gli errori accadono , non lasciare che ti uccidano. Invece, accettali come una sfida per te e le tue capacità. Alla fine, è solo una parte del lavoro.

15. Mancata implementazione della sicurezza del thread.

Niente di buono si crea facilmente. Ogni sviluppatore deve comprendere che la scrittura di funzionalità specifiche, che si tratti di un modulo o semplicemente di un metodo, richiede un piano su cosa verrà fatto e come. Di norma, quando si sviluppano funzionalità di qualsiasi complessità, è necessario attenersi alla seguente procedura:
Pensa -> analizza -> crea un piano -> scrivi codice -> prova codice -> refactoring
Molti errori che si verificano nel codice scritto da programmatori alle prime armi riguardano i passaggi di questa procedura. Naturalmente, non puoi escludere che ci siano momenti in cui devi scrivere rapidamente il codice senza esitazione non appena vedi l'attività. Ma questo generalmente funziona solo per alcuni compiti e metodi minori la cui implementazione è ovvia e non richiede molta riflessione. La procedura di sviluppo menzionata sopra è più adatta per compiti complessi e di grandi dimensioni che possono essere suddivisi in sottoattività. Non è una buona idea iniziare a scrivere codice senza capire chiaramente cosa vuoi scrivere. Innanzitutto, devi pensare attentamente e pianificare tutto. Può anche essere utile prendere un foglio di carta e una matita e provare ad abbozzare le tue idee di implementazione. Lo faccio sempre quando pianifico funzionalità complesse. Un programmatore trascorre la maggior parte del suo tempo non scrivendo codice, ma piuttosto pensando a come strutturare le funzionalità richieste . Infatti, una volta che hai pianificato e pensato a tutto, scrivere il codice diventa un processo puramente meccanico e senza problemi.

16. Superlavoro

Analisi degli errori comuni commessi dai programmatori alle prime armi, pt.  2 - 3
dal film "Fight club" (1999)
Forse ogni principiante pensa che lavorando fino a tarda notte, inizierà a completare più compiti e gli verranno affidate maggiori responsabilità. Lo pensavo anch'io, ma ora non più. Ho notato che arriva un punto in cui raggiungi il tuo limite, quando smetti di essere in grado di pensare adeguatamente. Inizi a diventare piuttosto noioso e avverti la nebbia mentale. Ci vuole un'ora per fare cose che potresti fare in 10 minuti se la tua mente fosse fresca. Quasi senza eccezione, dopo aver oltrepassato questa linea di fatica, incontri qualche problema che sembra insormontabile. Ma quando arrivi al lavoro la mattina dopo, risolvi il problema in un batter d'occhio. Quindi, quando ritieni di essere arrivato a questo punto, non restare alzato fino a tardi. Vai a casa e riposati bene. Dopotutto, se rimani alla scrivania fino a tarda notte, non solo non otterrai risultati particolarmente brillanti in queste ore di tormento, ma allo stesso tempo rischierai uno scarso (insufficiente) riposo prima della successiva giornata lavorativa, quando farò un pasticcio ancora una volta. Pensa alla tua salute: vale la pena minarla in questo modo all'inizio della tua carriera? Penso di no. È un periodo costoso per ammalarsi. E pensa al tuo datore di lavoro. Lavorando troppo, peggiori le cose non solo per te stesso, ma anche per il tuo datore di lavoro. Chi ha bisogno di un dipendente perennemente assonnato che, a causa dell'esaurimento, non riesce a implementare l'algoritmo di ordinamento più semplice? Sì, ci sono senza dubbio momenti in cui hai una scadenza ravvicinata, momenti in cui tutto è andato storto e momenti in cui - e questo è il mio preferito - "ne avevamo bisogno ieri". Ma queste situazioni sono generalmente rare e, una volta superate, è necessario sedersi e considerare attentamente come potrebbero essersi verificate e come evitarle in futuro.

17. Trascurare le competenze in inglese

Molti aspiranti sviluppatori danno priorità all’apprendimento della tecnologia e rimandano l’apprendimento dell’inglese. Questo è un grave errore, poiché molto spesso un programmatore è perfetto per una posizione junior (o stage), ma non ottiene il lavoro a causa delle scarse competenze in inglese. Sì, certo, ci sono casi in cui puoi farcela senza l'inglese. Di norma, queste persone vengono assunte localmente per progetti in paesi non anglofoni. Ma le aziende locali non pagano gli stessi salari delle aziende straniere. E sarà molto, molto difficile ottenere uno stipendio dignitoso, anche col tempo. Ecco perché non dovresti ignorare l'inglese. Invece di mettere l’inglese nel dimenticatoio, devi impararlo per concentrarti immediatamente su progetti in lingua inglese. In effetti, pensaci per un minuto: l’inglese è attualmente la lingua degli affari internazionali. Qualunque sia il paese in cui vai, puoi trovare una lingua comune con gli altri se conosci l'inglese. Lo stesso vale nei progetti di sviluppo. Non importa dove sia basato il progetto: Germania, Australia, Francia o altrove: tutta la comunicazione, tutti i compiti, la documentazione, ecc. saranno in inglese. E se ci pensi un attimo, converrai che è molto conveniente, vero?

18. Ricerca della tecnologia alla moda

Quando gli sviluppatori iniziano il loro percorso, spesso cercano di tenere il passo con le tecnologie più recenti. È la cosa giusta da fare? Da un lato sì: le ultime tecnologie, i progetti... Ma vale la pena dare a questo una priorità assoluta? Forse è meglio perseguire il "strumento classico" per uno specialista nel tuo campo? Il nuovo è sicuramente positivo, ma non devi dimenticare le tecnologie fondamentali del tuo settore. E solo allora, dopo aver acquisito un po' di esperienza e una conoscenza approfondita delle nozioni di base, puoi provare qualcosa di nuovo. Considera anche che le nuove tecnologie possono essere superiori in alcuni aspetti sottili, ma possono perdere vantaggi in altri. Fino a quando uno sviluppatore alle prime armi non comprende questi compromessi, è meglio attenersi alle soluzioni collaudate nel tempo. Ad esempio, se un programmatore sta sviluppando un'applicazione che interagisce con alcuni dati, non affrettarti a utilizzare l'ultima soluzione NoSQL semplicemente perché è di moda. Un normale database SQL collaudato (MySQL, PostrgreSQL, ecc.) molto probabilmente ha documentazione dettagliata e soluzioni su StackOverFlow per eventuali problemi :)

19. Imparare diverse tecnologie e/o linguaggi contemporaneamente

Abbiamo parlato sopra dei principianti che cercano di apprendere le tecnologie alla moda. Ebbene, che ne dici di studiare contemporaneamente più tecnologie o lingue? Ovviamente hai sentito parlare di programmatori che conoscono più di un linguaggio di programmazione e padroneggiano molte tecnologie. Ma sottolineerò subito che queste persone sono tutt'altro che nuove alla programmazione. Si tratta di persone con molti anni di esperienza alle spalle. Hanno padroneggiato la loro tecnologia originale e poi sono andati sempre oltre. I principianti che cercano di padroneggiare tutto in una volta dovrebbero ricordare l'eccellente proverbio: "insegui due lepri e non ne prenderai nessuna". La conseguenza potrebbe essere che non padroneggerai bene nessun argomento, ma imparerai gli argomenti solo superficialmente. Ci sarà più richiesta per uno specialista che conosca profondamente una singola lingua che per uno che sappia un po’ di tutto. Quindi, se vuoi conoscere molti linguaggi e tecnologie, devi affrontarli con saggezza. Per iniziare, devi scegliere una lingua base e fondamentale che devi imparare profondamente. E solo allora dovresti iniziare a studiare altre aree. Ad esempio, diventa un guru di Java, quindi impara Python come seconda lingua. Successivamente, potresti imparare qualcosa su react/angular per il frontend. In questo caso parliamo di tecnologie non intercambiabili, come C# e Java, ma piuttosto complementari, che ampliano le possibilità di carriera. Ma ripeto ancora una volta: non dovresti cercare di imparare tutto in una volta. Devi andare in sequenza. Cattura una lepre alla volta, per così dire.

20. Obiettivi formulati in modo errato

Come stabilisci gli obiettivi per te stesso? Diventare uno sviluppatore interessante? Ricordalo una volta per tutte: devi fissare obiettivi concreti o, in altre parole, obiettivi realizzabili. Di cosa sto parlando? Ad esempio, ti poni l'obiettivo: "Voglio diventare ricco". Ma come faresti a sapere se hai raggiunto questo obiettivo? Oppure come misuri quanto sei vicino a raggiungerlo? Beh, se stabilisci l'obiettivo "Voglio guadagnare un milione di dollari", è un po' più chiaro, no? Una volta guadagnati $ 10.000, sei $ 10.000 più vicino al tuo obiettivo: mancano solo $ 990.000. C'è ancora molto da raggiungere, ma puoi sentire i tuoi progressi e capire dov'è il traguardo, quindi sarai motivato ad andare avanti. Per quanto riguarda la tua carriera, che ne dici di fissarti un obiettivo più tangibile? Ad esempio: voglio diventare un team leader. O uno sviluppatore senior. O in definitiva un architetto. Ebbene, ogni grande compito deve essere suddiviso in piccole sottoattività. Non diventi caposquadra all'inizio della tua carriera. Stabilisci delle scadenze, se possibile e appropriato, e concentrati sulla fase attuale.
  1. Se parliamo di diventare uno sviluppatore senior , il primo piccolo obiettivo sarebbe trovare uno stage o un lavoro come sviluppatore junior presso un'azienda.
  2. Successivamente, puoi fissare obiettivi per approfondire la tua conoscenza di determinate tecnologie. Per quanto riguarda Java, potresti prepararti per la certificazione Oracle Livello 1. Stabiliamo un arco temporale per la nostra preparazione e affrontiamo l’obiettivo.
  3. Quindi, ad esempio, potresti fissare l'obiettivo di migliorare il tuo inglese di un livello (ad esempio, da B1 a B2). Elaboriamo un piano di apprendimento, pianifichiamo il tempo e ci muoviamo verso l'obiettivo.
In questo modo possiamo raggiungere il nostro obiettivo finale passo dopo passo (acquisendo esperienza nello sviluppo di software).

21. Teoria senza pratica

È un fatto indiscutibile che diventiamo professionisti migliori studiando nuove tecnologie e approfondendo argomenti che già conosciamo. Ma all'inizio del viaggio, gli sviluppatori raramente si rendono conto che divorare libri tecnici uno dopo l'altro non porta enormi benefici se le nuove conoscenze non vengono sperimentate nella pratica. Personalmente mi sono imbattuto in questo più di una volta. Se dedichi molto tempo a un libro ma non fai pratica con esso, quasi tutta la conoscenza appena acquisita viene dimenticata: ti rimane solo un vago ricordo generale di come funziona il tutto. Il risultato è un sacco di tempo sprecato senza risultati tangibili. Perché dovremmo sprecare il nostro tempo? La vita non dura per sempre. La conclusione è che quando impari una nuova tecnologia, non dovresti rimanere bloccato sulla teoria: scrivi gli esempi forniti parallelamente alla tua lettura, sperimenta la nuova tecnologia. Questo è l'unico modo per far sì che il tuo cervello conservi le informazioni. Sì, consumerai nuovi materiali molto più lentamente, ma assimilerai molto di più di ciò che leggi. Inoltre, se si padroneggia bene una tecnologia, quella successiva sarà ancora più facile da padroneggiare (proprio come quando si imparano le lingue).

22. Eccessivo perfezionismo

La maggior parte degli sviluppatori sono perfezionisti: persone che lottano per la perfezione. Ciò significa che anche il loro codice deve essere perfetto. Quindi il tuo codice è stato scritto, testato, messo a punto e sembra che sia ora di inviarlo al ramo principale. Ma non sei ancora soddisfatto del codice, quindi inizi a distorcerlo da una parte e dall'altra, dedicando molto tempo a questo sforzo. E in questo caso, il tempo è denaro del tuo cliente. I programmatori alle prime armi sono più suscettibili a questa ricerca della perfezione. Gli sviluppatori esperti sono abituati alla sensazione che il codice non sarà mai perfetto e che dovrebbero provare a scriverlo meglio. Ma allo stesso tempo non vanno agli estremi nel tentativo di avvicinarsi "all'ideale". Quindi, ricorda di imparare come raggiungere una via di mezzo: non in modo trascurato e non cercando di ricreare la Gioconda in codice.

23. Mancata riflessione sull'architettura

Lasciatemelo dire ancora: non dovreste scrivere codice disordinato. Oltre alla leggibilità e alle prestazioni, devi anche pensare a come il tuo codice potrebbe influenzare il resto dell'applicazione nel suo insieme. Ad esempio, quanto sarà difficile estendere il codice e così via. Il problema è che gli sviluppatori alle prime armi, a causa della loro mancanza di esperienza, potrebbero non rendersi immediatamente conto di come le loro nuove funzionalità influenzeranno l'applicazione in futuro. Questa lungimiranza richiede sicuramente molta pratica per essere sviluppata. Ma cosa devono fare allora i novizi? Non scrivere codice? In queste situazioni vengono in nostro aiuto diversi paradigmi di programmazione. Ad esempio, principi SOLID o vari modelli di progettazione che possono trasmetterti pratiche utili. Anche questi paradigmi dovrebbero essere trattati con cautela e non portati troppo oltre. Ma come determinare il punto in cui stai esagerando? È qui che una revisione del codice da parte di un collega più esperto ti aiuterà. Portando uno sguardo fresco e obiettivo, il tuo collega potrà indicarti la giusta direzione.

24. Sindrome dell'impostore

Analisi degli errori comuni commessi dai programmatori alle prime armi, pt.  2 - 4La sindrome dell’impostore è un fenomeno psicologico in cui una persona non è in grado di attribuire i propri risultati a qualità, capacità e sforzi personali. Nonostante le prove esterne delle loro prestazioni costanti, le persone sensibili a questa sindrome continuano a credere di essere degli impostori e di non meritare il successo che hanno ottenuto. Molti sviluppatori hanno questa sindrome. Forse ci dà la tenacia che ci spinge verso nuove conoscenze e tecnologie. Guardi colleghi più esperti e realizzati e ti senti a disagio, come se non valessi il tuo stipendio. Credimi, questo non è vero. Ci sono e ci saranno sempre sviluppatori che sono migliori o peggiori di te. Qualcun altro ti guarda e si sente a disagio, pensando che non diventerà mai come te. E questo è normale. Il feedback del tuo team, le revisioni del codice e le discussioni aiutano a combattere un po' questa sensazione. Credimi, l'opinione di un estraneo ti sorprenderà piacevolmente, ma solo se non trascuri davvero il tuo lavoro e il tuo sviluppo professionale. Se trascuri queste cose, hai scelto la professione sbagliata. In questa professione bisogna imparare sempre qualcosa di nuovo e lottare per il meglio. Ma penso che le persone che si riuniscono qui siano tutt’altro che pigre. Invece, le persone qui si stanno muovendo con fermezza verso il loro caro obiettivo. Se questo ti descrive, allora non hai nulla da temere.

25. Impegnarsi raramente

Ricordati di eseguire spesso i commit! Non ogni mezz'ora, intendiamoci. Se trascorri una settimana implementando alcune funzionalità, non dovresti eseguire un commit venerdì sera, ma, diciamo, cinque commit. Quasi tutte le attività di grandi dimensioni possono essere suddivise in attività più piccole per comodità. Quindi completi questi compiti più piccoli e ti impegni. E non dimenticare di inviare subito questi commit al server remoto. Altrimenti, potresti fare commit tutta la settimana e poi il tuo computer ha un guasto hardware venerdì all'ora di pranzo, e quindi hai perso un'intera settimana per niente! Ma se caricassi i tuoi commit su un server remoto, dovresti semplicemente trasferire il ramo con il tuo ultimo commit su un altro computer e continuare a lavorare. Ancora una cosa: non inviare nuove funzionalità a un server di produzione live venerdì sera. Fidati di me. Non ne hai bisogno. È molto probabile che vengano alla luce errori imprevisti e trascorrerai il fine settimana a risolverli. E questo non è divertente. Hai bisogno di riposarti nel fine settimana. Immagino sia tutto per oggi. PS Un ultimo consiglio: scrivi molto codice. PPS Scrivi una quantità di codice follemente grande, perché è l'unico modo per acquisire l'esperienza tanto necessaria.
Commenti
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION