Dovremmo codice per prestazioni o stabilità? [duplicare]

Credo che tutti i buoni consigli qui su PSE per preferire il codice gestibile su un codice veloce non convincerà la tua gestione finché entrambi hanno solo opinioni, ma non fatti. Quindi ecco il mio consiglio su come potresti agire nella tua situazione specifica.

Avendo memorizzato le procedure che eseguono i propri commit senza la possibilità di controllare le transazioni dall'esterno, è davvero difficile riutilizzare tali procedure in un processo combinato (vale a dire per qualsiasi tipo di codice che aggiorna un database, stored procedure o meno). Lo vedo tipicamente come un errore di progettazione pesante , tipicamente creato da principianti (ma ho visto questo genere di cose troppo spesso da sviluppatori più o meno "esperti").

The case is that management thinks that this approach [...] will impact greatly in our code.

Ovviamente, avrà un impatto sul tuo codice (sarà valorizzare il suo design). Ma IMHO nella maggior parte dei casi è possibile rifattorizzare il codice esistente in un modo in cui il rischio di rompere le cose non è troppo grande. Per ciascuna stored procedure, aggiungere un parametro (ad esempio bool autoCommit ) che consente di disattivare il commit facoltativamente. Lascia che il commit sia abilitato come predefinito (che ha in genere solo un piccolo impatto sul codice esistente), e assicurati di non aver infranto nulla finora.

Quindi, crea una versione di test del tuo codice (o almeno un esempio rappresentativo) che utilizza la nuova funzione per controllare la transazione dall'esterno. Ciò ti dà l'opportunità di misurare l'impatto sulle prestazioni e dimostrare o confutare le obiezioni gestionali. Ciò consentirà anche un confronto diretto tra il vecchio e il nuovo codice mostrando quanto è migliore la nuova soluzione.

In seguito, potresti pensare di ridefinire le procedure modificate in uno stato in cui il parametro autoCommit non è più necessario.

Il codice dovrebbe essere mantenibile, valido ed efficiente , in questo ordine di priorità.

Non ha senso avere un codice ad alte prestazioni che non faccia ciò che si suppone faccia (c'è robustezza), e ogni volta che si verifica un bug o un problema di prestazioni, è la manutenzione che farà la differenza . Non ho esperienza nel database, ma sarei sorpreso se questo principio non si applicasse anche nel database.

Ora la parte difficile sta nel fatto che la direzione lo accetti. E comunque, le prestazioni sono comunque un problema?

Ciò che cerchi sono due cose: correttezza ed efficienza. Succede solo che la semplicità sufficiente ti darà evidente correttezza e renderà l'efficienza facile da implementare.

Tuttavia, il tuo sistema è passato oltre quel punto. A meno che non vi sia un approccio drasticamente diverso al problema che semplificherebbe enormemente le cose, sarà difficile raggiungere sia la correttezza che l'efficienza. Se vuoi fare entrambe le cose per emergere dallo stesso codice, probabilmente fallirai.

L'unico approccio qui è usare i test. Avrai un corpo separato di codice semplice che non riguarda affatto l'efficienza, ma la correttezza. E una volta che i test sono a posto, è possibile implementare la soluzione reale e lottare con esso fino a quando non è abbastanza veloce durante tutti i test.

A well performing code that is unstable is no good

Quindi la prima e più importante osservazione dovrebbe essere quella di ottenere stabilità nel codice, e il modo per farlo è TEST , costruisci una grande suite di test.

Quando hai una grande suite di test che backs hai, ora dovresti provare a fare i test Load / Stress e se trovi che le prestazioni mancano allora e solo allora dovresti cercare di ottenere prestazioni.

E mentre raggiungi le prestazioni se fai qualcosa di sbagliato, i tuoi test ti avviseranno molto prima del tempo di produzione.

Passi:

• Test, test e test
• Codice flessibile, leggibile e verificabile
• Carica test
• Ottimizzazione delle prestazioni, se necessario, dimostrata priva di carico / stress test