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

Ciao mondo! Una volta che hai imparato tutto ciò che devi sapere e finalmente sei arrivato a lavorare come stagista o junior dev, probabilmente puoi rilassarti, giusto? No. Tutto è solo all'inizio per te... Sei circondato da molte cose nuove e incomprensibili. Come fai a non rovinare tutto fin dall'inizio? È di questo che parleremo oggi. In questo articolo, voglio analizzare gli errori comuni dei principianti e dare alcuni consigli, basati sulla mia esperienza, su come evitarli. Quindi, iniziamo senza ulteriori indugi:

1. Paura di cercare aiuto da colleghi più esperti

Siamo tutti umani. Abbiamo tutti paura di sembrare stupidi, soprattutto agli occhi dei nostri nuovi colleghi più esperti. Quando gli sviluppatori accettano il loro primo lavoro, sono spesso guidati da questa paura e, a voce alta, si chiudono in se stessi, cercando di capire tutto da soli. Inoltre, qualcuno può essere circondato da colleghi più esperti, che, a loro volta, sono in grado di indirizzarlo nella direzione più promettente, aiutandolo a evitare ulteriori errori e inutili "colpi di testa". Quindi ricorda: non aver paura di fare domande. Sei un principiante e tutti lo capiscono perfettamente. Quando lo chiedi, nessuno ti picchierà con i bastoni. Forse accadrà anche il contrario: diventerai amico dei tuoi colleghi più rapidamente e inizierai a godere di una comunicazione più attiva con loro. IO' Dirò ancora di più: più chiedi e discuti vari problemi tecnici, più velocemente sarai in grado di liberarti della tua pelle verde da principiante e diventare un esperto nel tuo campo. E un altro consiglio. Non essere estraneo aStackOverflow . Sto specificamente parlando di porre domande su questa risorsa. Da un lato, ci vuole del tempo per ottenere una risposta alla tua domanda. Ma d'altra parte, potresti imparare rapidamente più approcci per risolvere il tuo problema e guardarlo da un'angolazione leggermente diversa. Voglio anche notare che ci sono vantaggi pratici nello scrivere commenti/risposte e scrivere domande di chiarimento sulle domande di StackOverflow da parte di altri sviluppatori: hai la possibilità di discutere e approfondire i problemi, per non parlare di un aumento del karma.

2. Non provare a cercare informazioni da solo

Questo errore potrebbe essere considerato il rovescio della medaglia del precedente.Qui intendo quando inizi a infastidire i tuoi colleghi e conoscenti su ogni problema o singhiozzo che incontri. Chiedere va bene, ma non esagerare con le domande. Altrimenti, le persone potrebbero semplicemente trovarti fastidioso. Se ti senti confuso su qualcosa, la prima cosa da fare è esercitare le tue capacità di ricerca nel miglior motore di ricerca: Google. Qualcun altro ha già riscontrato la stragrande maggioranza di errori incomprensibili e altri problemi. E rimarrai piuttosto sorpreso se cerchi su Google la tua domanda e vedi il numero di persone che hanno familiarità con un problema simile e che hanno già ricevuto risposte esaustive che puoi applicare nel tuo lavoro. Ecco perché sentirai spesso i tuoi colleghi rispondere con "Google it". Assistente' Non essere offeso da questa risposta: il tuo collega non è il tuo insegnante personale che deve trasmettere tutte le sottigliezze del tuo campo di lavoro. Le infinite distese di Internet saranno il tuo mentore. A volte i programmatori sono anche indicati comepersone con cintura nera nella ricerca su Google . Quindi, se abbiamo un "singhiozzo", cerchiamo prima il problema su Google. Se non si riesce a trovare una soluzione (questo è raro, ma succede), solo allora iniziamo a chiedere ai colleghi. Le domande immediate servono per ottenere consigli su quale approccio dovresti scegliere per risolvere un problema più di quello che faresti quando colpisci un dosso o un messaggio di errore incomprensibile. Dopotutto, potrebbero essere in grado di vedere oltre il tuo approccio preferito e prevedere immediatamente dove porterà un dato approccio nel lungo periodo.

3. Copiare e incollare alla cieca

