Il culto del carico è inevitabile

È incontrovertibile che i nuovi sviluppatori non possano fare a meno del culto del carico.Semplicemente non hanno imparato abbastanza dello stack per capire davvero cosa sta succedendo sotto il cofano e perché le cose devono essere fatte in un certo modo.

Ad esempio, in uno dei miei primi corsi di programmazione abbiamo appreso che in Java il punto di ingresso al programma è:

public static void main(String args) 

Ci sono voluti anni per arrivare al punto in cui capisco ogni parte di quella firma del metodo.Anche se mi fosse stato spiegato in quel momento, non l’avrei capito.Avrei dovuto capire la visibilità del metodo, la classe rispetto ai metodi di istanza, i tipi di ritorno, i tipi di parametri, gli array (al contrario di elenchi/vettori), gli argomenti della riga di comando (e il modo in cui vengono analizzati dalla shell) e vari dettagli sull’implementazione di Java.

E va bene.Si scopre che non hai quasi bisogno di capire niente di tutto ciò per scrivere programmi a riga di comando o persino GUI in Java.

Non ci aspettiamo che i nuovi sviluppatori conoscano i dettagli di ogni decisione che prendono.Semplicemente non hanno programmato abbastanza a lungo per capire ogni dettaglio su ogni parte dello stack.

Né ci aspettiamo che sappiano che git memorizza i commit in un grafico aciclico diretto e ogni ramo è un puntatore a un nodo nel graph.It è abbastanza buono da poter fare git checkoutegit commit e andare avanti con il loro lavoro.Ed è abbastanza buono se seguono una regola come “mai unione rapida “(o”sempre unione rapida”).

Ma anche per gli sviluppatori senior è inevitabile.Quale dev senior capisce davvero tutti i comandi git che devono cercare su Stack Overflow?O la parte awk e sed del one-liner che hanno cercato ieri su GitHub?O ogni intestazione nella risposta HTTP con cui rispondono le API dell’applicazione Web?O quando utilizzare HTTPS rispetto all’URL SSH dal repository GitHub?O come configurare al meglio la tua istanza PostgreSQL locale?O la tua istanza Neo4j?O come eseguire il debug della configurazione rvm/rbenv/chruby/virtualenv senza spazzarla via e ricostruire da zero?

L’unico modo per non caricare il culto è sapere tutto.E nessuno sa tutto.

La coltura del carico è buona

La coltura del carico è buona una volta usata responsibly.It ci salva dal dover sapere tutto.Se usato bene, è l’atto di sfruttare l’esperienza conquistata a fatica di tutti gli altri sul campo.Probabilmente, usando qualsiasi astrazione senza capire come funziona (che è l’intero punto dell’astrazione!) è la coltura del carico secondo la definizione di Lippert.

Inoltre, la coltura del carico è spesso una buona scelta.”Queste persone sembrano sapere cosa stanno facendo, quindi seguirò il loro esempio”, è una strategia perfettamente razionale.

Infatti, la comunità di programmazione incoraggia attivamente la coltura del carico.Quando diciamo alla gente, “non usare stato globale,” o, “seguire PEP8,” stiamo dicendo loro di cargo cult.Ad esempio, uno sviluppatore capirebbe idealmente i modi sottili (a volte non così) in cui lo stato globale può morderti, ma finché non c’è la comprensione, è meglio evitarlo.

Alcuni altri grandi usi della coltura del carico:

• “Convenzione sulla configurazione” come si vede in Rails (e nei suoi miriadi di cloni), Django e Ember.js
• guide di Stile e i loro strumenti, come Rubocop, JSLint e Auto PEP8
• Molti strumenti di analisi statica, come CodeClimate, Puzzano, Flay, e Flog
• Il 12factor linee guida app
• Codice odori

Come cargo cult responsabilmente

Ovviamente, il carico culting ha alcuni svantaggi, ma ora abbiamo visto un po ‘ i lati, troppo.Ci piacerebbe utilizzare strumenti e tecniche che portano a termine il lavoro ora, senza dover sempre comprendere appieno perché funzionano.Invece di evitare del tutto il culto del carico, come possiamo efficacemente il culto del carico?

