Analisi degli errori tipici dei programmatori alle prime armi: parte 1

Ciao mondo! Dopo che hai imparato tutto ciò di cui hai bisogno e finalmente sei stato assunto come stagista o junior, probabilmente puoi rilassarti, giusto? Non importa come sia! Tutto è appena iniziato... Ci sono molte cose nuove e incomprensibili intorno a te, e come non fare un pasticcio così subito? Questo è ciò di cui parleremo oggi. In questo articolo, voglio esaminare gli errori comuni commessi dai principianti e fornire alcuni suggerimenti basati sulla mia esperienza su come evitarli. Quindi, cominciamo senza ulteriori indugi:

1. Paura di chiedere aiuto a colleghi più esperti

Siamo tutti umani e abbiamo tutti paura di sembrare stupidi, soprattutto agli occhi dei nostri colleghi più esperti e appena coniati. Una volta ottenuto il primo lavoro, gli sviluppatori spesso cedono a questa paura e si chiudono inconsolabilmente in se stessi, cercando di capire tutto da soli. Allo stesso tempo, una persona può essere circondata da colleghi più esperti, che, a loro volta, potranno guidarla inizialmente lungo il percorso più corretto, il che aiuterà ad evitare più errori e “conti” inutili. Ricorda quindi: non aver paura di fare domande: sei un principiante e tutti lo capiscono perfettamente. Quando lo chiedi, nessuno ti picchierà con i bastoni. Forse è anche il contrario: farai amicizia con i tuoi colleghi più velocemente e inizierai a comunicare più attivamente con loro. Dirò di più: più chiedi e discuti varie questioni tecniche, più velocemente puoi uscire dai panni di un principiante verde e diventare un esperto nel tuo campo. E un altro consiglio. Non trascurare StackOverFlow . In questo contesto intendo porre domande su questa risorsa. Da un lato, ci vuole del tempo per ottenere una risposta alla tua domanda. D'altra parte, potresti immediatamente conoscere diversi approcci per risolvere il problema attuale e guardarlo da una prospettiva leggermente diversa. Vorrei anche sottolineare che scrivere commenti-risposte, chiarire domande su StackOverFlow di altri sviluppatori, oltre a un vantaggio nel karma, ha un vantaggio pratico: hai l'opportunità di discutere e comprendere questo problema più a fondo.

2. Non provare a cercare informazioni da solo

Forse questo errore è il rovescio del precedente. Intendo quando inizi a tirare addosso ai tuoi colleghi e conoscenti per ogni problema o problematica. Chiedere è bene, ma non dovresti esagerare con le domande, altrimenti potresti annoiarti. La prima cosa da fare se emerge qualche punto incomprensibile è applicare le tue capacità di ricerca nel miglior motore di ricerca: Google. Qualcuno ha già riscontrato la stragrande maggioranza degli errori incomprensibili e altri problemi. E rimarrai piuttosto sorpreso se cerchi su Google e vedi il numero di persone che hanno familiarità con un problema simile e che hanno già ricevuto risposte esaurienti adatte per l'uso nel loro lavoro. Sulla base di ciò, puoi spesso sentire un collega rispondere a una domanda: "Cercalo su Google". Non dovresti essere offeso da questa risposta, perché dopotutto il tuo collega non è un insegnante personale che dovrebbe trasmettere tutte le complessità del tuo campo di lavoro. Le infinite distese di Internet ti aiuteranno con tale tutoraggio. A volte un programmatore viene anche chiamato cintura nera nella ricerca di Google . Pertanto, quando rimaniamo bloccati, cerchiamo prima il problema su Google e, se non è stata trovata alcuna soluzione (raramente, ma succede), iniziamo a chiedere ai nostri colleghi. Vale la pena chiederglielo subito, non quando si verifica qualche tipo di problema tecnico o errore incomprensibile, ma quando si sceglie un approccio per risolvere un problema. Dopotutto, possono vedere oltre il tuo e dire immediatamente come questo o quell'approccio potrebbe rivelarsi a lungo termine.

3. Copia-incolla cieco

