Riepilogo Tecnico: Benefici dell'Applicazione di Pattern di Design del Software ad Applicazioni Backend in Rust

Definizione del Problema

Sebbene il linguaggio di programmazione Rust offra garanzie di sicurezza a tempo di compilazione, sicurezza della memoria senza garbage collection e un sistema di tipi distinto, esiste una mancanza di ricerca empirica riguardante l'efficacia dei pattern di design del software in questo contesto. La maggior parte dei pattern di design esistenti ha origine dai paradigmi della Programmazione Orientata agli Oggetti (OOP) (ad esempio, i pattern del Gang of Four), che potrebbero non tradursi direttamente nella natura multi-paradigma di Rust. Inoltre, studi precedenti sui pattern di design hanno prodotto risultati controversi riguardo al loro impatto sulla qualità del codice, spesso mancando di dati contestualizzati. Questa tesi affronta il vuoto di comprensione su come specifici pattern di design influenzino la qualità del software e l'enforcement degli invarianti in applicazioni backend di produzione in Rust.

Metodologia

Lo studio impiega un approccio a metodi misti che combina metriche quantitative e analisi qualitativa di esperti per valutare l'impatto dei pattern di design su tre casi d'uso rappresentativi in applicazioni backend di produzione presso Otto GmbH & Co. KGaA.

Casi di Studio

Sono stati selezionati tre casi d'uso distinti per rappresentare comuni pattern architettonici nei backend in Rust:

1. Caso d'uso 1 (Servizio FT9 Detailview): Un servizio con una sequenza lunga e lineare di operazioni che coinvolge molteplici dipendenze e logica condizionale.
2. Caso d'uso 2 (Gestore componente FT9 Tag): Un gestore che si occupa della validazione dell'input di espressioni di dominio specifico ("Dreson") utilizzando stringhe grezze.
3. Caso d'uso 3 (Gestore Lambda Boxfish): Una funzione serverless che coinvolge stato mutabile condiviso, gerarchie di funzioni profonde e gestione implicita degli errori.

Strategia di Refactoring

Due specifici pattern di design sono stati applicati per affrontare i "code smell" identificati:

• Pattern Typestate: Applicato ai Casi d'uso 1 e 3. Questo pattern codifica lo stato di un oggetto nel suo tipo, garantendo che le operazioni siano eseguite solo in stati validi. Sfrutta il concetto di ownership e il sistema di tipi di Rust per imporre l'ordine di esecuzione e prevenire stati non validi a tempo di compilazione.
• Pattern Newtype: Applicato al Caso d'uso 2. Questo pattern avvolge tipi primitivi (ad esempio, String) in una nuova struct per imporre invarianti di dominio specifico (ad esempio, la validazione) immediatamente alla costruzione, aderendo al principio "Parse, don't validate" (Analizza, non validare).

Framework di Valutazione

Il codice refactored è stato valutato rispetto a criteri derivati dal modello di qualità ISO/IEC 25010 SQuaRE:

• Metriche Quantitative:
  • Comportamento Temporale (Time Behaviour): Misurato tramite micro-benchmarking usando criterion-rs per rilevare regressioni delle prestazioni.
  • Analisi Statica del Codice: Le metriche includevano la Complessità Ciclotomica (CyC), la Complessità Cognitiva (CoC), la Difficoltà di Halstead (HDiff) e l'Indice di Manutenibilità (MI).
• Analisi Qualitativa: Sono state condotte interviste semi-strutturate con quattro sviluppatori Rust senior (6+ anni di esperienza, 2+ anni in Rust) per valutare Modularità, Riutilizzabilità, Analizzabilità, Modificabilità, Testabilità e Assenza di Difetti (Faultlessness).

Risultati Chiave

1. Impatto sulle Prestazioni

In tutti e tre i casi d'uso, l'applicazione dei pattern di design ha prodotto nessun degrado statisticamente significativo nelle prestazioni di runtime.

