Méthodes de débogage du code (situation Nightmare)

Je suis fréquemment chargé de déboguer une application à mon travail. Il s'agit d'une application BI que nous déployons dans les entreprises, qui comprend un environnement de test et un environnement de production. Je me demande s'il existe des applications / outils / méthodes que les gens peuvent suggérer, en fonction de ces contraintes:

1. Le débogueur ne peut pas être utilisé sur le site client ou localement, car le logiciel dépend d'applications tierces personnalisées pour lesquelles nous n'avons pas d'environnements de test. (EDIT: pour être honnête, il est possible de déboguer localement dans certains cas. Si nous n'utilisons que le code de base. Une grande partie du code problématique réside dans une DLL qui encapsule la communication spécifique de tiers: sockets, processus, tuyaux, appels de savon, logique personnalisée qui modifie le comportement du code principal. Généralement, lors d'une implémentation ou d'une amélioration pour un client, nous écrivons du nouveau code dans cette zone.)

2. Il n'y a pratiquement aucune journalisation effectuée dans nos applications. Il n'y a pas de tests unitaires.

3. Le contrôle de version ne comporte qu'une seule version de la solution complète (en utilisant Source Safe 2005). Il n'est donc pas possible d'obtenir une version précédente de la solution entière, uniquement des fichiers individuels. (Sauf si quelqu'un sait comment contourner cela).

4. Ne peut pas se reproduire localement, souvent les temps ne peuvent pas se reproduire sur l'environnement de test (Fortes chances que le test et la production ne soient pas la même version).

5. Il est fort probable que la version utilisée par le client soit différente de celle du coffre-fort à la source. Cela est dû au fait que les fichiers individuels sont mis à jour, qui ont incorporé une logique personnalisée pour ce client spécifique. Souvent, ce qui se passe, c'est qu'une mise à jour est effectuée sur un binaire, ce qui nécessite des modifications dans plusieurs autres fichiers binaires, mais lorsqu'une validation est effectuée, personne n'a aucun enregistrement ou connaissance de cela. Une erreur quelque peu courante que je vois est la «fonction / méthode non trouvée» ou «l'appel de méthode a trop / trop peu de paramètres spécifiés» sur un environnement client.

6. Ceci est une solution .net VB

7. Impossible d'installer un logiciel sur les sites clients, mais peut localement

8. Notre application est extrêmement personnalisable, mais malheureusement, la logique de personnalisation est répartie sur toutes les classes et tous les fichiers, depuis le front-end jusqu'à la couche de données, y compris les modifications personnalisées apportées à la base de données client par client.

9. Il n'y a pratiquement aucun commentaire dans le code. Il n'y a aucune documentation sur l'architecture. Aucune documentation sur l'API. La seule chose que nous avons, ce sont des centaines et des centaines de chaînes de messagerie qui expliquent quelque peu ce qui se passe. Les seules personnes qui connaissent le code sont celles qui l'ont écrit à l'origine, mais elles ne sont plus des développeurs, donc elles ne s'impliquent pas beaucoup.

Et avant de le dire ... oui je sais; Je veux aussi me tirer dessus. Cela n'aide pas qu'il y ait du code spaghetti, des centaines d'avertissements du compilateur et un polymorphisme cassé qui devraient VRAIMENT être corrigés, mais je n'ai pas mon mot à dire.

Les erreurs les plus courantes que je rencontre sont des erreurs de référence nulles, des transtypages invalides et des incompatibilités de fonctions / signatures de fonctions manquantes. Parfois, j'ai de la chance et l'observateur d'événements enregistrera la classe, la méthode et le message d'exception. Ce n'est pas le plus utile, mais c'est quand même quelque chose. Les pires sont les erreurs qui n'ont aucune trace, aucune étape de repro à part une capture d'écran, et sont des messages d'erreur génériques comme ceux mentionnés ci-dessus. Parfois, il n'est pas possible de savoir pourquoi ils se sont produits, mais seulement de prier pour que l'environnement ne soit pas correctement configuré et qu'il disparaisse plus tard.

Je sais que cela se présente comme une sorte de diatribe, et dans une certaine mesure c'est le cas. Mais je cherche désespérément des options. Y a-t-il d'autres méthodes / outils que je peux utiliser?

Les conseils de Robert Harvey sont probablement les meilleurs, mais comme les conseils de carrière sont hors sujet, je vais donner la réponse qui peut être donnée:

