Non Particolarmente Magnifico
A volte (facciamo sempre va), guardo i metodi di sviluppo software "moderni" e penso... ma che cazzo stanno facendo?
Ok, vediamo di spiegarci. Io sono cresciuto nei "vecchi" tempi, quando tutto quello che avevi era un computer davanti, dei libri o della documentazione sottomano e basta. Se volevi scrivere del codice, facevi scrocchiare le nocchie e cominciavi a digitare. E se ti venivano dei dubbi, dovevi solo acchiappare il librone con i comandi e cominciare a leggere.
"Domandare un'opinione o un suggerimento" in molti casi significava dover andare fisicamente da qualcuno, spesso trasciandosi dietro una paccata di floppy o un paio di scatoloni con l'ultimo printout del codice e "copiaincolla" di codice di esempio significava doverlo ridigitare in toto da una copia cartacea.
Se avevate bisogno di libreria di terze parti, dovevate prima di tutto OTTENERE le fottute librerie, il che molto spesso significava pagare per averle e poi aggiungerle al vostro progetto, ed una gran parte dello "sviluppo" di quel progetto era in fatti la creazione e manutenzione di una collezione di librerie e funzioni di utlita' che erano fatte su misura.
E poi fare copie di backup di tutto ovviamente.
Oggi... Il tipico sviluppatore lavora in genere cercando schifezze su StackOverflow, facendo copiaincolla di spezzoni di codice schifoso che molto spesso non funziona o non fa quello che gli serve, poi cerca ancora, altro copia-incolla, poi scarica una carrettata di immondizia da questo o quel sito (guardare come e' fatto il codice e' al di la' delle sue possibilita', dato che nella maggioranza dei casi non lo capisce ne' gli interessa di capirlo), e continua finche' il codice che ha messo insieme in questo modo sembra quasi che faccia quello che gli interessa. A quel punto dichiara finita la giornata e si trasferisce nel vicino baretto fico per un cappuccino e apparire fico con il macbook.
E poi ci si domanda come mai ci sono cosi' tanti bachi di sicurezza in cose inutili come routers, switches e software che e' usato da un baziliardo di macchine intorno al mondo.
Tanto tempo fa c'erano cose come Test & Debug, che richiedevano lunge e tediose sequenze di operazioni ripetute ogni volta che si voleva essere sicuri (o ragionevolmente certi) che le cose fossero in grado di funzionare. Queste procedure richiedevano prima di tutto il raccattare tutto il codice scritto da tutti gli sviluppatori, se erano piu' di uno ovviamente, quindi compilare il tutto. E di norma non si riusciva manco a finire la prima fase senza che qualche cosa andasse completamente in malora. Percui la prima fase era, capire perche' cazzo questa roba non si compila. Poi si procedeva con l'uso "normale", cioe' vedere se il codice fa quello che dovrebbe fare poi l'uso "anormale", cioe' simulare quello che un gatto potrebbe fare se lasciato libero di scorrazzare sulla tastiera. Tutto questo per verificare che si fossero corretti i bachi che si volevan corretti e che non se ne fossero aggiunti ulteriori sempre nelle stesse cose. E poi si trattava di cercare di capire esattamente cose si fosse rotto tra la fase 1 e la 2. Tutto questo di solito richiedeva diversi giorni o addirittura delle SETTIMANE.
Oggi... Gli sviluppatori moderno non fanno "debugging" perche' non sanno neanche che cappero significa, e non fanno nemmeno 'testing', per quello hanno delle "procedure automatiche" che non falliscono mai perche' sono progettate per testare solo quello che si aspettano e non quello che non si aspettano ovviamente. Ecco perche' ci ritroviamo con nomi utenti e password hardwired e di default e nessuno controlla mai cosa la gente digita nei campi.
Ho detto che una larga parte dello sviluppo era costituito dalla costruizione e manutenzione di librerie e funzioni di utilita'? Spesso un'intero gruppo di sviluppatori era specificamente impiegato solo per questa attivita'. Ed ogni volta che c'era un aggiornamento di quella roba, tutto doveva essere ricompilato per essere sicuri che continuasse a funzionare. Ricordo che per risolvere un piccolo problema (uno spazio in una stringa), l'intero ufficio spese una settimana per ricompilare e ri-testare tutto, dato che il problema era in una libreria che era usata praticamente dappertutto.
Oggi... La procedura 'normale' e' sempre di scaricare dalla rete l'ultimissimissima versione di qualunque merda si stia usando. Gigabytes di roba per 'hello world'. Ed ovviamente, tutto e' fatto sul sistema di produzione. In questo modo non si puo' mai dire se il sistema di produzione usa la stessa versione di schifezze che tu stai usando sul tuo lapdog demmerda, e quando qualche cosa va' male, lo fa in modo catastrofico.
E dopo queste frizzanti reminescenze, parliamo di NPM.
Lo sapete che roba e' NPM, non mentite. E se veramente, VERAMENTE non lo sapete, siete fortunati. NPM sta per Node Package Manger. Che cappero e' Node? E' un "motore" javascript che e' usato da tutti gli sviluppatori "del giorno" per eseguire il loro codice che, in teoria, dovrebbe essere superefficiente e portatile. Ma non lo e'.
Ora, di solito, un linguaggio di programmazione e' sviluppato in tal modo che le funzioni e librerie di "base" sono.. hemm... alla base del linguaggio. E poi si possono espandere aggiungendo librerie extra. Per qualche strano motivo Javascript, nonostante sia in giro da quasi 30 anni, sembra che sia mancante di parecchie funzioni di base, e queste sono, ovviamente, sviluppate come librerie "esterne". Il che significa in pratica che ogni volta, per ogni progetto, bisogna scaricare dalla rete pezzi di codice che sono usati per migliaia di operazioni di base. Il che significa anche che se qualche cosa "entra" dentro quelle librerie, o "scompare" dalle stesse, sono dolori. E non si puo' prevenire perche' e' implicito nel modo come l'intero sistema e' organizzato.
Non dovrebbe essere una sorpresa quindi scoprire che il sistema che e' usato per gestire e mantenere le librerie usate da Node (i famosi Packages) sia nelle mani di un gruppo ufficiale costituito da note e rispettate universita' ed organizzazioni senza fini di lucro i quali hanno mandato di assicurare che le librerie contengano solo codice verificato ad i massimi standard per garantire la sicurBWAHAHHAHAHAHAAHAHHHAAHHHHHH....
No, scusate, vi sto perculando. No. Purtroppo. No.
Quello che costituisce sostanzialmente l'anima e la vita di un numero astronomico di progetti in tutto il fottuto mondo e' nelle mani di un branco di pagliacci che non hanno nessun sistema di controllo, non forniscono nessuna garanzia e, recentemente, hanno deciso di ottimizzare il loro "business" licenziando una pletora di sviluppatori.
Inoltre, pare che le qualifiche per aggiungere o rimuovere del codice da tutte quelle librerie siano anche piu' basse di quelle richieste per acquistare un'arma negli Stati Uniti (essere in grado di stare eretti e non sbavare troppo). Non e' passato tanto tempo quando una testa di cazzo di sviluppatore decise di rimuovere una paccata di roba dai repositori, provocando una catastrofe a livello mondiale con migliaia di applicazioni che hanno smesso di funzionare perche' non erano in grado di trovare le librerie che avrebbero dovuto usare.
A questo punto, voi potreste aspettarvi che nessuno con un grammo di cervello vorrebbe anche solo toccare con un bastone quella roba. Bene, quindi non conoscete $noifacciamosulserio. Un'altra societa' che cercava disperatamente di essere 'trendy'. Cosi' trendy che potevano solo usare le ultimissime cose.
Percui cominciarono a costruire questa... cosa... usando Node. Ovviamente.
Ed ovviamente applicarono le Magnifiche Eclettiche Regole Di Applicazione (merda), che significa: ogni volta che si fa un rilascio, per prima cosa si zappa via tutto, poi si scaricano tutti gli aggiornamenti di tutte le librerie (diversi gigabytes) e poi si scarica il codice dal repositorio. Poi si riavvia tutto e si prega che non ti scoppi in faccia.
Dopo un numero di "esplosioni", cominciarono ad essere un pelo irritati con questi dannati utenti, sapete, questo tipo di gente che solo perche' vi paga dei soldi buoni per il privilegio di farvi da beta-tester del vostro codice, pensano di poter pretendere cose come... no so.. che il software in effetti funzioni? E faccia quello che vogliono loro? Suvvia...
Ecco percui che domandarono il nostro aiuto per risolvere il problema.
Ok, uso i termini "domandarono" ed "aiuto" in modo molto generico, quello che in effetti successe e' che ci ordinarono perentoriamente senza mezzi termini che o sistemavamo il problema o se ne andavano. Ovviamente noi cominciammo subito a stappare lo spumante, perche' l'unico modo di "sistemare" il problema sarebbe stato quello di buttarli fuori dal sistema e non farceli piu' rientrare. Ed ovviamente il manglement non era molto propenso alla cosa. Loro erano piu' propensi a prendere dei soldi, dato che avevano appena speso un botto di quatrini per comperare tutte queste societa' che adesso portavano i loro clienti piu' scadenti dei quali non sapevamo che farci, dovevano in qualche modo recuperare l'investimento no?
Onde per cui si comincio' a far girare delle idee. Tipo: implementare un qualche tipo di sistema di controllo del codice e convincerli a fare dei TEST prima di zappare via tutto.
Io ci tenni a ricordare a tutti che $noifacciamosulserio usava gia' un sistema di controllo del codice nella forma di Git, e per quanto riguardava il 'testing'... questo era fatto (secondo loro) su ogni singolo fottuto laptop di ogni singolo fottuto sviluppatore, probabilmente con diverse versioni di ogni singola fottuta libreria che questi usavano nel loro sistema. E quindi 1. il fatto che vi sia un sistema di controllo del codice non implica che il codice funzioni, solo che sei in grado di prednere la versione precedente. O Una versione precedente. E 2. che i test automatici testano solo quello che gli programmi di testare, non possono di certo testare per cose inattese, il tipo di cose che i loro clienti per esempio possono fare.
E per ultimo, che zappare via tutto e riscaricare le ultime versioni e' un ottimo modo per avere roba indesiderata dentro al sistema. Al punto che l'intero ambiente dovrebbe essere considerato "non sicuro" per l'uso.
E mentre stavamo discutendo della cosa, arrivo' la novella che uno dei nostri sistemi stava sputando malware ed era coinvolto in un qualche DDOS. E chi pensate che fosse? Yep! Apparentemente l'ultimo giro di "rilasci" aveva scaricato dalla vastita' della rete anche qualche cosa che sarebbe stato meglio non scaricare. E prima che tu possa dire "uops" noi applicammo la Procedura Standard del caso: brucia tutto. Dopo di che, dato che vi era una chiara violazione di sicurezza, si comincio' una completa analisi dell'intera cosa. Analisi per la quale si domando' in sostanza "che cosa cazzo state usando e perche'".
E come potete immaginare, quelli non avevano idea di cosa il 90% del loro codice facesse o perche'.
La loro procedura standard era "questo codice (l'ho scaricato da CodeWarriors) richiede questa libreria di 600Mb, scarichiamola ed importiamola". Lascia perdere che quello che gli serviva era UNA funzione che probabilmente avrebbe potuto esssere realizzata con 20 linee di codice. Chissenefrega? Loro no di sicuro. In ogni caso, dato che la cosa era a quel punto nelle mani del Responsabile di Sicurezza, io trasformai NPM in NMP (Not My Problem). Non ho idea se abbiano mai finito la 'revisione del codice' e con quali risultati.
Davide
12/04/2019 16:11