• Caso d'uso 1: Ha mostrato un leggero miglioramento (1,86%) entro la soglia del rumore.
• Caso d'uso 2: Ha mostrato un aumento trascurabile (1,25%) entro la soglia del rumore.
• Caso d'uso 3: Ha mostrato un cambiamento non significativo a causa dell'alta varianza nell'ambiente di test, ma nessuna evidenza di perdita di prestazioni.
  L'overhead strutturale introdotto dai pattern (ad esempio, struct aggiuntive) si è dimostrato, nella pratica, un'astrazione a costo zero.

2. Miglioramenti degli Attributi di Qualità

• Assenza di Difetti (Faultlessness): Entrambi i pattern hanno migliorato significativamente l'assenza di difetti. Il pattern Typestate ha imposto l'ordine di esecuzione e prevenuto stati non validi (ad esempio, la lettura di un file chiuso) a tempo di compilazione. Il pattern Newtype ha garantito che i dati non validi non potessero propagarsi attraverso il sistema, spostando il rilevamento degli errori dal runtime al tempo di compilazione.
• Testabilità: Il pattern Typestate ha migliorato significativamente la testabilità isolando la logica in transizioni di stato più piccole, riducendo la necessità di complessi mocking delle dipendenze. Il pattern Newtype ha permesso di testare la logica di validazione in isolamento.
• Analizzabilità: Il pattern Typestate ha ridotto la Complessità Cognitiva delle grandi funzioni distribuendo la logica in unità più piccole. Tuttavia, gli esperti hanno notato che l'aumento del volume di codice boilerplate (struct e firme di funzioni) potrebbe inizialmente ostacolare la leggibilità per gli sviluppatori non familiarizzati con il pattern.
• Modificabilità: Le modifiche sono diventate più sicure grazie alle garanzie a tempo di compilazione. Tuttavia, modificare la struttura di una macchina a stati richiedeva l'aggiornamento di molteplici stati dipendenti, il che è stato visto da alcuni esperti come un aumento dello sforzo, sebbene altri lo abbiano visto come un positivo enforcement della correttezza.
• Modularità e Riutilizzabilità: I risultati sono stati misti. Mentre il pattern Newtype ha migliorato la modularità disaccoppiando la logica di validazione, il pattern Typestate ha creato stati strettamente accoppiati che erano difficili da riutilizzare in contesti diversi senza un significativo refactoring.

3. Consenso degli Esperti

Gli esperti concordano che i pattern offrano un alto valore per scenari specifici:

• Newtype: Altamente raccomandato per i tipi di dati primitivi che richiedono validazione, offrendo alti rendimenti con bassi costi.
• Typestate: Più benefico per il codice con estese logiche di branching e un alto numero di invarianti. Gli esperti hanno notato che per i flussi lineari, l'overhead del boilerplate potrebbe superare i benefici.

Significato e Contributi

Questo lavoro fornisce la prima valutazione empirica dei pattern di design del software specificamente nel contesto delle applicazioni backend in Rust. I suoi contributi primari includono:

1. Evidenza Empirica: Va oltre le discussioni teoriche per fornire prove basate sui dati su come i pattern Typestate e Newtype influenzino le metriche della qualità del codice e le prestazioni di runtime in sistemi reali.
2. Framework Metodologico: Lo studio stabilisce un framework di valutazione riutilizzabile che combina benchmarking, analisi statica e interviste agli esperti, adattato ai vincoli unici di Rust (ad esempio, riconoscendo i limiti delle metriche statiche nel catturare il carico cognitivo).
3. Raccomandazioni Contestuali: Il documento formula linee guida specifiche su quando applicare questi pattern:
   • Usare Newtype per imporre invarianti su tipi primitivi ("Parse, don't validate").
   • Usare Typestate per macchine a stati complesse con logica di branching, piuttosto che per semplici flussi lineari, per giustificare l'overhead strutturale.
   • Adottare il principio Functional Core - Imperative Shell (FC-IS) in congiunzione con Typestate per massimizzare testabilità e purezza.

La tesi conclude che, sebbene i pattern di design in Rust non migliorino universalmente tutti gli attributi di qualità, essi sono strumenti potenti per sfruttare il sistema di tipi del linguaggio per imporre la correttezza e migliorare la manutenibilità, a patto che vengano applicati con la comprensione dei relativi compromessi tra boilerplate e accoppiamento.