Prima venne l’ottimizzazione: le reti di computer erano poche e per addetti ai lavori in camice bianco.

Io programmavo in C, e non mancava mai qualche punto critico in assembler messo con il preprocessore pragma direttamente in mezzo al codice C.

Allora i compilatori non erano ottimizzati come quelli odierni, oggi questa pratica sarebbe inutile.

Poi vennero le reti di computer, e si iniziò a parlare di concorrenza, di semafori, di prenotazione delle risorse, di lock.

Si ottimizzava ancora, badando ad una minima scalabilità delle risorse condivise. Parliamo di poche decine di client.

I linguaggi e i processori crebbero rapidamente, si arrivò al punto che i linguaggi compilati erano un freno alla creatività dello sviluppo. Linguaggi lenti, farraginosi, ma meglio in grado di affrontare la realtà che cambiava vennero fuori.

Internet iniziò a dominare la scena, presto le CGI vennero rimpiazzate da Perl e PHP. L’ottimizzazione spesso consisteva nel scrivere un cuore calcolatore direttamente in C e chiamarlo dal linguaggio di scripting quando c’era necessità di elaborare.

L’hosting divenne più democratico, ci giravano però soltanto i linguaggi di scripting più diffusi. Ottimizzare il codice divenne più teoria che pratica: bastava evitare castronerie come mettere le query dentro ai loop e tutto andava bene.

Alcune applicazioni web iniziarono ad avere successo: con la gloria giunsero immediati i problemi, non si trattava di ottimizzare, ma di scalare.

Database performanti vennero migliorati in ottica multiprocesso, si iniziò a scrivere architetture per distribuire i carichi.

L’ottimizzazione divenne sempre meno pressante, si iniziò ad usare lo stesso linguaggio per i client e i server: javascript.

La scalabilità pretese che molti soggetti ripetessero le stesse operazioni, nello stesso modo, in zone diverse di internet.

Si iniziò a astrarre tutto, dai server hardware al cloud, dal cloud alle architetture a micro servizi.

Oggi l’ottimizzazione si fa in rari casi, quando ci sono di mezzo elaborazioni molto costose o che necessitano di estrema rapidità.

La scalabilità bisogna farla sempre, o il prodotto non scalerà e resterà il miglior prodotto del vostro condominio.

Però ancora mi piace soffermarmi sul codice, e renderlo più veloce, anche se servirà a poco.