Vous êtes au bas d'une montagne très raide couverte de ronces et de boue et de chèvres de montagne irritables. Il n'y a pas de chemin facile. Si vous voulez atteindre le sommet, vous devez vous frayer un chemin extrêmement douloureux à la fois.

Il semble que vous sachiez exactement comment les choses devraient fonctionner. Si personne d'autre ne vous aidera, alors (encore une fois, en ignorant les conseils de carrière), votre seul choix est de commencer à réparer ces choses vous-même.

Tout d'abord, pour tout ce qui est sacré, récupérez ces informations dans un véritable système de contrôle de version. À peu près tout sauf Source Safe, qui est bien connu comme une pile de déchets puants. gitest gratuit et peut être configuré assez facilement. Vous ne pouvez pas résoudre les problèmes liés au manque de contrôle de version passé, mais au moins empêcher le problème de continuer dans le futur.

Ensuite, examinez la journalisation. Trouvez, ou pire, écrivez un système de journalisation et commencez à l'utiliser. Utilisez-en un qui peut également être utilisé sur les sites clients, donc lorsque les choses tournent de côté, vous avez au moins quelque chose.

Et commencez à écrire des tests, au moins pour les nouvelles modifications que vous apportez.

Il n'y a pas de sucre enrobant: il n'y a pas de réponse ici qui n'implique pas beaucoup de travail, ou qui traite cela comme une question de carrière.

1) Le débogueur ne peut pas être utilisé sur le site client ...

C'est parfaitement normal.

... ou localement

Voilà un problème.

2) Il n'y a pratiquement aucune journalisation effectuée dans nos applications.

La journalisation est le débogage de production.

Il n'y a pas de tests unitaires.

Oh cher. Tout est commun, cependant.

3) Le contrôle de version n'a qu'une seule version de la solution complète

Ensuite, vous n'utilisez pas le contrôle de version.

4) Ne peut pas se reproduire localement, souvent les temps ne peuvent pas se reproduire sur l'environnement de test (Fortes chances que le test et la production ne soient pas la même version).

Ainsi, seul l'environnement client déployé affiche les erreurs.

Dans ce cas, vous avez besoin d'une journalisation disgnostique intégrée dans le code d'application qui (a) intercepte et enregistre [entièrement] les erreurs [fatales] et (b) peut être "composée" à la demande pour produire des diagnostics supplémentaires, continus, qui sont utiles dans traquer le (s) problème (s).

5) Il y a de fortes chances que la version utilisée par le client soit différente de celle du coffre-fort à la source.

Encore une fois, vous n'utilisez simplement pas le contrôle de version à votre avantage.

8) Notre application est extrêmement personnalisable

C'est assez typique.

Les différences spécifiques au site doivent être gérées via le contrôle de version "Branching".

9) Il n'y a pratiquement aucun commentaire dans le code.

Encore une fois, c'est trop courant, car les développeurs écrivent du code "auto-documenté", n'est-ce pas?
Ou, au moins, du code qu'ils comprennent le jour où ils l'écrivent.

Il n'y a aucune documentation sur l'architecture.

Oh cher.

Aucune documentation sur l'API.

Oh mon cher, oh mon cher.

Et avant de le dire ... oui je sais; Je veux aussi me tirer dessus.

Non; vous voulez tirer sur les gens qui ont écrit tout ça, créé un gâchis non documenté et impossible à entretenir, puis sont passés à de nouveaux pâturages, laissant le désordre inadmissible derrière eux.

Les erreurs les plus courantes que je rencontre sont des erreurs de référence nulles, des transtypages invalides et des incompatibilités de fonctions / signatures de fonctions manquantes.

