Progettazione del Software: La modificabilità

Ci sono molti modelli e principi di progettazione del software là fuori. Si possono contare, GoF Design Patterns, S.O.L.I.D., YAGNI ecc …
Puoi leggere articoli che descrivono come il codice dovrebbe essere leggibile, semplice e verificabile. Alcuni di questi principi sono in conflitto con gli altri. Cosa fare allora? Cosa scegliere?
Ecco da dove viene l’affermazione “la programmazione è un’arte“. È necessario bilanciare i requisiti in conflitto.
Ma c’è una sola regola che dovresti tenere in considerazione che ti aiuterà a prendere la decisione finale:

Penso che la regola principale sia che il tuo codice dovrebbe essere modificabile.

Stiamo cercando di raggiungere l’obiettivo proprio durante la creazione del software. Se stai costruendo qualcosa per un cliente, il cliente di solito non sa in dettaglio di cosa ha bisogno finché non lo vede.
Se stai lavorando su un prodotto, non sai mai in anticipo come reagirà il mercato a una versione o una funzionalità.
Tutto cambia rapidamente: il team UX cambierà idea non appena vedrà il design in azione, le piattaforme software rilasciano nuove API ogni anno, gli standard web si stanno evolvendo …
Dovresti essere pronto per questo.

Inoltre, la maggior parte dei principi di progettazione (o architettura) del software di cui si sente parlare hanno la mutevolezza al centro.
Rendere il codice testabile significa renderlo più facile da modificare. Perché abbiamo bisogno di unit test in primo luogo? Perché abbiamo bisogno dell’automazione dei test? Per essere più sicuri che il codice funzioni dopo le modifiche apportate. Se un codice non cambia mai, non ha senso scrivere unittest per esso. È molto più veloce e più semplice testarlo manualmente.

Rendere leggibile il codice significa renderlo più facile da modificare. Non ha senso progettare il codice in modo leggibile se nessuno lo leggerà. Quando vogliamo leggere e comprendere il codice? Nella stragrande maggioranza dei casi è quando vogliamo cambiarlo.
(Sì, se stai costruendo un’API, specialmente una pubblica, dovresti anche pensare a quanto sia facile capire il codice. Ma di solito questi concetti si uniscono).

Usare i principi come DRY o YAGNI significa rendere più facile il cambiamento. È molto più facile cambiare il codice quando le modifiche sono incapsulate in un unico posto (DRY) e non c’è codice inutilizzato “per un uso futuro” (YAGNI: you ain’t gonna need it, «non ne avrai bisogno»). È molto più semplice cambiare il codice quando l’oggetto fa una cosa (SRP: singola responsabilità).
Capire quali tecnologie utilizzare e quando migliorano anche la modificabilità.

La mutevolezza è importante! certamente, ma c’è un’altra dichiarazione molto importante da fare, ho delle brutte notizie per te:
Non puoi essere preparato a tutti i possibili cambiamenti.
Non puoi strutturare il codice in modo che tutti i cambiamenti nel mondo siano facili.
A peggiorare le cose, è così facile rendere il codice davvero difficile da modificare cercando di renderlo troppo flessibile.
Quindi alcuni cambiamenti saranno difficili e dolorosi da apportare.
Ma va bene.

Buone notizie: non tutti i cambiamenti nel mondo si verificheranno con il tuo codice. Alcuni cambiamenti sono di gran lunga più probabili di altri.

Quando finisci di progettare il tuo codice (su un foglio, nella tua testa o in uno strumento software), non affrettarti a implementarlo immediatamente. Pensa un po ‘. Pensa a quali cambiamenti sono possibili. Scrivi una lista. Ordinalo in base a quanto sono probabili i cambiamenti.

Quindi dai un’occhiata al tuo design. Gestisce bene i cambiamenti più probabili? È così facile rendere il codice flessibile in un modo di cui nessuno ha bisogno. Ed è così facile dimenticare le modifiche più probabili al codice base.
Ottimizza la progettazione del software per gestire le modifiche più probabili che si verificheranno al tuo codice.
Fallo durante l’implementazione di una funzionalità o durante il refactoring. Cambia il tuo codice , rendendolo più flessibile, ma non dimenticare di pensare allo scopo principale per cui hai iniziato a fare modifiche.