Pausa caffè #43. 6 errori di programmazione che ti impediscono di ottenere il lavoro dei tuoi sogni Come contribuire al software open source per la prima volta

6 errori di programmazione che ti impediscono di ottenere il lavoro dei tuoi sogni

Fonte: Medium Per trovare lavoro come programmatore, devi avere un repository Git. Questa è una delle prime cose che i reclutatori esamineranno. Affinché il tuo repository abbia un'impressione positiva, dovrebbe contenere progetti con modifiche recenti. Mostra solo i progetti di cui sei orgoglioso, non ogni riga di codice che hai scritto. Queste sono le basi per lavorare con un repository. Ricorda che prima o poi qualcuno esaminerà il tuo codice per vedere se sei adatto per l'azienda. Questo sarà un momento decisivo per te. Dopo pochi minuti il ​​recruiter deciderà se invitarti per un colloquio. E qui ci sono sia notizie buone che cattive. La cattiva notizia è che un semplice errore può compromettere le tue possibilità di ottenere il lavoro. La buona notizia è che le persone di solito non vogliono scavare in profondità nel codice. Hanno bisogno di una comprensione generale del tuo codice e della tua architettura. Quindi non devi essere un genio: devi solo essere un buon programmatore. Ecco alcuni errori comuni commessi dai neofiti. Evitali e le tue possibilità di colloquio aumenteranno notevolmente.

Commenti obsoleti

I programmatori hanno opinioni diverse sui commenti. Alcuni li amano, altri li odiano. Non possiamo giungere ad una conclusione comune sull'opportunità di commentare il codice e in quali casi farlo. Ma tutti sono unanimi su una cosa: se hai commenti, dovrebbero corrispondere al tuo codice. Esistono commenti per spiegare il codice. Quando il tuo codice è complesso o poco chiaro, hai bisogno di aiuto affinché i lettori lo capiscano. Inoltre devi modificare il tuo commento quando cambi il codice. Se non lo fai, il tuo commento non sarà più utile. Un commento negativo è molto peggio di nessun commento. A peggiorare le cose, i commenti sono evidenziati nel codice. Gli IDE moderni evidenziano i commenti in un colore diverso per renderli più facili da leggere. Aggiungendo un commento, inserisci il segno "leggimi" nel codice. In questo modo, qualsiasi discrepanza tra il commento e il codice sarà facilmente rilevabile. Scegli saggiamente i tuoi commenti e ricorda di aggiornarli insieme al tuo codice. In questo modo ti serviranno bene.

Combinazione di librerie e linguaggi con gli stessi casi d'uso

Prima del primo colloquio dovevo risolvere un problema di reclutamento. Era una semplice app Web, quindi ho scritto del codice, cercato su Google alcune domande complesse e l'app era pronta. Durante l'intervista, il reclutatore mi ha chiesto perché ho mescolato il codice jQuery con il semplice JavaScript in tutto il codice. La mia risposta? "Umm..." A dire il vero, ho incollato alcuni frammenti di codice da Stack Overflow. Non ci ho pensato molto. Il codice ha funzionato, quindi sono andato avanti. Questo errore è molto comune tra i nuovi sviluppatori. Siamo così concentrati sulla risoluzione dei problemi sul lavoro che non prestiamo attenzione a come lo facciamo. Non diventare uno dei principianti che cade in questa trappola. Esamina ogni riga di codice e assicurati di sapere perché l'hai inserita lì.

Ripetizione del codice

Non ripeterti (DRY) è un dogma della programmazione. Creare astrazioni per il codice ripetitivo è l'essenza della programmazione. Sì, all'inizio può essere difficile. Quando vuoi risolvere un problema, lo fai in ogni modo possibile. Quindi passi ad altre attività e il codice ripetitivo rimane con te. Puoi sbarazzarti di questa abitudine creando una serie di regole per te stesso. Ogni volta che perfezioni una funzionalità, leggi di nuovo il codice e vedi se c'è qualcosa che puoi fare per modificarlo. Ricorda che la prima versione del codice solitamente è sbagliata e puoi migliorarla. Quando noti un codice duplicato, prenditi il ​​tempo per studiarlo. In questo modo puoi capire il modo migliore per riscriverlo (ad esempio, utilizzando un loop o creando una nuova funzione). Se esegui questa pulizia ogni volta, ti ritroverai con un codice più affidabile ed elegante.

