Question

Supposons que vous prenez sur une application .NET héritée. écrit en C #

Quels sont les top 5 des mesures de diagnostic, le profilage ou autre que vous employer pour évaluer la santé de l'application?

Je ne cherche pas juste à la « QUOI » une partie du diagnostic, mais aussi au « comment ». Pour exemple Il est en effet nécessaire d'évaluer les temps de réponse rapide / optimale de l'application. ... mais est-il un moyen de mettre en place / mesurer par le diagnostic technique de la base de code au lieu d'obtenir une rétroaction expérience utilisateur?


(source: gmu.edu )

Et oui, il y a forcément quelques impressionnante outils que vous utilisez dans le but ... ce serait bien si vous les énumérer aussi.

Était-ce utile?

La solution

1. Perception de l'utilisateur

très première chose que je ferais est une enquête simplement les utilisateurs. Rappelez-vous, ce sont ceux que nous faisons cela pour. Cependant horribles une application peut regarder à l'intérieur, si les utilisateurs l'aiment (ou du moins ne déteste pas activement) alors vous ne voulez pas commencer immédiatement le déchirer en dehors.

Je veux poser des questions telles que:

  • Est-il bon déroulement?
  • Est-il facile à utiliser?
  • Lorsque vous l'utilisez, vous sentez-vous confiant qu'il fait ce que vous attendez?
  • Est-ce une BMW, une Civic ou un Pinto?

Les réponses seront subjective. C'est bon. À ce stade, nous sommes à la recherche d'grandes tendances. Si un très grand nombre d'utilisateurs disent qu'il bloque tout le temps, ou qu'ils ont peur d'effectuer des tâches de base, alors vous êtes en difficulté.

Si les races app superstition , et vous entendez des choses comme « il semble écailler sur le jeudi matin » ou « Je ne sais pas ce que ce bouton, mais il ne fonctionne pas à moins que Je clique d'abord », courir vers les collines.

2. Documentation

Un manque de documentation ou de la documentation qui est affreusement à jour, est un signe certain d'une application malade. Aucun moyen de documentation que les coins coupés du personnel de développement, ou sont tellement surchargés de travail avec la mort de mars constant qu'ils ne peuvent tout simplement pas le temps pour ce genre de travail « inutile ».

Je ne parle pas des manuels d'utilisation - une application bien conçue ne devrait pas besoin d'eux - je veux dire la documentation technique, comment l'apparence d'architecture, ce que les composants font, les dépendances de l'environnement, les paramètres de configuration, les besoins / témoignages d'utilisateurs, des cas de test / plans de test, les formats de fichiers, vous obtenez l'idée. Un système de suivi des défauts est également un élément essentiel de la documentation.

Les développeurs finissent par faire des hypothèses (incorrectes) en l'absence de documentation appropriée. J'ai parlé à plusieurs personnes dans l'industrie qui pensent que cela est facultatif, mais chaque système que j'ai jamais vu ou travaillé sur cette documentation avait peu ou pas fini d'être criblé de bugs et des défauts de conception.

3. Tests

meilleure façon de juger de la santé d'une application que par ses propres tests, si elles sont disponibles. Les tests unitaires, couverture de code, tests d'intégration, même des tests manuels, tout fonctionne ici. La plus complète la suite de tests, plus les chances du système étant en bonne santé.

Tests réussis ne le font pas garantie bien du tout, sauf que les caractéristiques spécifiques à l'essai le travail de la façon dont les personnes qui ont fait les tests les attendent à. Mais beaucoup de tests ayant échoué, ou des tests qui ne sont pas mises à jour au cours des années, ou pas de tests du tout - ce sont des drapeaux rouges

.

Je ne peux pas le point d'outils spécifiques ici parce que chaque équipe utilise différents outils pour les tests. Travaillez avec tout ce qui est déjà en production.

4. Analyse statique

Certains d'entre vous probablement tout de suite pensé « FxCop. » Pas encore. La première chose que je ferais est briser NDepend .

Juste un coup d'œil sur l'arbre de dépendance d'une application vous donnera énorme quantités d'informations sur la façon dont l'application est conçue. La plupart des pires conception anti-modèles - grosse boule de boue , dépendances circulaires, Spaghetti code , Dieu Objets - sera visible presque immédiatement de juste une vue plongeante sur des dépendances.

Ensuite, je courrais une construction complète, activation du paramètre « Traiter les avertissements comme des erreurs ». Ignorant les avertissements de spécifiques au moyen de directives du compilateur ou des drapeaux est bien la plupart du temps, mais littéralement en ignorant les sorts des avertissementsdifficulté. Encore une fois, cela ne vous garantit que tout est OK ou que quelque chose est cassé, mais il est très heuristique utile pour déterminer le niveau de soins qui est entré dans la réelle codage phase.

Après Je suis convaincu que la conception / architecture globale ne sont pas des ordures complète, puis Je regardais FxCop . Je ne prends pas sa sortie comme parole d'évangile, mais je suis particulièrement intéressé par Avertissements conception et Utilisation avertissements de (avertissements de sécurité sont également un drapeau rouge, mais très rare).

