Contattaci

[contact-form-7 404 "Non trovato"]

Le 4 Regole del Simple Design

le 4 regole del simple design
  • Data: 22 Gennaio 2019
  • Autore: Giuneco
  • Categorie

  • Giuneco Tech

    Il nostro settore richiede uno studio continuo e una forte attenzione all’innovazione. Incentiviamo quindi dei programmi formativi annuali per tutti i componenti del team, con ore dedicate (durante l’orario di lavoro) e serate formative sia online che in presenza. Sponsorizziamo eventi, sia come partner che semplicemente come partecipanti, e scriviamo articoli su quello che abbiamo imparato per essere, a nostra volta, dei divulgatori.

    Vai alla sezione Team
  • La Nascita delle 4 Regole del Simple Design

    Negli anni ’90 Kent Beck ha descritto per la prima volta queste regole nel suo libro “Extreme Programming Explained” sull’onda di una discussione sul Wiki di Ward Cunninham. Molte altre persone hanno condiviso le loro esperienze nell’utilizzo di queste regole, tra cui Joe Rainsberger e Ron Jeffries, chiamandole “Le Regole di Kent Beck”. Nel 2014 Corey Haines ha pubblicato il libro “Understanding the 4 Rules of Simple Design” dove usa esempi per esplorare e spiegare le regole, riportandole di nuovo alla ribalta.

    LE REGOLE

    Un buon software deve soddisfare i seguenti requisiti (ordinati secondo “Understanding the 4 Rules of Simple Design” di Corey Haines):

    1. Passare tutti i test
    2. Esprimere lo scopo del programmatore
    3. Non contenere duplicazioni
    4. Minimizzare il numero di classi e metodi

    PASSARE TUTTI I TEST

    Se non riesci a dimostrare che il tuo progetto funziona e fa quello che deve fare, che importanza può avere se è semplice o complesso? Se non supera i test, sarà anche difficile individuare eventuali bug.

    ESPRIMERE LO SCOPO DEL PROGRAMMATORE

    Un frammento di codice dovrebbe immediatamente dire cosa fa e non dovrebbe lasciar spazio a sorprese. I nomi di variabili, dei metodi e delle classi dovrebbero descrivere ciò che fanno (“the principle of least astonishment” o “the element of least surprise”).

    NON CONTENERE DUPLICAZIONI

    Un buon progetto non dovrebbe contenere alcuna duplicazione, principio noto anche come “Don’t Repeat Yourself” (DRY). Questo non significa solo duplicazione del codice in senso letterale, ci riferiamo anche alla duplicazione dell’implementazione delle regole di business; dobbiamo evitare di implementare in posti diversi ed in modi diversi lo stesso requisito funzionale. Le logiche con cui vengono ottenute determinate informazioni devono inoltre essere definite in un punto determinato e ben individuabile, in modo da essere facilmente rintracciabili e manutenibili.

    MINIMIZZARE IL NUMERO DI CLASSI E METODI

    L’applicazione non dovrebbe includere codice di cui non avete bisogno. Rimuovete qualsiasi codice inutile, resistete alla voglia di progettare per eventuali esigenze future di cui non si è sicuri. L’applicazione contiene parti che all’epoca sembravano una buona idea, ma che non sono mai state realizzate? Deve essere snellita.

    A volte è difficile minimizzare correttamente quando si è concentrati sui dettagli, per questo motivo è bene fare, occasionalmente, un passo indietro e valutare il risultato.

    La fonte in lingua inglese per questa #pilloladiinformatica è questo articolo di Nicole Bekkers:
    https://www.theguild.nl/4-rules-of-simple-design/