Quando si progetta un'applicazione di sostituzione, come posso confrontare il suo rendimento con l'originale, se non ci sono statistiche esistenti?

and don't want to ask the individuals doing the work to manually record things like how long it takes them to perform a given task

Ecco il problema.

Fondamentalmente vuoi creare metriche significative, senza misurare l'unica cosa che conta. Quasi tutti i tuoi utenti non si preoccuperanno della velocità del codice stesso a meno che non provochino un impatto notevole sulle loro attività.

Una buona domanda sarebbe a chi ti sta chiedendo questo progetto - a volte le informazioni che stai cercando (l'attività X impiega 10 minuti) sono usate come giustificazione per sostituire il software esistente, specialmente il software interno.

Potresti essere in grado di eseguire alcune operazioni di profilazione o registrazione di base. A seconda del tipo di rerwite, se hai dei test puoi confrontare i tempi di test (non sarà altrettanto efficace se stai partendo da zero e / o non ne hai nessuno).

Se ogni azione dell'utente presenta semplici punti di entrata / uscita, è possibile calcolare il tempo per l'intera azione (magari compilando una richiesta d'acquisto, qualunque sia l'applicazione) e registrarla. Non devi necessariamente preoccuparti tanto delle singole parti di tali azioni.

Puoi anche chiedere a chiunque richieda la riscrittura di fornirti un elenco di orari o un elenco di attività che desiderano confrontare. Questo è probabilmente consigliabile anche se si finisce per trovare le metriche da soli. Vuoi essere sicuro di mettere impegno per risolvere i problemi reali - con la riscrittura delle applicazioni devi giustificarti continuamente, perché il "bene ha funzionato prima perché lo stai riscrivendo?" la domanda sarà sempre presente (e legittima).

Mi sono trovato di fronte a questo, e la risposta è:

Per qualcuno esperto nell'ottimizzazione delle prestazioni, il nuovo codice può essere regolato in modo che quasi nessun codice possa andare più veloce. Ecco un esempio.

Il motivo è che c'è un intervallo di tempo minimo che l'attività può eseguire ed è maggiore di un ciclo. Esistono molti, molti programmi che possono eseguire l'operazione e uno o più di essi impiegano meno tempo di tutti gli altri, quindi sono ottimali, per definizione.

Il vecchio codice potrebbe essere altrettanto veloce o persino più veloce, ma se non è stato ottimizzato da qualcuno con quell'esperienza, non è probabile.

Quindi se non ci sono misure del vecchio codice, tutto ciò che puoi fare è applicare l'esperienza per assicurarti che il nuovo codice sia il più ottimale possibile, quindi è quasi certo che sia più veloce del vecchio.

Un modo più semplice per dirla:

Il software è come un asciugamano bagnato. Il più delle volte non è stato strizzato.

Non sai quanto sia umido il vecchio, ma se davvero tormenta il nuovo, puoi essere sicuro che non è più umido di quello vecchio, e probabilmente molto più secco.