Ma cercare su Google i problemi e le loro soluzioni ha le sue insidie. Ad esempio, copiando e incollando alla cieca .Questo di solito accade quando trovi un problema simile (ma forse non esattamente lo stesso) e una soluzione associata, ad esempio, su StackOverflow. Prendi questa soluzione e copiala e incollala senza approfondire ulteriormente i dettagli. E poi tu o i tuoi colleghi scoprite alcuni strani bug o comportamenti scorretti nel vostro codice. E nessuno può indovinare immediatamente da dove provengano. Alla fine, ovviamente, verrà trovato il posto con il codice copiato e sicuramente non sarai elogiato per la tua soluzione. Pertanto, quando trovi una soluzione già pronta su StackOverflow (o altrove), devi prima capire a fondo cosa, come e perché. Forse cerca su Google la funzionalità pertinente e leggi la relativa documentazione. E solo dopo averlo fatto dovresti aggiungerlo al tuo progetto.

4. Attenersi alla soluzione sbagliata

Quando scrivi una soluzione, a volte scoprirai che sta diventando sempre più complicata, arrivando infine a un vicolo cieco. E poi cerchi di rendere la soluzione ancora più elaborata per farla funzionare in qualche modo invece di cercare un'altra alternativa più adatta. Forse hai la sensazione di aver investito molto tempo e impegno e quindi hai deciso che, qualunque cosa accada, non ti arrenderai e risolverai il problema con il tuo approccio esistente. Questo non è proprio l'atteggiamento giusto. Almeno nella programmazione. Prima provi un approccio diverso, più tempo risparmierai alla fine. Quindi non aver paura di sperimentare e provare altri approcci, indipendentemente dalla quantità di tempo che hai investito in quello attuale. Inoltre, provando più approcci e immergendosi più a fondo nell'argomento,

5. Paura di fare domande sul tuo incarico attuale

Lavorare su un progetto di sviluppo software di solito si riduce all'esecuzione di compiti specifici. Ad esempio, in Jira. Questi compiti non sono sempre delineati in modo chiaro e dettagliato. Le descrizioni delle attività sono solitamente scritte dai capisquadra, che sono anche comuni mortali. Potrebbero dimenticare di aggiungere qualcosa o non tenere conto del fatto che non hai familiarità con questa o quella funzionalità. O forse non hai alcun accesso al progetto (ad esempio, accesso al database, al server di registro e così via). E ora hai ricevuto il compito, l'hai studiato per più di un paio d'ore, ma sei ancora seduto lì, a fissare lo schermo perplesso. Invece di continuare a tentare senza successo di capirlo, dovresti iniziare a chiedere chiarimenti o indicazioni a chi ha creato l'attività. Ad esempio, nell'app che il tuo team usa per la comunicazione (ad esempio, Microsoft Teams), potresti porre domande o fare un commento diretto sull'attività. Da un lato, se scrivi la tua domanda in un messaggio personale, probabilmente otterrai una risposta più velocemente, poiché la persona vedrà immediatamente la tua domanda. D'altra parte, ponendo una domanda in Jira, stabilisci la prova che stai facendo qualcosa, vale a dire, analizzando il problema. C'è un modo per accelerare questo processo: fai la tua domanda in un commento in Jira e poi in un DM, lascia un link al tuo commento e chiedi di dare un'occhiata.

6. Riporre aspettative irrealisticamente elevate sul leader della squadra

Ancora una volta, questo è il rovescio della medaglia del punto precedente. Il team leader è il capo di un team di sviluppo. Di norma, il responsabile del tuo team trascorre la maggior parte del suo tempo in vari tipi di comunicazione. Tuttavia, scrive anche codice per non dimenticare tutto sulla programmazione. Come puoi capire, la vita di un team leader è molto impegnativa. Tirare la manica del leader della tua squadra ogni volta che hai bisogno di starnutire non sarà ovviamente piacevole. Immagina ogni membro del team che bombarda il lead con una serie di domande. Potrebbe far impazzire chiunque, giusto? E se accumuli molte domande, il capo del tuo team dovrà dedicare molto tempo a risponderti. Cosa si può fare per ridurre il numero di domande rivolte al capogruppo:

• Esplora la documentazione del progetto in modo più approfondito per ridurre il numero di punti ciechi.
• Indirizza le tue domande agli altri membri del tuo team. Potrebbero avere familiarità con questa funzionalità quanto lo è il lead, o forse anche di più, poiché molto probabilmente la funzionalità è stata scritta da uno di loro.

In alternativa, puoi guardare le annotazioni nell'IDE a chi e quando il codice in una riga specifica è stato modificato l'ultima volta. Proprio così puoi scoprire chi è la persona più adatta a porre la tua domanda. Come probabilmente già ti rendi conto, quando si tratta di domande al capogruppo, proprio come con le domande ai colleghi, devi cercare di trovare una giusta via di mezzo: non aver paura di fare domande, ma anche di non farne troppe di loro.

7. Paura delle revisioni del codice

Una revisione del codiceè una fase del genere che si verifica prima di inviare il codice a un'applicazione comune (a un ramo condiviso, ad esempio, master o dev). Questo controllo viene eseguito da uno sviluppatore che non è coinvolto nell'attività, i cui occhi nuovi possono rilevare errori, imprecisioni o difetti nello stile del tuo codice che sono passati inosservati quando hai scritto inizialmente il tuo codice. Se ci sono critiche, vengono lasciate come commenti su alcune parti del codice. In questo caso, lo sviluppatore che ha scritto il codice deve correggere gli errori individuati nella revisione (o discutere le sue decisioni con il revisore, eventualmente convincendolo che sono corrette). Quindi il codice viene inviato per la revisione più e più volte fino a quando il revisore non ha più commenti. Il revisore funge da "gateway" prima che venga eseguito il commit del codice. La sfida è che molti programmatori alle prime armi percepiscono la revisione del codice come una critica e una condanna. Non apprezzano le revisioni del codice e ne hanno paura. Non dovrebbero. Le revisioni del codice sono esattamente ciò che ci consente di migliorare il nostro codice. Dopotutto, riceviamo informazioni importanti su cosa stiamo facendo di sbagliato e su cosa vale la pena prestare attenzione. Dovresti considerare ogni revisione del codice come parte della curva di apprendimento, qualcosa che può aiutarti a migliorare. Quando qualcuno commenta il tuo codice, sta condividendo esperienze e best practice con te. Personalmente non credo che tu possa diventare un buon programmatore senza ottenere revisioni del codice. Perché non sei nemmeno consapevole della qualità del tuo codice e se un estraneo esperto indicherebbe gli errori. t apprezzo le revisioni del codice e ne ho paura. Non dovrebbero. Le revisioni del codice sono esattamente ciò che ci consente di migliorare il nostro codice. Dopotutto, riceviamo informazioni importanti su cosa stiamo facendo di sbagliato e su cosa vale la pena prestare attenzione. Dovresti considerare ogni revisione del codice come parte della curva di apprendimento, qualcosa che può aiutarti a migliorare. Quando qualcuno commenta il tuo codice, sta condividendo esperienze e best practice con te. Personalmente non credo che tu possa diventare un buon programmatore senza ottenere revisioni del codice. Perché non sei nemmeno consapevole della qualità del tuo codice e se un estraneo esperto indicherebbe gli errori. t apprezzo le revisioni del codice e ne ho paura. Non dovrebbero. Le revisioni del codice sono esattamente ciò che ci consente di migliorare il nostro codice. Dopotutto, riceviamo informazioni importanti su cosa stiamo facendo di sbagliato e su cosa vale la pena prestare attenzione. Dovresti considerare ogni revisione del codice come parte della curva di apprendimento, qualcosa che può aiutarti a migliorare. Quando qualcuno commenta il tuo codice, sta condividendo esperienze e best practice con te. Personalmente non credo che tu possa diventare un buon programmatore senza ottenere revisioni del codice. Perché non sei nemmeno consapevole della qualità del tuo codice e se un estraneo esperto indicherebbe gli errori. stai sbagliando e a cosa vale la pena prestare attenzione. Dovresti considerare ogni revisione del codice come parte della curva di apprendimento, qualcosa che può aiutarti a migliorare. Quando qualcuno commenta il tuo codice, sta condividendo esperienze e best practice con te. Personalmente non credo che tu possa diventare un buon programmatore senza ottenere revisioni del codice. Perché non sei nemmeno consapevole della qualità del tuo codice e se un estraneo esperto indicherebbe gli errori. stai sbagliando e a cosa vale la pena prestare attenzione. Dovresti considerare ogni revisione del codice come parte della curva di apprendimento, qualcosa che può aiutarti a migliorare. Quando qualcuno commenta il tuo codice, sta condividendo esperienze e best practice con te. Personalmente non credo che tu possa diventare un buon programmatore senza ottenere revisioni del codice. Perché non sei nemmeno consapevole della qualità del tuo codice e se un estraneo esperto indicherebbe gli errori.