Errori non gestiti

È quasi impossibile creare un'applicazione significativa che funzioni sempre perfettamente. Sia che tu stia compilando un database o effettuando chiamate API, si verificano errori. Gli errori non gestiti possono non solo impedire l'esecuzione di singole funzioni, ma possono anche causare il blocco dell'intera applicazione. Anticipare possibili errori è un segno di un programmatore competente. Ogni volta che accedi o aggiorni dati esterni, devi essere preparato allo scenario peggiore. Segnala potenziali problemi in un modo che non renda l'applicazione ingombrante. Ciò consentirà ai lettori del tuo codice (e forse a te) di trovare rapidamente gli errori. Mostrerà anche al reclutatore che puoi scrivere codice coerente.

Mancanza di coerenza

La coerenza è il segno distintivo del software di qualità. Rende il codice più facile da leggere e mantenere. Il codice creato in uno stile uniforme è più prevedibile ed è più semplice valutare le prestazioni del programma. A un livello di astrazione più elevato, la coerenza è difficile da ottenere. Ci vorranno anni per padroneggiarlo, quindi è necessario iniziare ad apprendere questa tecnica il prima possibile. Ricordati di creare titoli utilizzando una sola lingua. Probabilmente dovrebbe essere l'inglese, ma nei progetti personali puoi nominare variabili e funzioni in qualsiasi lingua purché sia ​​sempre la stessa lingua. Se sei coerente, non importa se utilizzi tabulazioni o spazi. Crea o scegli una guida di stile e attieniti sempre ad essa. Dovresti anche usare uno strumento come Prettier . Aiuta davvero a mantenere il codice formattato in modo coerente. Qualunque siano gli strumenti e gli stili che utilizzi, usali in modo coerente. Anche se scrivi un codice errato in uno stile coerente, di solito è meglio di un codice incoerentemente buono perché è molto più facile da risolvere.

Incomprensione degli strumenti

In un progetto tipico, probabilmente dovrai utilizzare qualche libreria esterna. Molti programmatori installano le librerie quasi automaticamente perché vengono utilizzate in ogni progetto. Le librerie esterne sono fantastiche perché rappresentano un modo comprovato per risolvere problemi ricorrenti. Tuttavia, i nuovi sviluppatori spesso non capiscono quali librerie stanno utilizzando e finiscono per aggiungere una libreria sopra un'altra o reimplementare alcune funzionalità esistenti. Ogni volta che installi una libreria nel tuo progetto, leggi o almeno visualizza la documentazione. Controlla i metodi e le proprietà che puoi utilizzare e assicurati di comprendere quali problemi la libreria dovrebbe risolvere e quali richiedono l'utilizzo di uno strumento diverso. In questo modo puoi scegliere gli strumenti giusti per il lavoro e spiegare le tue scelte.

Come contribuire al software open source per la prima volta

Fonte: Jamestucker.dev L'altro giorno ho visto un tweet di Evan Yu (creatore di Vue.js ) su un nuovo repository su cui stava lavorando e mi ha interessato. Ho deciso che volevo contribuire! Il problema è che non ho mai contribuito a progetti open source prima e non sapevo da dove cominciare. Ma non può essere così difficile, vero? Una volta entrato nel repository, mi sono bloccato immediatamente. “Che diavolo dovrei fare?” ho pensato tra me e me. Se eseguo una PR (richiesta pull, richiesta di unione), gli specialisti probabilmente faranno a pezzi il mio codice. Sarò sempre conosciuto nel mondo dello sviluppo come la persona che non sa come lavorare correttamente con l'open source. E la mia carriera finirà. Fortunatamente ho letto un articolo (non ricordo dove) il cui autore consigliava che il tuo primo contributo al repository di qualcun altro dovrebbe essere il più discreto possibile. Potrebbe trattarsi di qualcosa di semplice come correggere un errore di battitura. E così ho fatto. Ho letto la documentazione del repository, ho trovato alcuni errori di battitura, ho aperto un PR ed ecco, Evan ha approvato le mie modifiche. Sono ufficialmente un collaboratore di Vue! Forse dovrei inserirlo nella mia biografia su Twitter?

"È fantastico, ma come posso iniziare?"

