Dovremmo scrivere una progettazione dettagliata dell'architettura o solo uno schema durante la progettazione di un programma?

8

Quando eseguo il design per un compito, continuo a combattere questa sensazione fastidiosa che, a parte il fatto di essere una struttura generale, alla fine sarà più o meno ignorata. Ti darò un esempio:

Stavo scrivendo un frontend per un dispositivo che ha operazioni di lettura / scrittura. Aveva perfettamente senso nel diagramma di classe per dargli una funzione di lettura e scrittura. Tuttavia, quando si è trattato di scriverli realmente, mi sono reso conto che erano letteralmente la stessa funzione con una sola riga di codice modificata (chiamata di funzione di lettura e scrittura), quindi per evitare la duplicazione del codice ho finito per implementare una funzione do_io con un parametro che distingue tra operazioni. Addio design originale.

Questo non è un cambiamento terribilmente dirompente, ma succede spesso e può accadere anche in parti più critiche del programma, quindi non posso fare a meno di chiedermi se c'è un punto per disegnare più dettagli di uno schema generale, a almeno quando si tratta dell'architettura del programma (ovviamente quando si specifica un'API si deve scrivere tutto fuori).

Questo potrebbe essere solo il risultato della mia inesperienza nel fare design, ma d'altra parte abbiamo metodologie agili che dicono "rinunciamo a pianificare molto più avanti, tutto cambierà comunque tra qualche giorno", che è spesso come mi sento.

Quindi, come esattamente dovrei "usare" il design?

    
posta EpsilonVector 21.11.2011 - 08:52
fonte

8 risposte

6

Se avesse perfettamente senso fornire operazioni di lettura e scrittura, perché rimuoverle?

Dal punto di vista dell'utente ha ancora perfettamente senso. I dettagli di implementazione non dovrebbero interferire con un'interfaccia fornita.

Quello che puoi fare è creare un do_io interno che viene chiamato da lettura e scrittura.

Alla fine il processo di progettazione segue questi passaggi:

  • definisce l'interfaccia
  • disegna un disegno approssimativo
  • perfezionare senza cambiare l'interfaccia concordata
risposta data 21.11.2011 - 09:17
fonte
4

Il design dell'architettura di un programma si evolve nel tempo. Non penso che all'inizio abbiate tutte le informazioni necessarie per avere un progetto corretto.

Quindi, se ti attieni al design che pensavi all'inizio, probabilmente ti limiti.

A meno che tu non stia creando una API pubblica, penso che sia OK apportare modifiche al design lungo il percorso.

Anche una delle cose migliori da fare è investire in uno strumento che può estrarre il design dal codice (come NDepend per C #)

    
risposta data 21.11.2011 - 09:18
fonte
2

Agile afferma di rispondere a questo problema, con un certo successo, tuttavia Fred Brooks ebbe la risposta 40 anni fa, quando scrisse "Scrivi uno da buttare via, perché lo farai comunque". Coloro che non studiano la storia sono condannati a ripeterlo.

Quindi, ciò che si fa è considerare il progetto come un piano, che è fatto al solo scopo di cambiarlo. Disegni che non possono essere cambiati sono condannati. Devi essere preparato a buttare via quelli cattivi.

Se il design è una delle API pubbliche, un'interfaccia o simili, è necessario prestare molta attenzione in quanto il costo del cambiamento è elevato, tuttavia, l'incapacità di cambiare lo condurrà al fallimento.

Non pensate per un secondo di essere abbastanza bravo e di sapere abbastanza per farlo bene prima, seconda o anche terza volta.

    
risposta data 21.11.2011 - 09:40
fonte
2

È un fatto della vita nella maggior parte dei progetti di vita reale che le cose cambiano:

  • (come hai notato) l'ambiente / piattaforma / API che il programma sta per utilizzare potrebbe essere diverso da quello originariamente assunto
  • i requisiti possono cambiare in qualsiasi momento
  • il mercato / mondo circostante potrebbe cambiare, rendendo obsoleti alcuni requisiti (o l'intero progetto)
  • ...

Questo è il motivo per cui i metodi Agile si oppongono a Big Design Up Front, perché dà solo un falso senso di sicurezza, comporta un sacco di sforzi inutili e rende più difficile l'adattamento alle inevitabili modifiche.

Tuttavia, Agile non equivale a "rinuncia alla pianificazione molto più avanti" . I metodi agili comportano la quantità necessaria di pianificazione attenta e ponderata, non più. Sono molto disciplinati e diversi dalla "codifica dei cowboy". Fare la giusta quantità di design è un continuo tentativo di trovare il giusto equilibrio tra over e underdesigning. Ma IMHO è meglio sbagliare un po 'di troppo, piuttosto che fare troppo poco.

Il design iniziale non dovrebbe cercare di coprire tutto, ma dovrebbe darti la sensazione che sai come procedere con l'implementazione, hai le risposte alle domande fondamentali sull'architettura e hai un modello mentale di come i casi d'uso noti funzioneranno nella vita reale. Nella vista Agile, il vero test di un progetto è l'implementazione, quindi è OK iniziare a scrivere il codice anche durante la fase di progettazione, solo per avere un'idea di come sarebbe il design previsto, o per prototipare / convalidare rapidamente alcune ipotesi . Nota però che la maggior parte di questi primi lavori devono essere gettati via una volta determinata la risposta alla domanda data. È quasi sempre una brutta cosa iniziare a costruire una vera app di produzione da un prototipo iniziale.

Ed è anche OK tornare indietro e modificare il design se si realizza una nuova importante realizzazione durante l'implementazione. Questo è un feedback importante su due livelli:

  • il tuo progetto concreto deve essere adattato al mondo che cambia e
  • il tuo progetto processo deve essere adattato per coprire tali possibilità in futuro (ad esempio, la prossima volta pensa attraverso il caso d'uso di leggere e scrivere sul dispositivo in anticipo).
risposta data 21.11.2011 - 09:17
fonte
2

È sempre importante quando crei un documento per capire qual è lo scopo.

Penso che dobbiamo stare attenti a ciò che chiamiamo documenti di "architettura". È tutta una questione di portata.

Se parli di un sistema che richiede diversi team o gruppi di team, allora stai parlando di un documento che ha lo scopo di dettagliare al minimo:

  • Quali sono i componenti nel sistema
  • Come sono collegati i componenti
  • Quali sono le responsabilità di ciascun componente
  • Chi dovrebbe lavorare su ciascun componente

Se il tuo documento è per un sistema più piccolo, puoi ridurre il numero di elementi che devi includere perché alcune ipotesi saranno inerenti al sistema esistente. Ad esempio, supponiamo che tu stia mettendo insieme una funzionalità che dovrà essere eseguita in un sito Web e alcune nuove chiamate in un'API, quindi il tuo documento servirà come un modo per fissare il seguente:

  • Quale logica vivrà nel sito web
  • Quale logica vivrà nell'API
  • Quali saranno i contratti di chiamate API (ipotesi migliore)

Questi documenti di contorno servono a portare le conversazioni in primo piano su chi dovrebbe fare cosa e come dovrebbero integrarsi. Una volta prese queste decisioni, i team possono operare in modo ampiamente autonomo con una minore probabilità di problemi di integrazione.

Più problemi di integrazione percepisci, più i documenti dovrebbero essere dettagliati.

    
risposta data 12.03.2014 - 07:02
fonte
1

Sembra che tu sia incappato in un enigma comune nello sviluppo di software. Non è possibile pianificare un intero sistema prima di iniziare a costruirlo, perché ci sono troppe cose che ancora non conosci.

Questo è il motivo per cui le metodologie Agile usano lo sviluppo iterativo, perché consente un feedback regolare per cambiare la direzione del software, piuttosto che lasciare che le cose si allontanino sempre di più da ciò che è effettivamente necessario. Ogni modifica influirà sul design.

Quindi, avendo detto tutto ciò, in realtà avrei scritto due metodi per lo specifico scenario descritto sopra, ma avrei incapsulato la logica condivisa in un terzo metodo privato che può essere usato dai due metodi. In questo modo, i metodi pubblici sono responsabili di una sola cosa e sono facili da nominare, read_file e write_file dicono esattamente cosa fanno, mentre do_file è ambiguo.

Libri come Clean Code , Robert C Martin e Emergent Design , Scott L Bain ti fornirà informazioni più dettagliate su questo argomento.

    
risposta data 21.11.2011 - 09:24
fonte
1

This might be just the result of my inexperience in doing design, but on the other hand we have agile methodologies which sort of say "we give up on planning far ahead, everything is going to change in a few days anyway", which is often how I feel.

Non è possibile pianificare ogni singolo dettaglio in anticipo. È perfettamente accettabile apportare modifiche qua e là.

Tuttavia, è importante pianificare in anticipo. Fare agile non significa affatto design e nessuna pianificazione , ma significa che ti stai aspettando dei cambiamenti.

So, how exactly should I "use" design?

Dovresti usare il tuo design così com'è. Poiché non è scritto nella pietra, è facile cambiarlo.

    
risposta data 21.11.2011 - 09:36
fonte
1

La quantità di tempo che trascorri per l'architettura dovrebbe essere determinata dal grado di rischio in quella parte del sistema.

Generalmente vorresti prendere una decisione abbastanza presto sugli stili architettonici - a strati, componenti, pub-sub, ecc. ecc. Nessuna quantità di codice pulito e accoppiamento libero renderà facile passare stili in ritardo in un progetto.

Questo ti darà un'idea di base dei diversi elementi costitutivi del tuo sistema e di quale sarà la roadmap come il tuo sistema e le esigenze evolveranno nel tempo.

Una volta entrati nei casi d'uso, credo che dovresti fare abbastanza design per assicurarti di comprendere pienamente il problema e la soluzione. Se si tratta di codice della piastra di riscaldamento che hai ripetuto più volte, il rischio di sbagliare (in senso architettonico, è comunque necessario testare ovviamente) è piuttosto basso e quindi è probabile che la progettazione anticipata essere abbastanza minimale. Se si tratta di un nuovo problema o di una soluzione poco chiara o potenzialmente rischiosa per l'azienda, meriterà molto più tempo a riflettere.

Ovviamente ci sono molti modi per farlo: UML, prototipi, schizzi a bordo bianco, ecc. Qualunque sia il metodo che usi, la cosa fondamentale è ricordare che il loro scopo è aiutarti a pensare e a comunicare sul tuo design.

    
risposta data 21.11.2011 - 10:46
fonte

Leggi altre domande sui tag