Come sviluppatori, sentiamo spesso frasi cliché lanciate come “Non ripeterti”. Prendiamo idee come questa e corriamo con loro, a volte un po ‘ troppo lontano.

Fare un passo indietro e valutare perché facciamo queste cose è utile. Quindi oggi, diamo un’occhiata a un’ideologia alternativa alla programmazione A SECCO.

DRY è definito (secondo Wikipedia) come:

Ogni pezzo di conoscenza deve avere una singola rappresentazione univoca e autorevole all’interno di un sistema.

Alcuni di questi potrebbero diventare un po ‘ pedanti, ma ciò può essere utile quando si considera qualcosa di simile. Scomponiamo le parti del fraseggio lì.

Ogni pezzo

Che cos’è “ogni pezzo”? Non possiamo mai ripetere un nome di variabile? Un’entità HTML?

Ok, ok. Quindi possiamo ripetere <div>senza molti problemi e non penso che nessuno si offenderà. Ma questo fa apparire la domanda – quando decidiamo che qualcosa è diventato un”pezzo di conoscenza”? In React, un buon esempio potrebbe essere un componente-ma è quella PrimaryButtone SecondaryButtono significa una classe Button generalizzata? La risposta è generalmente considerata “Qualunque cosa la tua organizzazione scelga”, ma questo può ancora lasciare un bel po ‘ di ambiguità su ciò che scegliamo di astrarre.

conoscenza

Questo è un altro punto ambiguo: cosa definiamo come conoscenza? Si consideri un elemento pulsante stile utilizzando alcune classi atomiche e reagire. Se ci vogliono 10 secondi di sviluppo senior per creare, potrebbero non considerare che la conoscenza valga la pena di essere astratta. Ma per uno sviluppatore più giovane che non conosce bene il sistema, quella conoscenza potrebbe essere una buona astrazione. Altrimenti, potrebbero dover dare la caccia alle classi, ricordare a se stessi come funzionano i pulsanti e capire la sintassi per un onClick. La conoscenza è relativa e usarla in una definizione aggiunge ambiguità.

Aggiornamento: Xander ha lasciato il seguente commento qui sotto. Penso che l’articolo faccia un grande lavoro di spiegare che cosa “conoscenza” dovrebbe significare.

Volevo solo lasciare questo qui per le persone che sono interessate.

“DRY riguarda la conoscenza, la duplicazione del codice non è il problema.”
verraes.net/2014/08/dry-is-about-k id

rappresentazione singola, univoca, autorevole

Una rappresentazione “singola” lascia molto a desiderare. Dal punto di vista di un ingegnere devops, una singola rappresentazione potrebbe essere un’intera applicazione di cui hanno bisogno per distribuire. Per un dev frontend, che potrebbe essere un componente. E per un backend dev, che potrebbe essere un metodo su una classe o un endpoint API. Dove viene disegnata la linea?

Abbiamo anche la parola “non ambiguo” – ma come ho appena sottolineato, il resto di questa frase definisce più ambiguità. “Autorevole” ha senso: il tuo codice SECCO dovrebbe definire esattamente ciò che fa ed essere fedele a quella definizione. Tuttavia, questo non è esplicitamente limitato al codice SECCO.

system

Infine, abbiamo il “sistema” mondiale – questo torna alla dichiarazione “singola” di cui abbiamo discusso un secondo fa. Che cos’è un “sistema”? In React, potrebbe essere un componente o un’azione Redux / componente / riduttore. Nel software containerizzato, potremmo parlare di un intero pod o solo di una singola istanza.

Alla fine della giornata, DRY all to spesso promuove la pre-ottimizzazione, che non è necessaria e talvolta danneggia la capacità di scrivere codice. A volte è più difficile modificare un componente astratto per adattarsi a un caso d’uso specifico. Aggiungi molta complessità o rompi quel componente in qualcosa di nuovo, che non è super SECCO. Non puoi conoscere ogni caso d’uso per il tuo componente il primo giorno.

Un’alternativa – Scrivi tutto due volte (WET) programming

Invece, propongo la programmazione WET. Per me la definizione sarebbe:

Puoi chiederti “Non l’ho scritto prima?”due volte, ma mai tre.

Con questa definizione il focus si allontana dall’ottimizzazione prematura e consente invece di ripetere codice simile un paio di volte. Sposta anche l’attenzione su una reazione più intestinale. Ti permette di prendere decisioni in base al caso d’uso esatto che stai guardando. Se stai costruendo un’app web, probabilmente vuoi astrarre i tuoi pulsanti in un componente, perché ne utilizzerai molti. Ma se c’è una singola pagina che ha uno stile speciale (forse una pagina dei prezzi?), quindi non è necessario preoccuparsi troppo di astrarre i componenti in quella pagina. In effetti, con questo sistema, se avevi bisogno di una nuova pagina simile a quella pagina speciale, puoi semplicemente copiare/incollare e cambiare il codice che ti serve. Tuttavia, nel momento in cui ciò accade una terza volta, è il momento di dedicare un po ‘ di tempo all’astrazione delle parti che possono essere astratte.

Vorrei anche aggiungere questa stipulazione (sia per la programmazione a UMIDO che a SECCO):