Domanda

Si supponga che si sta prendendo più di un'applicazione legacy .NET. scritto in C #

Quali sono i primi 5 misure diagnostiche, profilatura o in altro modo che si impiegano per valutare la salute della domanda?

Non sono solo guardando il "COSA" parte della diagnosi, ma anche il "come". Per esempio E 'infatti necessario valutare veloci / tempi di risposta ottimali delle app. ... ma c'è un modo per stabilire / misurarla dalla diagnosi tecnica del codice di base invece di ottenere user-experience feedback?

alt text
(fonte: gmu.edu )

E sì, ci sono tenuti ad essere un po ' impressionante gli strumenti che si utilizzano per lo scopo ... sarebbe bello se li si elencano anche.

È stato utile?

Soluzione

1. La percezione degli utenti

molto prima cosa che farei è semplicemente rilevare gli utenti. Ricordate, essi sono quelli che stiamo facendo questo per. Tuttavia orribile un'applicazione può guardare dentro, se gli utenti lo amano (o almeno non attivamente antipatia), allora non si desidera avviare subito strappa lo distingue.

vorrei chiedere domande come:

  • Si trasmette senza problemi?
  • E 'facile da usare?
  • Quando lo si utilizza, si sente sicuro che si sta facendo che cosa vi aspettate?
  • Si tratta di una BMW, una civica, o un Pinto?

Le risposte saranno soggettiva. Va bene. A questo punto stiamo solo cercando tendenze generali. Se un numero enorme di utenti dicono che si blocca tutto il tempo, o che hanno paura di eseguire operazioni di base, allora sei nei guai.

Se le razze app superstizione , e sentire cose come "sembra sfaldarsi fuori il giovedì mattina" o "Non so che cosa questo tasto fa, ma non funziona a meno che lo scatto prima", correre per le colline.

2. Documentazione

Una mancanza di documentazione, o la documentazione che è terribilmente fuori moda, è un segno sicuro di un'applicazione malato. Nessun mezzo di documentazione che angoli tagliati staff di sviluppo, o sono così oberati di lavoro con la marcia costante di morte che proprio non riesce a trovare il tempo per questo tipo di lavoro "inutile".

non sto parlando manuali d'uso - un'applicazione ben progettata non dovrebbe aver bisogno di loro - voglio dire documentazione tecnica, come i sguardi architettura, quali sono le componenti fanno, dipendenze ambientali, impostazioni di configurazione, requisiti / storie di utenti, casi di test / piani di test, i formati di file, si ottiene l'idea. Un difetto del sistema di monitoraggio è anche una parte essenziale della documentazione.

Gli sviluppatori finiscono per fare ipotesi (errati) in assenza di documentazione adeguata. Ho parlato con molte persone del settore che pensano che questo è facoltativo, ma ogni sistema che abbia mai visto o lavorato su quel avuto poco o nessun documentazione finito per essere crivellato di bug e difetti di progettazione.

3. I test

Non c'è modo migliore per giudicare la salute di una domanda che per i propri test, se sono disponibili. Prove di unità, copertura del codice, test di integrazione, anche test manuali, niente lavora qui. Quanto più completare l'suite di test, maggiori sono le possibilità del sistema di essere in buona salute.

test di successo non garanzia molto a tutti, diverso da quello delle specificità in fase di sperimentazione lavoro il modo in cui le persone che hanno scritto i test li aspettano a. Ma un sacco di test in mancanza, o prove che non sono stati aggiornati negli anni, o nessun test a tutti - queste sono le bandiere rosse

.

Non riesco a punto strumenti specifici qui perché ogni team utilizza diversi strumenti per il test. Lavora con tutto ciò che è già in produzione.

4. Analisi statica

Alcuni di voi probabilmente subito pensato "FxCop." Non ancora. La prima cosa che farei è scoppiata NDepend .

