Design knowledge

La design knowledge è la conoscenza del design architetturale di un progetto. È possibile utilizzare:

  1. la memoria: non è affidabile perché nel tempo si erode, specialmente in coppia;
  2. i documenti di design (linguaggio naturale o diagrammi): se non viene aggiornato di pari passo con il codice, che è un operazione fastidiosa e onerosa, rimane disallineato, risultando più dannoso che d’aiuto.
  3. le piattaforme di discussione (version control, issue management): possono aiutare ma le informazioni sono sparse in luoghi diversi e di conseguenza difficili da reperire e rimane il problema di mantenere aggiornate queste informazioni.
  4. gli UML: tramite diagrammi UML si è cercato di sfruttare l’approccio generative programming, ovvero la generazione automatica del codice a partire da specificazioni di diagrammi. Con l’esperienza si è visto che non funziona.
  5. il codice stesso: tramite la lettura del codice è possibile capire il design ma è difficile rappresentare le ragioni delle scelte effettuate.

È bene sfruttare tutte le tecniche sopra proposte combinandole, partendo dal codice.
È inoltre importante scrivere documentazione per spiegare le ragioni dietro le scelte effettuate e non le scelte in sé, che si possono dedurre dal codice.

Condivisione

Per condividere tali scelte di design (il know how) è possibile sfruttare:

  1. metodi: con pratiche (come Agile) o addirittura l’Object Orientation stessa, che può essere un metodo astratto per condividere scelte di design.
  2. design pattern: fondamentali per condividere scelte di design, sono utili anche per generare un vocabolario comune (sfruttiamo dei nomi riconosciuti da tutti per descrivere i ruoli dei componenti) e aiutano l’implementazione (i pattern hanno delle metodologie note per essere implementati). I pattern non si concentrano sulle prestazioni di un particolare sistema ma sulla generalità e la riusabilità di soluzioni a problemi comuni;
  3. principi: per esempio i principi SOLID, spiegati nella sezione successiva.