Traduzione dell'articolo di Dor Tzur del 23 febbraio 2016 sul sito web thefullstack.xyz

“L'eccellenza non è mai un caso. È sempre il risultato di una forte intenzione, di uno sforzo sincero e di un'esecuzione intelligente. Rappresenta la scelta saggia di molte alternative: le scelte, non la fortuna, determinano il tuo destino. – Aristotele

Tutti noi vogliamo essere bravi in ​​quello che facciamo. Ma pochi di noi dedicano tempo e sforzi per trasformare l'eccellenza in realtà. Essere eccellenti è un duro lavoro, in qualsiasi professione.
Misurare l'eccellenza di uno sviluppatore JavaScript è molto difficile.

Cosa rende un grande sviluppatore JavaScript?

Ci sono molti criteri che potremmo usare per guidare la nostra decisione sul fatto che uno sviluppatore sia eccezionale o meno: La qualità del codice, il rispetto degli orari, i tempi di elaborazione dei biglietti…. nato sono solo alcune opzioni. Anche aiutare gli altri membri del team nei loro compiti potrebbe essere un criterio da considerare.
Non credo, tuttavia, che nessuno dei precedenti fornisca una misura accurata della qualità di uno sviluppatore. Scrivere un capolavoro di codice, ma ritardare il progetto di 2 mesi perché volevi refactoring tutto non aiuterà nessuno, nemmeno te. Allo stesso modo sappiamo tutti che chiudere i biglietti per chiudere i biglietti non ha senso.
Ci sono molte variabili da considerare e sono sicuro che se chiedessi a 10 diversi programmatori cosa pensano sia un grande sviluppatore, otterrei 10 risposte diverse.
Sono sicuro che anche tu stai pensando alla tua definizione di misurazione della qualità in questo momento.
Quindi, dal momento che ho lottato con questa definizione per un po' di tempo, ho deciso di provare a dedicare un po' di tempo ad analizzarla e comprenderla meglio.

“Giù e sporco”

Ho dovuto trovare qualcosa che tutti gli sviluppatori fanno. Per poi essere in grado di classificare le prestazioni di uno sviluppatore in base a "come" lo fanno.
Basare la misurazione dell'eccellenza della professione nel suo insieme su un'attività è troppo semplicistico. Ma lo farò comunque? e cercherò di rassicurarti che l'attività che ho scelto è buona. Questa deve essere un'attività che fa ogni sviluppatore, mantenendo le cose positive separate dalle cose bloccanti.

Tutti gli sviluppatori a volte scrivono codice orribile!
 

Ammettiamolo, tu ed io sappiamo che di tanto in tanto finiamo tutti per scrivere del codice davvero orribile: Codice vergognoso. Codice che speriamo nessuno vedrà mai.
Tutti abbiamo le nostre ragioni per scrivere a volte codice orribile. Non discuterò su quali siano le ragioni valide per scrivere codice orribile, perché le abbiamo tutti. Quindi esaminiamo il nostro elenco di motivi.
Fermiamoci il naso per non annusare l'odore del codice  e andiamo:

Alcuni motivi comuni per scrivere codice orribile

1. La necessità di consegnare in tempo

"Non abbastanza tempo" è di gran lunga il motivo numero uno per scrivere un codice orribile. L'impegno nei confronti di un cliente, un programma serrato o un rilascio in attesa sono tutti oggetti di scena della scena del crimine.

2. Una goccia in un oceano di miseria

Il codice esistente è così orribile che non hai voglia di impegnarti per riscrivere qualcosa di decente. Sai che non c'è niente che tu possa fare per salvare questa orribile base di codice dal collassare su se stessa a un certo punto.

3. "Devo solo apportare questa modifica e andare avanti"

Come sviluppatori, a volte ci troviamo a programmare in paesi stranieri. Immagina di dover scrivere o modificare alcune righe di codice in un altro progetto.
Ovviamente la persona con la conoscenza effettiva di questo progetto è in congedo e nessun altro è disponibile per la revisione del codice. 'Impegna', spingi' il cambiamento e prega che ci sia stato un numero sufficiente di test unitari per garantire un minimo di sicurezza e qualità.

Diventare reale

Quindi abbiamo tutti scritto un codice orribile. Questo ci rende tutti cattivi sviluppatori?
Ovviamente no. Dal momento che tutti lo fanno di tanto in tanto, l'attività in sé non indica nulla di tangibile. Tuttavia, nel corso degli anni sono arrivato a capire questa sorprendente verità sugli sviluppatori.

Le commento il modo in cui ci comportiamo quando scriviamo un codice orribile è l'ultima cartina di tornasole per misurare l'abilità di uno sviluppatore.

È strano, ma è vero. Essere consapevoli del fatto che il codice che stai scrivendo in questo momento è orribile e i passaggi che stai adottando per evitare che si ripeta in futuro, dice molto su come codifichi e come tratti il ​​codice in generale.

Che cosa ha a che fare il codice orribile con la misura di eccellenza di uno sviluppatore?