Ma cercare su Google il problema e, di conseguenza, la sua soluzione ha le sue insidie. Ad esempio, copia-incolla cieco . Questo di solito accade quando trovi un problema simile (ma magari non esattamente uguale) e sotto ad esso, ad esempio, su StackOverFlow c'è una soluzione. Prendi questa soluzione, copiala e incollala tu stesso, senza entrare troppo nei dettagli. E poi tu o i tuoi colleghi di progetto scoprite alcuni strani bug o comportamenti errati delle vostre funzionalità. E subito nessuno ha idea da dove vengano le gambe. Quindi, ovviamente, verrà trovato un posto con questo codice e sicuramente non sarai elogiato per questa decisione. Pertanto, quando trovi una soluzione già pronta su StackOverFlow (o da qualche altra parte), devi prima di tutto analizzarla nel dettaglio, di cosa si tratta, come e perché. Forse cerca su Google questa funzionalità e guarda la relativa documentazione. E solo dopo implementalo nel tuo progetto.

4. Lanciare la soluzione sbagliata

Quando si scrive una soluzione, a volte capita che diventi sempre più complessa e alla fine raggiunga un vicolo cieco. E stai cercando di complicarlo sempre di più per risolvere in qualche modo questo problema usando questo approccio invece di cercare un’altra alternativa più praticabile. Forse semplicemente ti dispiace per l’energia e il tempo che hai speso, e quindi decidi: qualunque cosa accada, non arrenderti, ma risolvi il problema in questo modo. Questo non è del tutto l’approccio giusto. Almeno nella programmazione. Prima proverai un approccio diverso, più tempo finirai per risparmiare. Quindi non aver paura di sperimentare e provare altri approcci, nonostante la quantità di tempo che hai investito in questo. Inoltre, questi saranno punti per la tua esperienza, poiché proverai diversi approcci e studierai meglio quest'area.

5. Paura di fare domande sul compito attuale

Il lavoro su un progetto di solito si riduce al completamento di alcune attività (Attività). Ad esempio, in Jira . E questi compiti non sono sempre descritti in dettaglio e chiaramente. Di solito sono scritti dai leader del team e anche queste sono persone, se ciò accade. Potrebbero anche dimenticare di aggiungere qualcosa o non tenere conto del fatto che non hai molta familiarità con questa o quella funzionalità. Bene, oppure non hai alcun accesso al progetto (ad esempio, accesso al database, al server di registro e così via). E ora, dopo aver ricevuto l'incarico, dopo averlo studiato per più di un paio d'ore, ti siedi ancora e guardi lo schermo sbalordito. E invece di continuare a capirlo inutilmente, dovresti iniziare a porre domande chiarificatrici/chiaritrici al creatore di questa attività. Diciamo, in un'applicazione che utilizzi per la comunicazione in un team (ad esempio, Microsoft Teams) o direttamente come commento sotto questa attività. Da un lato, se scrivi una domanda in un messaggio personale, molto probabilmente la risposta sarà più rapida, poiché la persona vedrà subito la domanda. D'altra parte, ponendo una domanda in Jira, hai la prova che stai facendo qualcosa, ovvero analizzando il problema. C'è un modo per accelerare questo processo: porre una domanda come commento in Jira e inviare un collegamento a questo commento in un messaggio privato con una richiesta di visione.

6. Aspettarsi troppo dal leader della squadra

Ancora una volta, questo è il rovescio della medaglia del punto precedente. Un team leader è una persona che è a capo di un team di sviluppo. Di norma, la maggior parte del tempo di tale membro del team viene dedicato a vari tipi di comunicazioni. E allo stesso tempo scrive anche codice per non dimenticare di cosa si tratta. Bene, come hai capito, questo è un personaggio molto impegnato. E gli spasmi eccessivi ad ogni starnuto ovviamente non lo renderanno felice. Immagina se ogni membro del team lo bombardasse con una serie di domande. Quindi puoi impazzire, vero? E non sorprende che con molte domande da parte tua ti risponderà a lungo. Cosa puoi fare per ridurre il numero di domande al team leader:

• Studia più approfonditamente la documentazione di questo progetto per ridurre il numero di punti ciechi.
• Fai domande agli altri membri del team. È del tutto possibile che abbiano familiarità con questa funzionalità quanto il lead, o anche di più, perché molto probabilmente uno di loro ha scritto quella funzionalità.

In alternativa, nell'IDE puoi guardare le annotazioni: chi e quando ha modificato il codice l'ultima volta in una determinata riga. In questo modo scopriremo chi avrebbe più ragione a porre questa domanda. Come probabilmente hai già capito, quando fai domande al caposquadra, così come quando fai domande ai colleghi, devi cercare di mantenere la media aurea: non aver paura di fare domande, ma anche di non infastidirle con un numero eccessivo.