Les références nulles et les transtypages non valides sont des erreurs d'exécution; dans une certaine mesure, vous devriez les attendre et le fait qu'ils vous les obtiennent fréquemment suggère un manque de programmation défensive (ou un surplus d'optimisme) par les auteurs originaux.

Les incompatibilités de signature de fonction devraient provoquer une construction cassée ; ceux-ci devraient provoquer des «constructions cassées» et ne devraient jamais sortir de la porte!

Commencez par la journalisation. Cela aura le plus grand impact. Implémentez un cadre de journalisation dans la base de code, comme Log4Net ou similaire. Commencez à enregistrer ce que fait le code.

Le débogage devrait être possible localement. Sinon, essayez d'obtenir les fichiers de symboles (PDB) afin de pouvoir déboguer dans des DLL tierces pour obtenir une image complète des problèmes qui se produisent. Des outils comme WINDBG peuvent indiquer quelles DLL sont problématiques si le système plante. On peut configurer n'importe quel serveur pour prendre un vidage de mémoire en cas de plantage. Il s'agit essentiellement d'un instantané de ce qui se passait lorsque le problème est survenu. On peut examiner les décharges localement pour trouver des indices sur ce qui se passait. Si le débogage n'est pas possible, essayez de le rendre possible. Documentez les étapes nécessaires au débogage. Parfois, sur des systèmes complexes, il y a beaucoup de configuration nécessaire pour déboguer complètement.

Suivi des bogues ... Si vous n'en utilisez pas, commencez à en utiliser un. Cela va de pair avec un système de contrôle de version approprié. Fondamentalement, commencez à suivre les défauts et les révisions de votre code. Commencez à construire un historique du système.

Effectuez une analyse de code statique. Investissez dans un outil comme ReSharper. Il indiquera rapidement toutes les exceptions de référence nulle possibles et autres mauvaises pratiques de codage. Il peut aider à améliorer le code en quelques clics et automatiser des éléments fastidieux tels que le formatage du code, la dénomination des variables, etc.

Refactor et tests unitaires. Je vais supposer que la plupart du code écrit n'est probablement pas très testable, donc je ne prendrais pas la peine d'ajouter des tests pour cela. Tout nouveau code, créez un projet de tests et commencez à écrire des tests, à la fois unitaires et d'intégration. Si les tests unitaires échouent, échouez la construction. Donc, comme vous refactorisez, il devrait y avoir des tests. Une chose avec les tests est que l'on peut écrire un test pour appeler n'importe quelle méthode et déboguer dans cette méthode sans charger l'intégralité de l'application ou de la base de code. Ceci est utile pour aider à résoudre les problèmes.

Documentez toute connaissance tribale au besoin. Le code doit être auto-documenté afin que les commentaires soient clairsemés, mais de nombreux systèmes ont des façons de faire "inhabituelles", signalez-les dans un WIKI de codage ou un autre type de référentiel informel. Envisagez également d'élaborer des normes et des pratiques de codage. Appliquez ces normes via un ensemble d'outils comme Resharper. Étant donné que la plupart du code ne suit probablement aucune norme ni aucune directive, implémentez les normes sur le nouveau code écrit.

Depuis votre nouveau, je traiterais cela comme une période de service. 6 mois à 2 ans, puis faites le choix de rester ou de partir. Prenez plaisir à rendre les choses légèrement meilleures que la veille.

Tout d'abord, tout ce qui précède ... idem.

Quelques heuristiques:

• Utilisez le contrôle de code source sur votre ordinateur de développement. C'est la meilleure chose que j'ai faite. Il ne remplace pas le contrôle de version du projet, que nous avons. C'est un outil qui donne une liberté incroyable pour expérimenter, pirater, résoudre des problèmes simultanément mais indépendamment, etc. Je suis meilleur dans l'utilisation du contrôle de version parce que j'ai la liberté d'être audacieux, de bousiller et d'apprendre.
  • Quelle est la différence entre Git et Mecurial?
  • Git est Mcgyver, Mecurial est James Bond
• Dans la mesure où vous ajoutez des commentaires, hiérarchisez les éléments de l'interface publique pour tirer parti d'Intellisense. Faites-le pendant que vous déchiffrez pendant vos aventures de débogage.
• Soyez persistant avec des refactorisations mineures. Tôt ou tard, pour un morceau de code donné, vous atteindrez une masse critique qui permettra de gros remaniements comme le SECHAGE du code redondant entre les classes.
• Ne mélangez pas le reformatage de code et les changements réels dans les mêmes validations de contrôle de version.
• Principes SOLIDES
  • N'ignorez jamais une seule responsabilité. Bien joué, c'est le chemin vers la promesse de l'orienté objet; A MON HUMBLE AVIS.
  • Ignorez toujours Open / Closed.
  • Nous ne parlons pas de nouveau code ici.
  • La création d'interfaces sans conception ciblée entrave la maintenance.
• Refactoring
  • Il y a une méthodologie . Achetez le livre.
  • Refactoring: améliorer la conception du code existant
• Certains fichiers de code nécessitent un reformatage complet, un changement de nom des variables, etc. avant même de tenter le débogage. N'hésitez pas à utiliser le menu de refonte de Visual Studio sans tests unitaires.
• La seule documentation qui ne peut pas être égarée se trouve dans les fichiers de code.
• Lorsque vous obtenez le contrôle de version, réfléchissez au plan VC. Et documentez-le! Et proposez une convention de dénomination pour les succursales, des balises qui mettront en évidence les principales versions et étapes du logiciel.
• Utilisez un bon équipement
  • Obtenez un moniteur qui pivote. Vertical est le moyen de lire rapidement le code.
  • Disque externe pour les sauvegardes, clavier avec le bon type de touches , souris multifonction. Au moins 1 très bonne clé USB. J'ai même ma propre chaise Herman Miller .
  • Obtenez un très bon logiciel de comparaison. Je suis satisfait de Beyond Compare .
• Pratiquez le débogage de Ducky en caoutchouc
• Parfois, la pire chose qui puisse arriver est qu'ils ne vous licencient pas.

Éditer

Développement d'applications Brownfield dans .NET

Essayez ce livre. Une première couverture pour lire est probablement la meilleure. Ce livre vous aidera à réfléchir à la vue d'ensemble, aux possibilités et à l'élaboration de plans d'attaque stratégiques et tactiques.

Tenir le coup

Restez, disons, 1,5 an si vous le pouvez; assez longtemps pour savoir si vous faites des progrès expérientiels. Vous saurez si vous acquérez 2 ans d'expérience ou 6 mois d'expérience 4 fois.

Étant «junior avec 1/2 ans d'expérience», je crains qu'un employeur potentiel ne le considère comme renflouant tôt parce que vous ne pouvez pas le pirater. C'est une chose de dire que vous avez appris z, y, x, pris des noms et donné des coups de pied dans le cul - mais que vous n'avez pas été autorisé à contribuer à vos capacités; et un autre risque simplement de disséquer le travail, le code, la gestion, etc. à titre d'explication.

Je suis peut-être en dehors de cette base, mais mon "meilleur temps et le pire des temps" a été mon premier travail, qui s'est avéré être un code littéralement incontrôlable. J'avais un super superviseur (tout le reste venait du programme de gestion de l'élevage) qui m'a donné l'espace pour réécrire certains programmes clés. Cette expérience a été une révélation.

fin Modifier

Je dirais que (5) est celui que vous devez corriger en premier. Si vous ne savez pas quel code s'exécute en production, vous n'avez aucun moyen sûr de reproduire et de résoudre les problèmes. Cela rend tout autre changement que vous introduisez dangereux, car il peut provoquer des problèmes que vous ne pouvez pas prévoir et ne pouvez pas reproduire.

Vous devrez peut-être faire un travail de détective et peut-être faire de l'ingénierie inverse pour déterminer quelle (s) version (s) de code et quelles bibliothèques sont déployées. (Et vous avez besoin d'un système de génération et de déploiement cohérent pour mettre tout le code déployé en conformité avec le contrôle des sources à l'avenir.)

Vous devrez peut-être créer plusieurs environnements de test pour répliquer les différents déploiements. (Bien sûr, la solution la plus simple consiste à créer une nouvelle version propre et à la déployer de manière cohérente partout, mais il semble que ce ne soit pas possible?)

Ce n'est que lorsque vous connaissez les versions exactes déployées et que vous disposez des environnements de test correspondants, que vous devez commencer à essayer de corriger / améliorer le code.

Votre prochaine priorité devrait être de consolider en une base de code unique qui peut être déployée partout. Il semble que vous ayez déployé différentes versions de code en raison de la personnalisation? Vous devez consolider vers une seule version, puis utiliser des commutateurs de configuration pour la logique personnalisée.

Après cela, vous pouvez commencer à améliorer soigneusement la base de code pour faciliter le débogage. L'ajout de la journalisation est probablement les améliorations les moins risquées.

Vous souhaiterez peut-être ajouter des tests automatisés, mais il est souvent difficile d'ajouter des tests à un projet qui n'est pas initialement conçu pour les tests. Au lieu de cela, je recommande de commencer par des tests d'intégration de bout en bout automatisés. Celles-ci sont plus difficiles à configurer, mais ne nécessitent pas que vous ré-architecturiez la solution, elles sont donc moins risquées.

Ignorant les problèmes que vous rencontrez dans votre équipe, il semble que le premier à résoudre est de déboguer le code correspondant à ce qui est en production. Sinon, vous pourriez être en train de chasser un bogue qui a déjà été corrigé dans le code que vous avez dans votre "Contrôle source". Comme il s'agit de .NET, vous pouvez facilement "décompiler" les binaires de production pour comparer le code avec ce que vous avez. Ce n'est pas une tâche facile, mais si vous réussissez, c'est un argument solide pour un meilleur outil de contrôle des sources qui peut étiqueter les versions publiées.