La modifica di un disegno in seguito lungo la traccia sembra richiedere molto tempo per il suo valore

3

(Per coloro che non codificano, non essere intimiditi dai frammenti di codice in questa domanda, si tratta di un approccio alla modifica di un disegno piuttosto che alla progettazione del codice stesso).

Recentemente ho presentato un progetto tecnico che assomiglia a questo

public class MyDatabaseLayer
{
    public ResponseCode runQuery(Query q)
    {
        try 
           {
              //do database stuff
           }
        catch 
            {
               //catch database exceptions (like bad username/password) and put them into a user friendly ResponseCode
            }
        return r;
    }

}

Tuttavia, secondo il principio del "lancio anticipato, cattura in ritardo", il mio design dovrebbe essere più simile a questo:

public class MyDatabaseLayer 
{
    public ResponseCode runQuery(Query q) throws SomeDatabaseExceptions
    {
        //do database stuff without handling exceptions
        return r;
    }
}

La domanda è, è già in ritardo nella fase di progettazione, e ho già pensato a come avrebbe funzionato la soluzione originale.

Il progetto è abbastanza semplice, e sono sicuro che non ci saranno problemi né nella codifica della soluzione, né nella modifica in futuro.

Penso che cambiare il design in questa fase stia solo ritardandolo e farmi girare in tondo senza produrre un prodotto funzionante.

La domanda è: quali tecniche ci sono per affrontare questo tipo di problema, se ritengo il codice per renderlo 'perfetto', contro salire e consegnarlo come 'abbastanza buono'?

    
posta dwjohnston 26.03.2015 - 23:37
fonte

2 risposte

3

Porsi tre domande:

  • Abbiamo la risorsa per cambiare il design ora? In caso contrario, lascia stare.
  • È probabile che un cambiamento di progettazione aggiunga più valore al prodotto nel corso della sua vita? In caso contrario, lascia stare.
  • C'è qualcosa di meglio che potrei fare con le mie risorse? Se è così, fallo invece.

Il punto di fare qualsiasi cosa, che si tratti di creare software, progettare un prodotto, fare lavoretti, ecc. è sostituire un'alternativa di basso valore per uno più alto. ad esempio, pulisco il pavimento della mia cucina perché apprezzo la sua pulizia rispetto allo sforzo necessario per pulirlo.

Quindi, se i "miglioramenti" apportati a un design sono intesi a confermarlo con un determinato principio di progettazione, ma non aggiungere alcun valore reale, non ha senso crearli.

Il problema di tutto questo è che nessuno può essere sicuro di ciò che accadrà in futuro. Ciò significa che qualsiasi sforzo che io pongo per migliorare oggi potrebbe essere uno sforzo inutile. Per esempio, ho cambiato l'olio nella mia auto regolarmente perché così facendo, spero, contribuirò a prolungare la sua vita. Tuttavia, se la mia macchina viene ammortizzata subito dopo un cambio d'olio, ho sprecato i miei soldi.

La soluzione a questo dilemma è di fare una stima ottimale sulla base delle informazioni che ho a disposizione. Come aiuto per farlo, le persone hanno escogitato regole o principi che li guidano in modi per aggiungere più valore al costo minimo. È qui che entrano in gioco cose come i principi del design del software, ma euristiche simili possono essere applicate a molti altri settori della vita.

La sfida sta scegliendo il principio giusto al momento giusto. Di Coruse, non ci sono regole rigide per farlo, ma per fortuna, ci sono (non sorprendentemente) principi che puoi applicare.

Ecco alcuni:

  • Comprendi perché qualcosa è considerato best practice.
  • Comprendi i tipi di situazioni alle quali il principio appartiene
  • ... e per il quale non lo fa.
  • Confronta questi dati con la situazione attuale.
  • Scopri il costo dell'implementazione del principio.
  • ... e i vantaggi che potrebbero derivare dall'applicarlo.
  • Determina se hai la risorsa per applicare il principio ora.
  • Impara dall'esperienza, sia la tua che quella di altri che hanno svolto un lavoro simile.
  • Considera se potresti apportare miglioramenti incrementali piuttosto che provare a modificare tutto in una volta.

Un'ultima cosa da ricordare è che i costi e i benefici sono cose complesse e spesso scivolose. Tornando al mio esempio di pulire il pavimento della mia cucina, il tempo che passo a pulire ha sia benefici immediati (sembra più bello), benefici a medio termine (mia moglie è felice, e il nostro rapporto migliora di conseguenza) e benefici a lungo termine (dura più a lungo, non è probabile che prendiamo cattive malattie dalle cose ammuffite che festeggia negli angoli). I benefici immediati potrebbero non sembrare così importanti ... ma alcuni degli altri sono critici. Molti dei vantaggi del buon design nel software sono simili. In particolare, un buon design libera "spazio di testa" che può essere utilizzato per risolvere altri problemi, spesso più profondi.

    
risposta data 27.03.2015 - 14:08
fonte
2

I think that changing the design at this stage is just going to delay it and have me going around in circles without actually delivering a working product.

Penso che questa sia la citazione di denaro. Non sei lì per scrivere codice buono o bello. Sei lì per creare software che crea valore per qualcuno e che viene venduto. Il buon design non è un obiettivo in sé. È auspicabile solo nella misura in cui ti consente di creare un software migliore, ad esempio facilitando la manutenzione o l'estensione.

Sviluppo software agile risolve esattamente questo problema. Il modo agile di guardare il tuo problema sarebbe quello di fornire il design concordato subottimale ora per avere un pezzo di software operativo il più presto possibile ... ma essere molto aperto al refactoring più tardi.

Ovviamente qui c'è molto margine di manovra. Nessuno si difende solo sedendosi per codificare "per ottenere qualcosa che funzioni velocemente" senza pianificare ciò che si sta facendo e facendo in anticipo un vero lavoro di progettazione. Ma se senti l'impulso di deviare da un corso pianificato di azione prima di avere un prodotto , per migliorare la progettazione, allora lo sviluppo agile del software ti dirà di calpestare quell'impulso e non agire su di esso. Porta qualcosa fuori dalla porta, raccogli feedback e quindi pensa al refactoring.

    
risposta data 27.03.2015 - 09:14
fonte

Leggi altre domande sui tag