Stavo guardando / ascoltando questo grande discorso di Simon Brown sui monoliti modulari di GOTO 2018.
In questo menziona un termine chiamato Cargo Cult Programming e mi ha davvero colpito.
Recentemente sono entrato a far parte di una nuova azienda con un nuovo linguaggio di programmazione, nuovi strumenti, nuovi processi e un nuovo team. In realtà, è praticamente tutto “nuovo”.
Questo mi ha fatto fare un sacco di apprendimento negli ultimi mesi. Essendo relativamente esperto, mi piace guardare nei “perché” piuttosto che nei “come” quando imparo cose nuove. Quello che ho capito è che questo non è l’approccio più comune.
Quando un utente ha il compito di aggiungere a una base di codice esistente, estendendo la soluzione corrente, molto probabilmente controllerà come è stato fatto in precedenza, copiando l’approccio per la loro soluzione. Possono / seguiranno ciecamente questo schema poiché è come è stato fatto prima. Ulteriori blocchi vengono aggiunti in cima alla torre, senza chiedersi se sia la cosa giusta da fare. Se tutti fanno questo, questo alla fine accadrà.
Questo è dove il termine ‘Cargo Cult Programming’ viene da.
Wikipedia lo spiega in questo modo:
Cargo cult programming è uno stile di programmazione per computer caratterizzato dall’inclusione rituale di codice o strutture di programma che non hanno uno scopo reale. La programmazione del culto del carico è tipicamente sintomatica di un programmatore che non capisce né un bug che stavano tentando di risolvere né la soluzione apparente (confronta il debug del fucile, la magia profonda). Il termine cargo cult programmer può applicarsi quando un programmatore di computer non qualificato o alle prime armi (o uno inesperto con il problema a portata di mano) copia un codice di programma da un luogo all’altro con poca o nessuna comprensione di come funziona o se è richiesto nella sua nuova posizione.
Cargo cult programming può anche riferirsi alla pratica di applicare un modello di progettazione o uno stile di codifica ciecamente senza comprendere le ragioni alla base di tale principio di progettazione. Esempi sono l’aggiunta di commenti non necessari al codice autoesplicativo, l’adesione troppo zelante alle convenzioni di uno specifico paradigma di programmazione o l’aggiunta di codice di eliminazione per gli oggetti che la garbage collection avrebbe raccolto automaticamente.
Immagina uno scenario in cui stai lavorando su un bug, trovando il codice che sta causando l’errore. Non sei assolutamente sicuro di quello che sta succedendo, quindi;
- Google l’errore.
- Si trova una domanda StackOverflow.
- Cerca la risposta più aggiornata.
- Copia e incolla la soluzione nel tuo codice.
- Prova a eseguire il debug per vedere se è stato risolto il problema.
Ha, quindi lo controlli e vai avanti.
Ti suona familiare?
Perché lo facciamo? Perché prendiamo ciecamente questo frammento e lo usiamo così com’è, nella nostra implementazione?
Il caso d’uso probabilmente non è lo stesso, quindi sarei sorpreso se le soluzioni fossero. A parte semplici esempi, comprendere il ragionamento alla base della soluzione è più importante della soluzione stessa. Ci sono molte cose che non puoi fare con qualcosa che non capisci. Non è possibile modificarlo, migliorarlo o testarlo. Non puoi documentarlo e non puoi possederlo.
Tutti noi amiamo ciò che è nuovo, e la gestione soprattutto sembrano come seguendo le tendenze popolari, al passo con il progresso tecnologico.
La maggior parte dei team seguirà ora un approccio Agile. TDD e test automatizzati possono essere molto utili in determinati scenari, l’integrazione continua rimuove gran parte del sovraccarico dal team dell’infrastruttura, i Big Data e l’IA possono migliorare notevolmente la soddisfazione degli utenti e la containerizzazione e più recentemente i microservizi spostano la nostra vecchia architettura monolite in servizi autonomi più piccoli.
Ognuno di questi progressi è brillante a sé stante, e io non condono nessuno di loro. La mia situazione è se abbiamo bisogno di adottarli tutti in tutti i nostri processi e codice? Vediamo post di blog da Netflix, Facebook, Twitter che mostrano come il loro uso ha trasformato il loro modo di lavorare. Se le grandi aziende le ritengono necessarie, non dovremmo farlo anche noi? Questo è dove la programmazione cult cargo alza di nuovo la sua brutta testa.
Dobbiamo capire i problemi con i nostri progetti attuali, perché sono accaduti e come possono essere eliminati in futuro. Sì, questi nuovi processi possono aiutarci con i nostri problemi, ma seguirli ciecamente nella debole speranza che lo facciano non è la via da seguire, né ha alcun senso logico.
cito Microservices specificamente come un sacco di aziende sembrano essere facendo la transizione, citando tali benefici come:
- più Veloci i tempi di sviluppo
- Alta scalabilità
- Facile migliorare
- Facilità di deployment
- squadre Autonome con la libertà di scegliere la tecnologia
Con una lista del genere, cosa c’è da pensare? Saltiamo tutti sul carro!
Aspetta un secondo Wait ci sono degli svantaggi in questo approccio?
- Complessità Architettonica
monolitiche architetture, la complessità e il numero delle dipendenze che risiedono all’interno della base di codice, mentre in microservices architetture di complessità si sposta per le interazioni dei singoli servizi che implementano un dominio specifico
- Complessità Operativa
- Come eseguire il provisioning delle risorse di un sistema scalabile ed economicamente efficiente,
- Come operare con decine o centinaia di microservice componenti in modo efficace senza moltiplicare gli sforzi
- Come trattare con la mancanza di standard e eterogenee ambienti che includono diverse tecnologie e persone con competenze diverse
- Come gestire il controllo delle versioni
- Come monitorare ed eseguire il debug delle interazioni nell’intero sistema
- Come tenere traccia di centinaia di pipeline di distribuzioni di codice e delle loro interdipendenze
Questi sono sollevati dal whitepaper “Challenge of Microservices” di Amazon. Ora non lo so di te, ma gli svantaggi mi sembrano molto più spaventosi dei benefici. Ancora una volta, non sto dicendo che questo non è l’approccio giusto per scendere, ma a meno che questi benefici non superino gli svantaggi cosa stai guadagnando seguendo questo approccio?
Il problema “pubblico”.
È davvero semplice, Smetti di usare la parola chiave Pubblica, interrompi automaticamente la creazione di classi pubbliche. Perché lo facciamo?
Il problema con l’utilizzo della parola chiave public è che ti stai perdendo i vantaggi relativi all’incapsulamento. Perché lo usiamo così tanto? È praticamente la parola predefinita che usiamo quando creiamo classi, tutti gli esempi useranno classi pubbliche, procedure guidate e frammenti implementeranno classi pubbliche. E ‘ ora di smettere. Quante persone hanno un account Facebook pubblico? La maggior parte delle cose in questo mondo sono private, come dovrebbero essere le nostre classi. Rendili privati per impostazione predefinita, e quindi se hai bisogno che siano pubblici, cambiali.
Con grande esperienza arriva grande apprensione.
Più a lungo sei in un campo, meno ingenuo sei a percepire i miglioramenti che un nuovo strumento o processo porterà. La maggior parte delle idee di oggi provengono da decenni di ricerca nel campo che sono finalmente essere abbracciato. Una volta che qualcosa ha guadagnato l’adozione di massa, è più facile sentirsi a proprio agio abbracciandolo completamente. Cioè, se è la cosa giusta da fare.
“Il buon giudizio deriva dall’esperienza e l’esperienza deriva dal cattivo giudizio”
– Rita Mae Brown
Quindi sentiti libero di continuare a setacciare gli interweb per soluzioni e tutorial ai tuoi problemi; continua ad esplorare nuovi linguaggi, framework e implementazioni. Basta essere consapevoli del perché funzionano, piuttosto che semplicemente come. Tutti impariamo dalle nostre esperienze e dai nostri errori, quindi comprendere i fondamenti ti impedirà di continuare sulla stessa strada in futuro.