Ok, cominciamo: ti mostrerò i passaggi che puoi eseguire per fare la differenza.

1. Trova un progetto

Per trovare ispirazione, pensa alla tua tecnologia o al tuo strumento preferito. Diciamo che lavori con JavaScript e usi molto Gatsby ? Dai un'occhiata al loro repository ! Puoi anche contribuire a uno dei miei repository. Ecco un elenco dei miei progetti frontend. Se hai qualcosa che ami o trovi utile, mi farebbe piacere se lo aggiungessi! Infine, Awesome First PR Opportunities è un gigantesco archivio di progetti open source per principianti. Ci sono progetti in 22 lingue diverse!

2. Decidi come puoi contribuire

Scopri il progetto. Leggi il file Leggimi. Scansione di cartelle e file diversi. Acquisire una comprensione della struttura della base di codice. In questo modo potrai facilmente trovare e correggere l'errore di battitura! Dopo averlo fatto, dai un'occhiata alla sezione Problemi del progetto. Lì troverai un elenco di bug rilevati in precedenza o funzionalità suggerite. Fortunatamente, molti progetti comportano problemi adatti ai principianti. Penso che il tuo primo contributo dovrebbe essere il più sottile possibile, ma se vuoi ottenere il riconoscimento rapidamente, dipende da te. Una volta trovato qualcosa che puoi aggiungere al progetto, dovrai biforcarlo.

3. Creazione di un fork del progetto

Un fork (fork di un progetto) ne crea una copia esatta nel tuo repository Github.

4. Clonare il progetto localmente

Quindi clona il progetto in una cartella locale utilizzando l'URL del progetto.

git clone <project-url>

Qui troverai l'URL. Ora che il progetto è sul tuo computer, aprilo in un editor. Se ritieni che le modifiche richiedano tempo, assicurati di sincronizzare una copia del progetto con l'originale in modo da essere sempre consapevole delle modifiche. Puoi trovare i comandi Git esatti per questo qui .

5. Crea un nuovo ramo per le tue modifiche

È il momento di apportare le modifiche/correzioni! Crea un nuovo ramo in cui avranno effetto le modifiche.

git branch <branch-name>

Puoi chiamarlo come vuoi, ma secondo la mia esperienza sarai in grado di vedere uno schema per denominare i rami nel progetto originale. In questo caso, consiglio di seguire il modello esistente. Un buon nome di ramo per correggere l'errore di battitura sarebbe patch/typo-fix . Puoi passare a questo ramo utilizzando git checkout <branch-name> . Ora apporta le tue modifiche!

6. Apri una PR (richiesta di unione)

Quindi hai corretto un errore di battitura evidente o aggiornato un collegamento non funzionante. Sei orgoglioso del tuo lavoro. Vuoi che il mondo intero sappia che sei uno di quei mitici sviluppatori in grado di programmare, cancellare e guardare Netflix allo stesso tempo. Invia le tue modifiche a un repository Github ramificato utilizzando git push -u origin <branch-name> . Vai al tuo repository Github biforcuto e apri una PR (richiesta pull). Nota: se non hai mai eseguito una richiesta pull prima, guarda questo video di Kent Dodds per scoprire come farlo. Assicurati che il tuo ramo punti al ramo principale del repository di origine. Ora sei pronto per aggiungere dettagli al tuo PR. Assicurati che il titolo trasmetta chiaramente il contenuto del PR. Aggiungi una descrizione: se stai risolvendo un problema esistente, assicurati di includere un collegamento ad esso. Una volta terminata la descrizione, invia il tuo PR per la revisione. Chiunque abbia l'autorità per approvare le PR probabilmente esaminerà la tua domanda entro pochi giorni ed eseguirà una delle seguenti operazioni:

1. Unirà immediatamente le modifiche.
2. Ti chiederà di apportare modifiche.
3. Chiuderò il tuo PR.

Sii paziente poiché il creatore del repository potrebbe essere impegnato con un lavoro a tempo pieno o altri progetti.

Ce l'hai fatta!

Ora sei un collaboratore del progetto open source! Come ti fa sentire? Pronto a creare il tuo concorrente Node.js? Spero che dando un semplice contributo le prospettive per il futuro lavoro open source diventino meno scoraggianti. Per ulteriori informazioni sui contributi open source, consulta le guide open source .