Tutto !
Facciamo alcuni esempi:
Rum ha scritto un codice orribile oggi. Ron non era felice. Un fastidioso problema di ereditarietà di 5° livello nel modello Backbone ha impedito a Ron di modificare una singola riga di codice senza rompere tutto.
Ron ha aggirato il problema scrivendo un codice che fa davvero schifo. Ma tutti erano felici perché Ron ha consegnato in tempo. Tutti... tranne Ron.
Ron ha parlato con il suo caposquadra di quello che è successo. Insieme sono andati avanti e indietro su come risolvere questo problema. Hanno deciso che spezzare la catena dell'eredità in moduli componibili piatti era probabilmente la migliore linea d'azione.
Ron ha quindi chiesto del tempo per consentirgli di implementare il refactoring di cui lui e il suo team leader avevano discusso.
Roger ha scritto anche un codice orribile oggi.
Ha parlato al suo amico sviluppatore dello straordinario trucco che ha sviluppato per aggirare il problema dell'eredità di 5° livello. È riuscito a aggirare l'intera architettura, mettendo il suo codice nel posto giusto e quindi consegnando in tempo.
Ruggero era molto felice. Non sono necessarie ulteriori azioni.

Le 4 classi di sviluppatori JavaScript

Possiamo prendere gli atteggiamenti degli sviluppatori di cui sopra e classificarli in 4 categorie: da pessimi a eccellenti.

Barney – Un cattivo sviluppatore JavaScript

A Barney non importa di aver scritto un codice orribile. L'unica cosa che gli interessa è portare a termine il lavoro in tempo. Non importa nient'altro. Se funziona, funziona.
Eppure Barney scrive un codice orribile che a volte impedisce il progresso dell'intero progetto. Anche se il codice funziona, interrompe così tante cose sul suo percorso che è un disastro in termini di regressioni. Barney non si interroga e non pensa di avere cose da imparare. Crede di sapere già tutto di JavaScript, abbastanza comunque per far avanzare i progetti a dovere.

Bill: uno sviluppatore JavaScript mediocre

Bill non sa che sta facendo un codice orribile. Segue le convenzioni e le regole della squadra e quindi pensa di fare tutto bene. Ma non ci vuole tempo per comprendere appieno la struttura dell'intero progetto e come interagiscono le diverse componenti.
Il risultato finale, sfortunatamente, è un mucchio di codice mal strutturato e fragile.
Bill non consulta nessuno prima di aver fatto scelte architettoniche di grande impatto. Scorre l'argomento. Ha letto 3 post sul blog un anno fa che da allora hanno guidato le sue decisioni.
Dico spesso che scavare nel codice di Bill è come correre attraverso un campo minato. Un passo falso e tutto ti esplode in faccia.

Roger – Un buon sviluppatore Javascript

Abbiamo già incontrato Roger. Completamente consapevole che sta scrivendo un codice orribile. Sa come sarebbe stato il codice se avesse scritto un buon codice. Si dà una pacca sulla spalla e passa a scrivere quell'orribile pezzo di codice.
Il principale difetto di Roger è che non cerca di cambiare nulla. Fa quello che gli è stato chiesto di fare e lo fa bene. Ma Roger ha preferito lasciare le cose come stanno invece di prendersi il tempo e fare lo sforzo per cambiarle.

Ron – Un eccellente sviluppatore Javascript

Ron è un eccellente programmatore. Ma a volte scrive ancora un codice orribile.
Ciò che distingue Ron è che mentre scrive il codice puzzolente, pensa a come assicurarsi che non accada di nuovo. Che non si ripeta per lui, ma nemmeno per nessun altro. Ron pensa a quale tipo di refactoring sarà necessario e quali metodi devono essere modificati o migliorati.
Ron quindi agisce in base alle sue scoperte, agendo per mettere in moto il cambiamento.

La dura verità:

Ho una confessione da fare:

Sono Ruggero. Ma sono anche Ron.

E sono sicuro di aver spesso lasciato aggiunte salate inconsapevolmente in più di un'occasione.
Onestamente, non credo di essermi mai comportato come un cattivo Barney, ma chissà.
Tutti andiamo e veniamo in un continuum di eccellenza. A volte siamo mediocri, a volte siamo bravi o eccellenti. Cerca sempre di non essere cattivo.
È chi finiamo per essere la maggior parte del tempo che ci definisce come sviluppatori.
A dire il vero, il passaggio dal mediocre al buono richiede che uno sviluppatore acquisisca più conoscenza ed esperienza tra le altre cose. Ma per fare il salto da buono a grande devi solo cambiare una cosa: Atteggiamento .
Ricordati che:

“Prima di poter essere grande, devi essere bravo. Prima di poter essere buono, devi essere cattivo. Ma prima ancora che tu possa essere cattivo, devi provare. – Arte Williams

Traduzione dell'articolo di Dor Tzur del 23 febbraio 2016 sul sito web thefullstack.xyz