L’unico grande avvertimento: il rischio intrinseco del culto del carico è che non sarai in grado di prevedere cosa andrà storto, o anche la classe di problemi che potresti incontrare, perché fondamentalmente non capisci le decisioni che stai prendendo.Detto questo, ecco alcuni suggerimenti.

Scrivi test

Puoi scrivere test automatici per assicurarti che il tuo codice funzioni come previsto, anche se non capisci perché il codice funziona.Un semplice esempio potrebbe essere se si copia e incolla un algoritmo di ordinamento da Stack Overflow, è possibile scrivere un test per assicurarsi che funzioni.

Fai attenzione, però, perché i test non sono così bravi a dimostrare che non ci sono effetti collaterali imprevisti o edge cases.In l’esempio dell’algoritmo di ordinamento, non saprai di quali casi limite devi preoccuparti.

Refactoring senza pietà

Più pulito mantieni il codice, più facile sarà ragionare su quando una decisione culted cargo deve essere cambiata.E ricorda, non puoi refactoring in modo efficace senza test.

Isolare il codice culted del carico

Quando possibile, isolare il codice culted del carico in una classe o in un modulo.Più puoi isolarlo, più limiti il suo potenziale danno.Inoltre, più è isolato, più facile sarà sostituire o riscrivere una volta capito di più.

Non caricare cult in parti critiche della tua app

Ad esempio, se l’alta concorrenza è una necessità assoluta per la tua app, probabilmente non puoi farla franca copiando del codice di threading da Stack Overflow.Anche la scelta di un linguaggio che gestisca intrinsecamente bene la concorrenza (come Elixir, Go o Clojure) non risolverà magicamente il tuo problema.Sfortunatamente (o fortunatamente), dovrai davvero scavare e imparare qualcosa.

Non caricare il culto se il fallimento porta a cose brutte

Se la sicurezza, la privacy,il denaro, ecc. sono a rischio, non cargo culto.Come esempio ovvio,se il pace-maker di qualcuno esegue un certo C one-liner che hai copiato da Stack Overflow, sai dannatamente bene perché il tuo piccolo trucco funziona e quali sono i casi di fallimento e gli effetti collaterali.

Evita la coltura del carico quando si tratta di input variabili

Ad esempio, se non conosci awk super bene e l’input al tuo awk one-liner verrà dall’input dell’utente, è probabile che si rompa.Se riesci a prevedere le diverse forme che il tuo input può assumere, ciò ti aiuterà, ma dovresti tenere presente che è probabile che si rompa su casi di input che non sei stato in grado di prevedere.

Monitora in produzione

Solo perché funziona sulla tua macchina, non dare per scontato che funzionerà in produzione dove l’ambiente è diverso e gli utenti fanno cose che non hai mai considerato.Il monitoraggio di errori, eccezioni, errori di asserzione e prestazioni consente di sapere se qualcosa non va prima che gli utenti, i clienti o il capo se ne rendano conto.

Revisione del codice, coppia di programmazione, strumenti di analisi statica, ecc.

Ottieni altri occhi, virtuali o meno, per guardare il tuo codice.La programmazione delle coppie e la revisione del codice sono esempi ovvi, ma anche gli strumenti di analisi statica (ad esempio CodeClimate) possono essere utili.Oltre a rilevare errori evidenti, sono particolarmente utili per indicare il codice che potrebbe non funzionare sempre come previsto.

Passa a una comprensione più profonda

Iniziando con la coltura del carico, quando decidi di immergerti in profondità nel soggetto avrai già un certo contesto.Il percorso verso una comprensione più profonda può essere lo studio autonomo, il mentoring, la programmazione delle coppie o semplicemente farlo da soli per il gusto dell’apprendimento.

Questa è una vecchia notizia

I suggerimenti elencati sopra sono probabilmente tutte le cose che hai sentito prima.Questo perché lavoriamo tutti con una conoscenza limitata.Siamo tutti cult cargo tutto il tempo e abbiamo sviluppato intuizione, tecniche e linee guida in modo da poter andare avanti con conoscenza parziale e limitare i danni che possiamo fare.Piuttosto che mai cargo cult, i buoni sviluppatori imparano a cargo cult in modo efficace.