Gli errori che commettono i junior developer
Rilasciare codice che funziona è il requisito minimo. Non è l'obiettivo.
Una volta ho revisionato una pull request che ha richiesto 45 minuti per essere compresa. La logica era corretta. I test passavano. Ma il codice era stato scritto come se solo l'autore lo avesse mai letto.
Quando ho dato il mio feedback, il developer ha detto: "Però funziona".
Aveva ragione. Funzionava. Ed era esattamente questo il problema.
I junior developer si concentrano spesso sulle competenze tecniche. Ma le lacune reali riguardano spesso le abitudini e la mentalità.
Ecco gli errori sottili che ti rallentano:
Scrivere per se stessi invece che per gli altri Il codice viene letto molto più spesso di quanto venga scritto. Una funzione che scrivi oggi potrebbe essere toccata da tre persone diverse in due anni. Se uno sconosciuto non riesce a capire il tuo codice in 30 secondi, hai fallito.
Copiare il codice senza capirlo Usare Stack Overflow va bene. Copiare un pattern regex senza sapere come funziona è pericoloso. Crei una black box nel tuo codebase. Non potrai fare il debug quando si romperà.
Aggiungere complessità non necessaria I junior spesso equiparano la complessità alla competenza. Applicano design pattern a compiti semplici. L'astrazione non necessaria rende il codice più difficile da debuggare e da modificare. Aggiungi astrazione solo quando senti il dolore della sua assenza.
Ignorare i messaggi di errore I messaggi di errore sono documentazione gratuita. Non correre su Google non appena vedi uno stack trace. Leggi l'intero messaggio. Spesso ti dice esattamente quale riga è fallita e perché.
Chiedere aiuto troppo presto o troppo tardi Non passare tre ore bloccato su un problema da 10 minuti. È inefficiente. Ma non scrivere a un senior solo con uno screenshot e senza contesto. Usa la regola dei 20 minuti: passa 20 minuti a cercare di risolverlo. Documenta ciò che hai provato. Poi chiedi aiuto fornendo quella documentazione.
Ricreare ciò che esiste già Prima di scrivere una nuova utility, cerca nel codebase. È probabile che il tuo team abbia già risolto quel problema.
Messaggi di commit scadenti Un messaggio di commit come "fix bug" non dice nulla al tuo team. Spiega cosa è cambiato e perché. Tratta la cronologia di Git come documentazione.
Trattare i requisiti come leggi immutabili I requisiti spesso trascurano i casi limite (edge cases). Non limitarti a implementare ciò che ti viene detto. Chiedi cosa succede quando le cose vanno male.
Fermarsi al tasto "Merged" La responsabilità non finisce quando la tua PR viene approvata. Segui la tua funzionalità fino alla QA. Monitorala in produzione. Leggi i report degli errori.
La lacuna più grande è la responsabilità. I senior developer non si limitano a scrivere codice. Risolvono problemi senza crearne di nuovi.
Smetti di ottimizzare per il "fatto". Inizia a ottimizzare per il "bene".