Steven è un guru del PLSQL, ha all'attivo diversi libri sull'argomento, potete saperne di più seguendo il link (https://www.stevenfeuerstein.com/)
Nel video ci sono una serie di suggerimenti affinchè il codice scritto sia leggibile e sia ben implementato, in modo da evitare errori nella creazione e nelle successive rilavorazioni.
Il primo suggerimento è di ordine pratico, consiglia di prendersi cura del proprio fisico perchè in questo modo avremo maggiore concentrazione e saremo tendenti meno alla distrazione. Ci consiglia di idratarci, di mangiare sano e di fare esercizio fisico. Consiglia di alzarsi periodicamente dalla scrivania per fare delle pause e di fare dei sit-ups ogni qualvolta ci alziamo.
Io aggiungerei di praticare la meditazione mindfulness, è scientificamente provato che migliora la capacità di concentrazione e quindi ci permette di raggiungere lo stato di flow, di completa immersione in quello a cui ci stiamo dedicando.
Passando al codice di suggerisce di evitare di fare hard-coding, cioè evita di martellare delle costanti nel codice, permettile all'utente di inserirle via promt, inseriscile in una tabella o in un file di testo o csv.
Hard-code significa inserire qualcosa nel codice che non può essere cambiato senza modificare il codice. Per esempio variabili di configurazione del sistema o del software, numero massimo di record da elaborare, tempo massimo di elaborazione ecc.
Curare molto la scelta dei nomi delle variabili, a tal fine adottare una convenzione e usare dei prefissi per i diversi tipi di entità (differenziare le variabili ad esempio dai nomi delle colonne delle tabelle da cui si estraggono i dati).
Usare dei nomi significativi per le procedure e i packages, questo vi eviterà di scrivere commenti che potrebbero rendere il codice meno leggibile. Evitare di scrivere commenti nel codice ci permette di avere una procedura tutta in una schermata ed è più comprensibile, evita la necessità di dover fare scroll nel codice.
Data isolation e cioè creare delle procedure per estrarre e manipolare i dati, delle API per l'accesso e la manipolazione dei dati di una tabella. Ad esempio SQLDeveloper genera queste API in automatico (nella voce di menù Tabella/GeneraApi)
Nascondere logiche complesse di estrazioni nelle Table Functions.
Spostare le "Select into" in funzioni e usare bulk collect e for all ogni volta che è possibile.
Single point of definition, cioè definire le funzioni in un solo punto per non avere più punti nel codice che fanno la stessa cosa, in futuro se si dovrà modificare il codice lo si fa in un solo punto. A tal fine creare delle piccole utility da riutilizzare .
Usare dei packages per la gestione degli errori e il logging. Per il logging si può usare una tabella centralizzata che viene aggiornata di volta in volta con errori o log.
Tutto questo al fine di riusare il codice, si risparmia tempo nel creare il codice e nella manutenzione o refactoring.
Non usare VARCHAR2 di lunghezza fissa, in questo modo quando cambiano le dimensioni di una variabile non bisogna modificare il codice. Per questo viene consigliato nel video di usare dei subtype.
Ridurre la lunghezze delle procedure per non rendere illeggibile il codice a chi va a modificare il codice dopo di noi. No spaghetti-code.
Scrivere piccoli packages focalizzati su funzionalità atomiche.
Non superare le 50 righe per procedura e smetterla di scrivere troppo codice SQL
Usare una metodologia top-down
Personalmente ritengo utile rifattorizzare il codice dove necessario quando si apportano delle modifiche allo stesso.
Infine da particolare importanza a testare il codice e nel video viene illustrato come funziona un tool della Quest per gestire i test in automatico.
Nei prossimi post cercherò di parlare più in dettagli di alcuni dei suggerimenti, in modo da rendere disponibili esempi e codice.