8. Propensione alle decisioni arcane

Vari compiti/problemi possono spesso avere diverse soluzioni. E tra tutte le soluzioni disponibili, i principianti tendono a usare quelle più complesse e arcane. E questo ha senso: i programmatori alle prime armi proprio ieri hanno imparato molti algoritmi, modelli e strutture di dati diversi, quindi le loro mani non vedono l'ora di implementarne alcuni. Fidati di me, ero così, quindi so di cosa sto parlando :) Ho avuto una situazione in cui stavo implementando alcune funzionalità per molto tempo. Si è rivelato molto, molto complicato. Quindi lo sviluppatore senior ha riscritto il mio codice. Certo, ero molto interessato a vedere cosa e come l'ha cambiato. Ho guardato la sua implementazione e sono rimasto stupito di quanto fosse più semplice. E c'era tre volte meno codice. Inoltre, sorprendentemente, i test automatizzati per questa funzionalità non sono stati rimossi o modificati! In altre parole, la logica generale è rimasta la stessa. Da questo, sono arrivato alla conclusione chele soluzioni più geniali sono sempre semplici . Dopo questa realizzazione, la codifica è diventata molto più semplice e la qualità del mio codice è balzata a un livello significativamente più alto. Allora quando vale la pena applicare modelli di progettazione e algoritmi fantasiosi, chiedi? Quando li applichi sarà la soluzione più semplice e compatta.

9. Reinventare la ruota

La ruota è una soluzione duratura che è stata inventata molto tempo fa. In questo anti-pattern, lo sviluppatore implementa la propria soluzione proprietaria per un problema che è già stato risolto. A volte queste soluzioni esistenti sono migliori di quelle proposte dal programmatore. Di norma, reinventare la ruota porterà alla perdita di tempo e alla diminuzione della produttività, perché la soluzione che trovi potrebbe essere tutt'altro che la migliore o, beh, potresti non trovarne affatto. Detto questo, non possiamo escludere la possibilità di creare una nostra soluzione indipendente: se lo facessimo, tutto ciò che rimarrebbe sarebbe la programmazione copia e incolla. Il programmatore dovrebbe essere adeguatamente guidato dalle specifiche attività di programmazione che si presentano per risolverle in modo competente e tempestivo, utilizzando soluzioni già pronte o creando soluzioni personalizzate. Da un lato, nelle università e nei corsi online, siamo bombardati da vari tipi di attività che sembrano progettate per aiutarci a reinventare le ruote. Ma solo a prima vista: il vero scopo qui è sviluppare il pensiero algoritmico e una più profonda padronanza della sintassi del linguaggio. Tali compiti ti aiutano anche a comprendere meglio algoritmi e strutture di dati e ti danno le competenze per implementare controparti più sofisticate, se necessario (questo a volte è necessario, ma è estremamente raro). Nella vita reale, nella stragrande maggioranza dei casi non è necessario inventare la propria ruota, poiché le ruote che soddisfano le proprie esigenze esistono da molto tempo. Forse la tua inesperienza ti impedisce di conoscere l'esistenza di implementazioni della funzionalità di cui hai bisogno. È qui che devi seguire i consigli forniti nel primo punto di questo articolo, vale a dire, chiedere aiuto a colleghi più esperti. Saranno in grado di guidarti (ad esempio, indirizzarti nella giusta direzione nella tua ricerca su Google) o suggerire un'implementazione specifica (ad esempio, una libreria).