7. Paura della revisione del codice

La revisione del codice o revisione del codice è una fase prima del caricamento del codice in un'applicazione comune (in un ramo comune, ad esempio master o dev). Questo controllo viene effettuato da uno sviluppatore estraneo a questo compito, che può, con uno sguardo nuovo, scoprire errori, imprecisioni o mancanze nello stile del codice passate inosservate nella fase iniziale di sviluppo. Se sono presenti commenti, vengono lasciati come commenti ad alcune sezioni del codice. In questo caso, lo sviluppatore che ha eseguito questo compito deve correggere gli errori in base alla revisione (o discutere le sue decisioni con il revisore, magari convincendolo della correttezza della sua decisione). Successivamente, rimandalo indietro per la revisione e così via finché il revisore non avrà più commenti. Il revisore funge da “filtro” prima di caricare il codice. Pertanto, molti programmatori alle prime armi percepiscono la revisione del codice come una critica e una condanna. Non la apprezzano e hanno paura di lei, e questo è sbagliato. È la revisione del codice che ci consente di migliorare il nostro codice. Dopotutto, riceviamo informazioni importanti su cosa stiamo facendo di sbagliato e su cosa dovremmo prestare attenzione. È necessario considerare ogni revisione del codice come una parte dell'apprendimento, qualcosa che può aiutarti a migliorare. Quando una persona lascia commenti sul tuo codice, condivide con te la sua esperienza, le sue best practice. Per quanto mi riguarda, non puoi diventare un buon programmatore senza ottenere una revisione del codice. Perché non sai nemmeno quanto è buono il tuo codice e se ci sono errori dal punto di vista di una persona esperta dall'esterno.

8. Tendenza a soluzioni astruse

Spesso compiti/problemi diversi possono avere diverse soluzioni. E tra tutte le soluzioni disponibili, i principianti solitamente utilizzano quelle più complesse e “astruse”. Ed è vero: se un programmatore alle prime armi proprio ieri ha studiato molti algoritmi, modelli, strutture dati diversi, allora le sue mani non vedono l'ora di implementarne uno. Sì, e voglio, per così dire, dichiararmi. Credimi, anch'io ero così e so di cosa sto parlando :) Ho avuto una situazione in cui ho trascorso molto tempo a scrivere una funzionalità che si è rivelata molto, molto complessa. Poi è stato riscritto da uno sviluppatore di livello Senior+. Naturalmente, ero interessato a vedere cosa e come lo aveva cambiato. Ho guardato la sua implementazione e sono rimasto stupito da quanto sia diventata più semplice. E il codice è diventato tre volte inferiore. E allo stesso tempo, i test per questa funzionalità non sono cambiati e non hanno fallito! Cioè, la logica generale rimane la stessa. Da questo sono arrivato alla conclusione che: le soluzioni più ingegnose sono sempre semplici . Dopo questa realizzazione, scrivere il codice è diventato molto più semplice ed è diventato notevolmente più di alto livello. E allora, quando vale la pena usare modelli e algoritmi, chiedi? Quindi, quando utilizzarli sarà il modo più semplice e compatto.

9. L'invenzione delle biciclette

Questo concetto è noto anche come l'invenzione della ruota. La sua essenza sta nel fatto che lo sviluppatore implementa la propria soluzione al problema per il quale esistono già soluzioni, e molte volte migliori di quelle inventate dal programmatore. Di norma, inventare la propria bicicletta comporterà una perdita di tempo e una diminuzione dell'efficienza del lavoro dello sviluppatore, perché potrebbe non essere trovata una soluzione lontana dall'essere la migliore, o potrebbe non essere trovata affatto. Allo stesso tempo, non si può scartare la possibilità di una decisione indipendente. Il programmatore deve navigare correttamente tra i compiti che possono presentarsi davanti a lui per risolverli con competenza e tempestività, utilizzando soluzioni già pronte o inventandone di proprie. Da un lato, nelle università e nei corsi siamo bombardati da compiti di vario genere che dovrebbero aiutarci a mettere le mani sulla creazione di biciclette. Ma questo è solo a prima vista. Lo scopo, infatti, è quello di sviluppare il pensiero algoritmico e una più profonda padronanza della sintassi del linguaggio. E tali compiti aiutano anche a comprendere meglio algoritmi/strutture e, se necessario, forniscono loro le competenze per implementare i loro analoghi avanzati (ma questo è molto raramente necessario). Nella vita reale, nella stragrande maggioranza dei casi, non è necessario inventare la propria ruota, poiché esistono da tempo analoghi che soddisfano le nostre esigenze. Forse, a causa della tua esperienza, non saprai dell'esistenza delle implementazioni di questa o quella funzionalità di cui hai bisogno. È qui che devi sfruttare il primo punto di questo articolo, ovvero chiedere aiuto a colleghi più esperti. Potranno guidarti (ad esempio, consigliare a Google in quale direzione) o suggerire un'implementazione specifica (determinata libreria).