5. Analyse d'exécution

A ce point, je suis déjà convaincu que l'application, à un niveau élevé, n'est pas un monticule énorme de sucer. Cette phase varie un peu par rapport à l'application spécifique au microscope, mais quelques bonnes choses à faire sont:

Et c'est tout ce que je peux penser pour l'instant. Je mettrai à jour si plus viennent à l'esprit.

Autres conseils

Ce ne sont pas codants des conseils ou des conseils de profilage, mais d'une manière générale d'évaluer la santé d'un programme dans toutes les langues. Par ordre d'importance

  1. L'utilisateur final heureux avec elle?
  2. Est-il stable?
  3. Est-il solide?
  4. Est-il rapide?
  5. La stabilité de l'empreinte mémoire sur de longues périodes et ce que j'attendre?

Si la réponse à tous les 5 de ces questions est oui, alors vous avez une application saine. Je dirais que 1-3 sont vraiment le plus important. Il ne peut pas être assez à l'intérieur, et peut-être vers le bas bout droit laid, mais sa santé si elle répond à ces spécifications et doit rester toujours en mode hérité (à savoir les petites corrections de bugs)

Je suggère l'écriture de tests dans certaines zones. Je ne suis pas un grand fan des tests unitaires - bien que je finis par écrire un assez grand nombre d'entre eux. Je préfère des tests du système que des parties de test du système - donc du bas de domaine, le service vers le bas, vers le bas etc présentateur ne neccesarily l'ensemble du système, mais les parties de celui-ci. Si vous êtes à la recherche d'efficacité alors ces tests peuvent exécuter un chronomètre autour du code et l'échec si elle prend trop de temps.

Une autre chose agréable à faire est de lancer des tâches standard par Fourmis Profiler de Redgate ou dotTrace de JetBrains. Il va vous dire ce qui prend le temps et combien de fois il a été exécuté, ce qui signifie que vous pouvez voir où peut être optimisé / mis en cache.

Si vous utilisez NHibernate puis NHProf est grande (ou je pense que Ayende a publié le UberProf qui couvre plus de stratégies d'accès DB). Cela vous avertit de tout accès DB stupide passe. A défaut juste en utilisant le SQL Server profileur peut vous montrer demander les mêmes données encore et encore, mais il faudra plus d'efforts en filtrant les déchets. Si vous finissez à l'aide que vous pouvez l'enregistrer sur une table DB que vous pouvez ensuite la requête d'une manière plus intelligente.

Si vous êtes à la recherche de robustesse, une bonne chose à utiliser est une stratégie forestière - attraper toutes les exceptions et les journaux. Ceci est assez facile à mettre en place en utilisant log4net . connectez-vous également si vous frappez certains points que vous êtes un peu méfiant de. Ensuite, cette course dans un serveur (j'utilise le serveur kiwi qui est facile à mettre en place et assez puissant) qui peut écrire à un DB et vous pouvez exécuter une analyse sur les résultats. Je recommande contre le appender ADO.NET pour log4net que ce n'est pas async et ainsi va ralentir votre application vers le bas.

Enfin en fonction de ce que l'application est si vous êtes vraiment vraiment envie de passer un peu de temps à tester son état de santé, vous pouvez utiliser Watin ou WinForms équivalent pour tester la l'extrémité avant. Cela pourrait même être un test prolongé en regardant l'utilisation de la mémoire / processeur de l'application pendant qu'il est utilisé. Si vous n'êtes pas inquiet alors les Analyseur de performances Windows vous permettra de regarder les différents aspects de l'application pendant que vous utilisez. Toujours utile, mais vous devez vraiment pousser autour d'obtenir les mesures utiles.

Hope this helps.

Les deux premiers grands articles que j'examineraient seraient:

  1. Ajout exception globale manipulation à l'exploitation forestière, ainsi que la recherche d'une gestion des exceptions qui pourraient être « avaler » exceptions, cachant des problèmes avec votre application (je pense qu'il ya aussi un compteur de performance Windows qui exposera le nombre d'exceptions par seconde qui sont envoyées par l'application). Cela peut aider à découvrir des problèmes de cohérence des données potentielles dans votre application.
  2. Ajoutez un peu de suivi de la performance et l'exploitation forestière à toute persistance de données et / ou des dépendances de service réseau externe qui l'application peut être utilisé, telles que les requêtes de base de données de journalisation ou des appels de service Web qui prennent plus de temps que la quantité X de temps complet.

Si ce interagit avec une base de données, vous devriez avoir une idée de disque d'E / S et le degré de fragmentation de la matrice de disques / disque dur. Pour MS SQL, analyser les procédures stockées et examiner les index et les clés primaires sur les tables.

Vous avez vraiment besoin de ne pas les outils pour cela, tout le travail grognement de la révision des compteurs et de parler avec le DBA.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top