Rigidità

La caratteristica che rende il codice difficile da modificare, in cui una piccola modifica in una parte del codice porta a modifiche a cascata in altre parti.

Non potrebbe esserci un esempio di codice breve, poiché la rigidità non può esistere in un piccolo pezzo di codice in cui non c'è nulla da collegare a cascata.

Il tuo esempio pratico con una query SQL ripetuta cento volte attraverso il codice non è un segno di rigidità. È una semplice duplicazione del codice, che, pur indicando un codice scritto male, non rende la manutenzione eccessivamente complicata. Qualsiasi IDE ti consente di trovare, sostituire il testo in tutti i file in una cartella, apportando una modifica alla query estremamente semplice , l'opposto di quanto affermato.

Immagina un diverso esempio. In origine, il controllo delle autorizzazioni è stato eseguito tramite una query:

SELECT * FROM permission WHERE user=‘1’

I nuovi requisiti è di farlo in questo modo:

SELECT * FROM permission WHERE user=‘1’ AND isDisabled='false'

Esplorando il codice, sembra che la query SQL sia costruita attraverso un builder personalizzato che supporta la nozione di ID utente, ma non è mai stato progettato per gestire isDisabled . Si inizia cambiando questo e si scopre che il builder utilizza un programma di conversione di tipi che gestisce stringhe e numeri, ma non i booleani. Si aggiunge tale supporto, ma l'esecuzione dei test unitari indica che è stata interrotta qualche altra parte del codice. Lo aggiusti, torni al compito originale e scopri che per farlo funzionare, devi cambiare tre altre classi (e i rispettivi test), e ora che la firma di uno dei metodi è cambiata, richiede di modificare altre dieci classi. A causa della rigidità, invece di eseguire una modifica nel codice e una modifica nei test, hai influito sulla metà della base del codice.

Fragilità

class Probe
{
    static bool finished;

    public void Process()
    {
        while (true)
        {
            var measurement = this.ReadNext();
            if (measurement == null)
            {
                Probe.finished = true;
                break;
            }

            var results = this.Analyze(measurement);
            if (results.Relevant)
            {
                this.S3File.Append(results);
            }
        }
    }
}


// Somewhere else in the code, 'Process' is called asynchronously.
// In parallel, the following code is executed every two seconds:
if (Probe.finished)
{
    // Alert the user that the probe finished sending the data.
}

A parte l'uso improprio di un campo statico, il problema principale è che il campo è stato reso pubblico e vi si accede dall'esterno. Controllare che la sonda abbia completato le sue misurazioni in questo modo rende il codice particolarmente fragile; una modifica nella parte interna della classe Probe potrebbe interrompere il codice.

Sarebbe molto meglio rendere il campo privato (e non statico) e lasciare che il chiamante di Process chiami questo metodo in modo sincrono e gestisca di conseguenza il termine del metodo.

L'immobilità

Sebbene il codice precedente possa sembrare un esempio di immobilità, l'odore si applica piuttosto a blocchi di codice più grandi e, quindi, non ci potrebbe essere un esempio di codice breve per esso.

Lo riconosci quando chiedi agli sviluppatori "potremmo aggiungere questa semplice funzionalità al nostro sistema di prenotazione?" e iniziano a evitare il contatto visivo e il più coraggioso di loro urla "Non è il sistema di prenotazione! Per favore, evitiamo quello che è successo due anni fa! Non posso lavorare ancora una volta sedici ore al giorno per tre settimane per ripristinare tutti i nostri sistemi aziendali critici! "

viscosità

// It would be too complex to use our Dependency Injection framework here, so 
// let's create new instances directly for now. It makes it impossible to run unit
// tests for this class, so beware of regressions.
// TODO: Use Dependency Injection and add unit tests.
...