10. Non scrivere test

A tutti i principianti non piace scrivere test. E i neofiti: anche ai non principianti non piace scrivere test, ma capiscono meglio perché è necessario. Quando sei completamente verde, pensi: perché scriverli? Funziona tutto e non possono esserci errori. Ma come puoi essere sicuro che le tue modifiche non rompano qualcosa in un'altra parte del sistema? I tuoi colleghi non apprezzeranno se porti avanti cambiamenti che disturbano più di quanto traggono beneficio. È qui che i test vengono in soccorso. Più un'applicazione è coperta dai test, meglio è (chiamata anche percentuale di copertura). Se l'applicazione è ben coperta dai test, eseguendoli tutti potresti trovare punti che possono essere interrotti dalle modifiche. E come ho detto nell'esempio sopra, durante il refactoring della funzionalità, i test non hanno fallito, e tutto perché la logica generale non è cambiata. Ciò significa che i test possono anche mostrare se la logica di una determinata funzionalità è cambiata o meno. Quindi, anche se non ti piace scrivere i test, ne derivano indubbi vantaggi e valgono il tempo speso su di essi.

11. Commenti eccessivi

Molti sviluppatori soffrono di perfezionismo e i principianti non fanno eccezione. Ma a volte un effetto collaterale di questo desiderio è che iniziano a commentare tutto e tutti. Anche quello che non serve, perché è 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 una buona cosa, perché il codice risulterà molto più disordinato e difficile da leggere. Cosa succederebbe se il codice fosse stato modificato, ma non ci fosse alcun commento? Si scopre che ci ingannerà e ci confonderà solo. Perché allora un commento del genere? Di solito, il codice ben scritto non ha bisogno di commenti , poiché tutto in esso è già ovvio e leggibile. Se scrivi un commento, significa che hai già rovinato la leggibilità del codice e stai cercando di appianare in qualche modo la situazione. L'approccio migliore sarebbe scrivere inizialmente codice leggibile che non debba essere integrato con commenti. Inoltre non ho potuto fare a meno di menzionare la corretta denominazione di metodi, variabili e classi, ovvero una regola alla quale io stesso aderisco: il miglior commento è l'assenza di un commento e, al suo posto, la corretta denominazione che lo descriva chiaramente o quella funzionalità nella tua applicazione.

12. Cattivi nomi

Spesso i principianti falsificano i nomi di classi, variabili, metodi, ecc. Ad esempio, quando creano una classe il cui nome non ne descrive affatto lo scopo. Oppure viene creata una variabile con un nome breve, qualcosa come x , e quando vengono create altre due variabili denominate n e y , diventa molto difficile ricordare cosa fa x . In questi casi, devi pensare attentamente al codice e studiare questa funzionalità al microscopio (magari usando un debugger) per capire semplicemente cosa sta succedendo lì. È qui che ci viene in aiuto la corretta denominazione nel codice che ho menzionato sopra. I nomi corretti migliorano la leggibilità del codice, risparmiando di conseguenza tempo nella familiarizzazione, perché è molto più semplice utilizzare un metodo in cui il nome descrive approssimativamente la sua funzionalità. Nel codice tutto è costituito da nomi (variabili, metodi, classi, oggetti file, ecc.), questo punto diventa molto importante quando si crea un codice corretto e pulito. Vale la pena ricordare che il nome deve trasmettere il significato: perché, ad esempio, esiste la variabile, cosa fa e come viene utilizzata. E noterò ancora e ancora che il miglior commento per descrivere una variabile è il suo nome corretto. Per uno studio più approfondito dei commenti e della corretta denominazione, ti consiglio di leggere il classico intramontabile: “Codice pulito. Creazione, analisi e refactoring”, Robert Martin . Con questo si conclude la prima parte di questo articolo (riflessioni). Continua…