Basta un rapido sguardo alla struttura di dipendenze di un'applicazione vi darà enorme quantità di informazioni sul modo in cui l'applicazione è progettata. La maggior parte dei peggiori progetto anti-pattern - il Grande palla di fango , circolari dipendenze , Codice Spaghetti , Dio Oggetti - saranno visibili quasi immediatamente da solo una vista a volo d'uccello delle dipendenze.

Avanti, vorrei correre una generazione completa, accendendo le "Avvertenze trattare come gli errori di" impostazione. Ignorando gli avvertimenti specifici attraverso le direttive del compilatore o bandiere va bene la maggior parte del tempo, ma letteralmente ignorando gli avvertimenti incantesimiguaio. Ancora una volta, questo non garantisce che tutto è OK o che tutto è rotto, ma è un'euristica molto utile per determinare il livello di cura che è andato in l'attuale codifica di fase.

Dopo Sono soddisfatto che il design / architettura generale non è completa spazzatura, poi vorrei guardare FxCop . Non prendo la sua uscita come il vangelo, ma sono specificamente interessati a Avvisi di progettazione e Usage avvertenze (avvisi di protezione sono anche una bandiera rossa, ma molto raro).

5. Analisi Runtime

A questo punto sto già soddisfatto che l'applicazione, a un livello elevato, non è un enorme cumulo di succhiare. Questa fase potrebbe variare un po 'per quanto riguarda l'applicazione specifica al microscopio, ma alcune cose buone da fare sono:

  • Log tutte le eccezioni first-chance sotto una corsa normale. Ciò contribuirà a valutare la robustezza della domanda, per vedere se troppe eccezioni vengono ingerite o se eccezioni vengono utilizzati come controllo di flusso. Se si vede un sacco di istanze Exception di livello superiore o derivati ??SystemException appaiono, avere paura.

  • Esegui attraverso un profiler come EQATEC . Questo dovrebbe aiutare a identificare abbastanza facilmente eventuali problemi di prestazioni gravi. Se l'applicazione utilizza un back-end di SQL, utilizzare uno strumento di SQL profiling per guardare le query. (Really ci sono separati di passaggi per testare la salute di una banca dati, che è una parte critica di test di un'applicazione che si basa su uno, ma io non voglio arrivare troppo fuori tema).

  • Guarda alcuni utenti - aspetto particolarmente per i "rituali", cose che fanno per apparentemente senza motivo. Questi sono di solito il segno della persistente bug e ticchettio bombe a orologeria. Anche guardare per vedere se genera un sacco di messaggi di errore, si blocca l'interfaccia utente per lunghi periodi mentre "pensiero", e così via. In sostanza, qualsiasi cosa che personalmente odio per vedere come utente.

  • Gli stress test. Anche in questo caso, gli strumenti specifici dipendono dall'applicazione, ma questo è particolarmente applicabile alle applicazioni basate su server. Vedere se l'applicazione può ancora funzionare sotto carico pesante. Se inizia timeout vicino al punto di rottura, va bene; se si inizia a generare il messaggio di errore bizzarri o, peggio, sembra dati corrotti o dello stato, che è un molto brutto segno.

E questo è tutto quello che posso pensare per ora. Io aggiornare se più vengono in mente.

Altri suggerimenti

Queste non sono codificando consigli o profilatura consiglio, ma un modo generale di valutare la salute di un programma in qualsiasi lingua. In ordine di importanza

  1. È la felice utente finale con esso?
  2. è stabile?
  3. E 'robusto?
  4. E 'veloce?
  5. È la stabile occupazione di memoria per lunghi periodi e quello che ci si aspetterebbe?

Se la risposta a tutti e 5 di quelle domande è sì, allora si ha l'applicazione in buona salute. Direi che 1-3 sono davvero i più importanti. Esso non può essere abbastanza al suo interno, e di testa, eventualmente, in basso a destra brutto, ma la sua salute se soddisfa tali specifiche e deve sempre rimanere in modalità legacy (ossia piccole correzioni)

