Come comunicare l'inefficienza prima che sia implementata?

3

Questo è un problema che mi capita spesso. Fondamentalmente stiamo usando un'applicazione per fare contenuti artistici. Spesso ciò richiede la scrittura di strumenti personalizzati per questo.

A volte ci si imbatte in parti dell'applicazione dove il fare qualcosa non è direttamente supportato nell'interfaccia utente, il che significa che sarà un po 'più impegnato o comunicarlo alla società di software che produce questo software in modo che possa indirizzarlo nel futuro.

Ma vedo alcune delle persone più esperte che suggeriscono di usare metodi estremamente inefficienti.

Ad esempio, supponiamo di voler accedere al valore dell'ultimo elemento in un array di elementi 10M. Diciamo che non è direttamente fattibile. Quindi potresti scrivere un codice che sarebbe inopportuno in questo caso perché lo vuoi direttamente direttamente nell'app.

Ma al posto di questo, ti suggeriscono di creare una proprietà di riserva per ogni elemento dell'array, che in pratica memorizzerà la stessa cosa e poi usando uno strumento integrato che passerà attraverso ogni elemento e set il valore di TUTTE queste nuove proprietà sull'ultimo elemento letto. Quindi sarà come:

for i=0 to array.Length:
    new_property[0..array.Length - 1] = array[i];

Quindi questo ti darà davvero l'ultimo elemento quando l'operazione è terminata, ma sarà estremamente lenta.

Come puoi comunicarlo alle persone che suggeriscono questi metodi? Perché pensano che sia abbastanza ragionevole e dal momento che hanno più esperienza e questa è principalmente un'applicazione artistica, non dovrebbe comportare più lavoro per noi / loro.

    
posta Joan Venge 27.01.2013 - 03:29
fonte

1 risposta

12

Il modo in cui gestisco gli argomenti di efficienza prima dell'implementazione (fase di studio di fattibilità o fase di architettura) è il seguente:

  1. Requisiti di prestazioni espliciti e, ancora meglio, definire gli indicatori di prestazioni chiave che ti permetteranno di verificare se il software soddisfa i requisiti di prestazione. (Se si esegue il subappalto del software, questi KPI devono essere molto chiari e devono far parte dei criteri di accettazione.)

    Ad esempio : il requisito di base che avevamo nell'interfaccia utente del telefono cellulare era che qualcosa (qualsiasi cosa) doveva muoversi al massimo 100 ms dopo un'azione dell'utente finale. Se non è possibile, il tempo di reazione più lungo possibile deve essere inferiore a 200ms. (Il razionale si basa sulla percezione umana di "istantaneamente").

  2. Ogni volta che uno specifico obiettivo prestazionale sembra difficile da soddisfare, è possibile prototipare la soluzione prevista. Per il tuo esempio di applicazione artistica, se pensi che la soluzione suggerita potrebbe non funzionare, puoi semplicemente chiedere una dimostrazione di concetto / prototipo, prima dell'implementazione reale.

    Nota: Se soddisfa i requisiti di prestazione, ti interessa davvero una soluzione non ottimale?

  3. (facoltativo) Se non riescono a trovare una soluzione ragionevole per soddisfare i requisiti di prestazione, potrebbe essere il momento di fare un compromesso tra i requisiti "funzionali" ei requisiti di prestazione.

  4. Durante il processo di sviluppo, monitorare l'indicatore KPI per rilevare al più presto possibili problemi di prestazioni. Il subappaltatore potrebbe farlo internamente anche se non lo chiedi esplicitamente.

Inoltre, questo monitoraggio KPI consente di utilizzare la strategia "ottimizza solo se necessario". Gli sviluppatori non dedicano il loro tempo a ottimizzare il loro codice a meno che non vi sia un reale bisogno di prestazioni.

Spero che questo aiuti.

    
risposta data 27.01.2013 - 13:02
fonte

Leggi altre domande sui tag