Come gestire le ipotesi durante la progettazione di qualsiasi sistema?

3

Ho esaminato vari esempi di progettazione di sistema per capire come ci avviciniamo a qualsiasi domanda di progettazione di sistema. Ecco cosa ho capito fino ad ora.

  1. Conosci prima il sistema e scopri come funziona.
  2. Pensa a tutti i casi d'uso.
  3. Identifica i componenti chiave e le loro responsabilità.
  4. Connetti tutti i componenti in modo che possano comunicare tra loro.
  5. Utilizza tutte le procedure standard durante l'integrazione dei componenti e, se possibile, utilizza schemi di progettazione standard.

A volte facciamo ipotesi sul sistema, quindi queste ipotesi dovrebbero essere utilizzate per rimuovere un caso d'uso o per aggiungere una variante.

Inserirò questa domanda nel contesto della progettazione di un parcheggio.

Se presumo che il parcheggio non sia commerciale, ed è un parcheggio gratuito, la progettazione del parcheggio dovrebbe gestire il parcheggio gratuito come uno dei casi d'uso e dovrebbe essere generico. OPPURE Progettare semplicemente un parcheggio che non funzionerà mai per il parcheggio commerciale.

L'idea principale è che se qualcuno ti chiede di progettare un parcheggio e questo è un parcheggio gratuito, il design dovrebbe essere generico o specifico?

    
posta AKS 14.08.2013 - 17:04
fonte

5 risposte

6

Personalmente, sono un grande fan di YAGNI - (non ne avrai bisogno) .

La progettazione della soluzione generale è difficile .

La regola generale che ho visto (ma naturalmente non riesco a trovare un link a quando lo voglio) è

  1. Scrivi il primo blocco di codice per risolvere il problema.
  2. Quando vedi una seconda istanza del problema, copia il primo codice e amp; apportare modifiche per soddisfare.
  3. Quando vedi una terza istanza del problema, refactoring a una soluzione generale.

Potresti trovare la storia della lettura utile Oggetto Toaster . È un ammonimento sui pericoli legati al pensiero eccessivo di un problema.

    
risposta data 14.08.2013 - 17:14
fonte
2

Le ipotesi sono un dato di fatto nei progetti IT.

I requisiti cambiano e non importa quanto spesso desideriamo che vengano bloccati, spesso non lo sono.

Quindi devi gestire le tue ipotesi e tenerle d'occhio.

Forse mantenendo un registro dei problemi o qualcosa di simile. Contrassegnare elementi con livelli di stato per indicare quanto grande potrebbe diventare un problema ecc.

Con il tuo esempio di parcheggio, puoi assegnare una stima del tempo a ciascun "livello" di progettazione e avere un'ipotesi nel tuo log di emissione che parli del presupposto che hai fatto, e quale sarebbe il costo di farlo in un modo o l'altro.

    
risposta data 14.08.2013 - 17:23
fonte
1

Regola n. 1: non fare mai ipotesi, sviluppare un minimo indispensabile
Regola n. 2: non ne hai bisogno: link
Regola n. 3: inizia scrivendo test unitari

    
risposta data 14.08.2013 - 17:11
fonte
0

È sempre una buona idea sistemare i sistemi e avere un percorso di comunicazione verso lo sviluppatore con i risultati della strumentazione. (Non sto parlando di spyware, lo farò un file di registro o una schermata "stats").

Parte della buona strumentazione fornisce dati rilevanti per le ipotesi. Vale a dire; un'app di parcheggio dovrebbe riportare il numero di auto che dovrebbe gestire e magari aggiungere una speciale bandiera di avviso se si suppone che gestisca un milione di auto ...

    
risposta data 14.08.2013 - 22:19
fonte
0

Main idea is that if someone asks you to design a parking lot and that is free parking lot, then design should be generic or specific?

Evita il più possibile una progettazione specifica, poiché dovresti modificarla una volta chiariti o modificati i requisiti.

Elimina le tue ipotesi chiarendo i requisiti e minimizzando / semplificando lo scopo del lavoro. Di solito, la progettazione sovra-architettonica introduce una complessità non necessaria per il progetto.

La regola empirica durante la progettazione di un software, con requisiti e presupposti precostituiti, è di per mantenerlo semplice. Ci sono un numero di post su questo argomento combinato con una famosa frase YAGNI!

In altre parole, i migliori schemi di progettazione con cui attenersi sono KISS e YAGNI !

  • YAGNI - Non ne avrai bisogno
  • KISS - Mantieni la cosa semplice stupida
risposta data 14.08.2013 - 18:03
fonte

Leggi altre domande sui tag