Vorrei suggerire la scrittura test in giro certe aree. Io non sono un grande fan di test di unità - anche se io alla fine a scrivere un bel po 'di loro. Io preferisco test di sistema che le parti di test del sistema - in modo da giù di dominio, il servizio verso il basso, verso il basso presentatore ecc non neccesarily l'intero sistema, ma parti di esso. Se siete alla ricerca del massimo rendimento, allora questi test può essere eseguito un cronometro intorno al codice e non riuscire se ci vuole troppo tempo.

Un altro bel cosa da fare è gestito attraverso operazioni standard ANT Profiler dal Redgate o dotTrace da JetBrains. E ti dico quello che sta prendendo il tempo e quante volte è stato eseguito, significa che è possibile vedere dove può essere ottimizzato / cache.

Se stai usando NHibernate quindi NHProf è grande (o penso Ayende ha rilasciato la UberProf che copre più strategie di accesso DB). Questo vi avvertirà di qualsiasi accesso DB stupido in corso. In mancanza di ciò semplicemente utilizzando il SQL Server Profiler potrebbe mostrarvi la richiesta più e più volte gli stessi dati, ma richiede uno sforzo maggiore filtrando fuori la spazzatura. Se si finisce per utilizzare che quindi è possibile salvarlo in una tabella di DB, che è quindi possibile query in modo più intelligente.

Se siete alla ricerca di robustezza, una buona cosa per l'uso è una strategia di registrazione - catturare tutte le eccezioni e log. Questo è abbastanza facile da configurare utilizzando log4net . Anche il login se si ha colpito alcuni punti che sei un po 'sospettosi. Poi hanno questo in esecuzione in un server (io uso server kiwi syslog , che è facile da configurare e abbastanza potente) che può scrivere in un DB e si può eseguire l'analisi dei risultati. Vorrei raccomandare contro l'appender ADO.NET per log4net in quanto non è asincrona e quindi rallenterà la vostra applicazione verso il basso.

Infine a seconda di ciò che l'applicazione è se si sta davvero appassionato di trascorrere del tempo sulla sperimentazione sua salute è possibile utilizzare Watin o WinForms equivalente per testare la fine frontale. Questo potrebbe anche essere un test prolungato monitorando l'utilizzo della memoria / processore dell'applicazione mentre viene utilizzato. Se non sei preoccupato che poi i finestre Performance Analyzer vi permetterà di guardare i vari aspetti dell'applicazione, mentre lo si utilizza. Sempre utile, ma bisogna colpire veramente intorno per ottenere le metriche utili.

Spero che questo aiuti.

I primi due grandi elementi che avrebbero cercato sarebbero:

  1. Aggiunta di movimentazione con la registrazione, così come la ricerca per qualsiasi gestione delle eccezioni che potrebbero essere "deglutire" eccezioni, nascondendo i problemi con l'applicazione globale delle eccezioni (penso che ci sia anche un contatore di finestre delle prestazioni che esporrà il numero di eccezioni al secondo che vengono gettati dall'applicazione). Questo può aiutare a scoprire eventuali problemi di coerenza dei dati nell'applicazione.
  2. Aggiungete un po 'le prestazioni di monitoraggio e la registrazione a qualsiasi persistenza dei dati e / o dipendenze dei servizi di rete esterni che l'applicazione potrebbe essere in uso, come ad esempio le query di database di registrazione o di chiamate di servizio web che richiedono più tempo di una quantità X di tempo per completare.

Se questo interagisce con un database, si dovrebbe avere un'idea di disco I / O e il grado di frammentazione del disco rigido / disk array. Per MS SQL, analizzare le stored procedure e rivedere gli indici e le chiavi primarie sui tavoli.

È davvero non ha bisogno di strumenti per questo, solo il lavoro sporco di revisione contatori e parlare con il DBA.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top