10. Mancata scrittura dei test

A tutti i neofiti non piace scrivere test. Ma perché dovremmo individuare i neofiti, qui? Anche agli sviluppatori più esperti non piace scrivere test, ma capiscono meglio perché sono necessari i test. Quando sei completamente verde, ti chiedi perché dovresti scriverli. Tutto funziona, quindi non ci possono essere errori. Ma come puoi assicurarti che le tue modifiche non rompano qualcosa in altre parti del sistema? I tuoi colleghi non apprezzeranno se introduci cambiamenti che causano più danni che benefici. È qui che i test vengono in nostro soccorso. Più il codice di un'applicazione è coperto dai test, meglio è (si parla di copertura del codice o copertura dei test). Se l'applicazione ha una buona copertura del test, puoi eseguire tutti i test per trovare i punti che verranno interrotti dal tuo codice. E come ho detto nell'esempio sopra, quando lo sviluppatore senior ha eseguito il refactoring del codice, i test non hanno fallito. Questo perché la logica generale non è cambiata. Utilizziamo test per dimostrare se la logica di determinate funzionalità è cambiata o meno. Quindi, anche se non ti piace scrivere test, sono sicuramente utili e valgono il tempo speso per loro.

11. Commenti eccessivi

Molti sviluppatori soffrono di perfezionismo e i neofiti non fanno eccezione. A volte manifestano solo un aspetto di questa propensione quando iniziano a commentare tutto e tutti. Anche fare commenti che non sono necessari, perché il codice è così ovvio:

Cat cat = new Cat(); // Cat object

Non tutti i programmatori alle prime armi si rendono subito conto che commentare il codice non sempre va bene, perché i commenti superflui ingombrano il codice e ne rendono difficile la lettura. E se il codice cambia, ma i vecchi commenti non vengono aggiornati? Allora ci inganneranno e ci confonderanno. Allora perché fare un commento del genere? Di solito, il codice ben scritto non ha bisogno di essere commentato , poiché tutto in esso è già ovvio e leggibile. Se hai bisogno di scrivere un commento, allora hai già rovinato la leggibilità del codice e stai cercando di rimediare in qualche modo alla situazione. L'approccio migliore è scrivere codice leggibile fin dall'inizio, cioè codice che non ha bisogno di commenti. Inoltre, non posso fare a meno di menzionare la necessità di seguire le convenzioni di denominazione corrette per metodi, variabili e classi. Ecco la mia regola: Il commento migliore è nessun commento o una denominazione corretta che descriva chiaramente la funzionalità nell'applicazione.

12. Cattiva denominazione

I neofiti giocano velocemente e liberamente nella denominazione di classi, variabili, metodi, ecc. Ad esempio, creando una classe il cui nome non descrive affatto il suo scopo. Oppure dichiarano una variabile con un nome breve, qualcosa come x . Loro quando altre due variabili denominate n e yvengono creati, ricordare di cosa è responsabile x diventa molto difficile. Di fronte a questa situazione bisogna ragionare bene sul codice, analizzandolo al microscopio (magari usando un debugger), studiandone le funzionalità per capire semplicemente cosa sta succedendo. È qui che le convenzioni di denominazione corrette che ho menzionato sopra vengono in nostro aiuto. I nomi corretti migliorano la leggibilità del codice, riducendo così il tempo necessario per familiarizzare con il codice, perché l'utilizzo di un metodo è molto più semplice quando il suo nome ne descrive approssimativamente la funzionalità. Tutto nel codice è costituito da nomi (variabili, metodi, classi, oggetti, file, ecc.), quindi questo punto diventa molto importante quando si crea un codice corretto e pulito. Dovresti ricordare che il nome dovrebbe trasmettere un significato, ad esempio, perché la variabile esiste, cosa fa, e come viene utilizzato. Noterò più di una volta che il miglior commento per una variabile è darle un buon nome. Per uno studio più approfondito dei commenti e della corretta denominazione, consiglio di leggere i classici senza tempo:"Codice pulito: un manuale di artigianato software agile" di Robert Martin . Su questa nota, la prima parte di questo articolo (le mie riflessioni) è giunta al termine. Continua...