7 techniques de débogage pour les développeurs pour accélérer le dépannage en production

0
102


La prise en charge de la production d’une application est l’un des aspects les plus difficiles du développement logiciel. Développeurs sont affectés à l’équipe de maintenance et travaillent sur le patch des bugs de l’application. Cependant, ils sont également disponibles sur appel en cas de panne de production, auquel cas ils travaillent pour remettre l’application sur les rails le plus rapidement possible.

Cet article vise à fournir un ensemble de recommandations organisées afin que vous puissiez éviter les bogues en production et trouver les problèmes beaucoup plus rapidement. La gestion de ces applications en production est une tâche compliquée: souvent, aucune documentation n’est disponible, l’application a été écrite dans une pile technologique héritée, ou les deux. Il y a très peu de sessions de formation, et il est courant d’être appelé pour fournir une assistance pour une application que vous connaissez peu.

De nombreux développeurs n’ont pas d’expérience dans la gestion d’une application en production. Il existe un éventail de problèmes qui se produisent dans les environnements de production qui provoquent des bugs et des pannes, entraînant généralement des milliers et parfois des millions de dollars de perte de revenus pour l’entreprise. De plus, comme la majorité des développeurs ne sont pas exposés à l’environnement, ils continuent de commettre des erreurs qui, à leur tour, causeront ces problèmes. Cette liste de conseils devrait rendre votre travail moins pénible en enseignant à partir de l’expérience de production.

Conseil n ° 1: supprimez ou automatisez toute la configuration nécessaire au fonctionnement de l’application

Quelle est la configuration requise pour installer le logiciel sur un nouveau serveur? Dans le passé, cela pouvait parfois prendre trois jours à chaque fois qu’il y avait un nouveau développeur dans l’équipe. L’installation de l’application nécessiterait de nombreuses étapes qui doivent être effectuées manuellement. Au fil du temps, le logiciel évolue vers de nouvelles versions qui deviennent incompatibles avec ces instructions, et bien sûr, les instructions ne sont généralement pas mises à jour. Du coup, vous passez beaucoup plus de temps que nécessaire simplement pour que l’application soit opérationnelle.

Avec l’avènement de conteneurisation, il est devenu beaucoup plus facile de fournir un moyen de faire fonctionner une application en un rien de temps, avec une configuration nulle et avec l’avantage supplémentaire que, puisque l’image Docker est autonome, vous courez un risque beaucoup plus faible de problèmes avec différentes versions du système d’exploitation, des langues et des frameworks utilisés.

De même, simplifiez la configuration du développeur, donc cela ne prendra pas beaucoup de temps pour être opérationnel, y compris la configuration IDE. Un développeur devrait pouvoir passer de zéro à héros en moins de 30 minutes.

Lorsqu’un problème de production survient, il se peut que vos meilleurs experts ne soient pas disponibles (par exemple, vacances ou maladie) et que vous souhaitiez que la personne à qui vous posez le problème soit en mesure de le résoudre rapidement.

Astuce n ° 2: ne tombez pas dans le piège à soupe tech stack

Moins il y a de technologies utilisées, mieux c’est. Bien sûr, parfois, vous devez utiliser le bon outil pour le travail. Cependant, veillez à ne pas surcharger les «bons outils». Même l’eau potable peut entraîner de graves problèmes de santé si vous en faites trop. Chaque nouveau langage et cadre ajouté à la pile technologique doit passer par un processus de prise de décision clairement défini avec une attention particulière aux impacts.

  • N’ajoutez pas une nouvelle dépendance de framework simplement parce que vous avez besoin d’un StringUtils classe.
  • N’ajoutez pas une langue complètement nouvelle simplement parce que vous devez écrire un script rapide pour déplacer des fichiers.

Une grosse pile de dépendances peut vous rendre la vie misérable lorsque les bibliothèques deviennent incompatibles ou lorsque des menaces de sécurité sont trouvées soit sur les frameworks eux-mêmes, soit sur leurs dépendances transitoires.

De plus, rappelez-vous, les complexités de pile supplémentaires rendent difficile la recherche et la formation de nouveaux développeurs pour l’équipe. Les gens passent à de nouveaux rôles dans d’autres entreprises et vous devez en trouver de nouveaux. Le chiffre d’affaires est très élevé dans les équipes d’ingénierie, même dans les entreprises reconnues pour leurs excellents avantages et leur équilibre entre vie professionnelle et vie privée. Vous souhaitez trouver le nouveau membre de l’équipe le plus rapidement possible. Chaque nouvelle technologie ajoutée au sommet de la pile technologique augmente le temps pour trouver un nouveau candidat et a le potentiel de rendre les nouvelles embauches de plus en plus chères.

Astuce # 3: La journalisation doit vous guider pour trouver le problème, pas vous noyer avec des détails inutiles

La journalisation est très similaire aux commentaires. Il est nécessaire de documenter toutes les décisions critiques prises ainsi que toutes les informations à utiliser dans vos techniques de débogage. Ce n’est pas simple, mais avec un peu d’expérience, il est possible de cartographier quelques scénarios possibles de pannes de production, puis de mettre en place la journalisation nécessaire pour résoudre au moins cela. Bien sûr, la journalisation évolue avec la base de code en fonction du type de problèmes qui apparaissent. De manière générale, vous devriez avoir 80% de votre connexion sur les 20% les plus importants de votre code, la partie qui sera la plus utilisée. Les informations importantes, par exemple, sont les valeurs des arguments passés dans une méthode, les types d’exécution des classes enfants et les décisions importantes prises par le logiciel, c’est-à-dire le moment où il était à la croisée des chemins, et il a choisi gauche ou droite.

Conseil n ° 4: gérez les situations inattendues

Cartographiez très clairement quelles sont les hypothèses du code. Si une certaine variable doit toujours contenir les valeurs 2, 5 ou 7, assurez-vous qu’elle est de type enum, pas int. La principale source de pannes de production importantes est lorsqu’une certaine hypothèse échoue. Tout le monde cherche le problème au mauvais endroit parce qu’il tient certaines choses pour acquises.

Les hypothèses doivent être documentées de manière explicite et tout échec à ces hypothèses devrait déclencher suffisamment d’alarmes support de production l’équipe peut rapidement rectifier la situation. Il devrait également y avoir du code pour empêcher les données de passer dans un état non valide, ou au moins de créer une sorte d’alerte dans ce cas. Si certaines informations doivent être stockées dans un seul enregistrement et qu’il y a soudainement deux enregistrements, un avertissement doit être déclenché.

Astuce n ° 5: Il devrait être simple de reproduire un problème qui arrive à un client

L’une des étapes les plus difficiles consiste toujours à reproduire le problème rencontré par le client. Plusieurs fois, vous passerez 95% du temps à essayer de répliquer le problème, puis au moment où vous pourrez le répliquer, il ne vous faudra que quelques minutes pour corriger, tester et déployer. En tant que tel, l’architecte d’application doit s’assurer qu’il est extrêmement simple et rapide de reproduire les problèmes. Cela se produit en grande partie parce que, pour arriver à la même situation dans laquelle se trouve le client, le développeur doit effectuer une quantité importante de configuration d’application. Il existe de nombreux enregistrements stockés qui aggravent la situation dans laquelle se trouve le client, le problème étant que vous, en tant que développeur, devez deviner exactement ce qu’a fait le client. Et parfois, ils ont effectué une séquence d’étapes, dont ils ne se souviennent que de la dernière.

Le client expliquera également le problème en termes commerciaux, que le développeur devra ensuite traduire en termes techniques. Et si le développeur a moins d’expérience avec l’application, il ne saura pas demander les détails manquants, car il ne connaît même pas encore les détails manquants. Il est impossible de copier l’intégralité de la base de données de production sur votre machine. Il devrait donc y avoir un outil pour importer rapidement de la base de données de production uniquement les quelques enregistrements nécessaires pour simuler la situation.

Supposons que le client rencontre un problème avec l’écran Commandes. Vous devrez peut-être importer quelques-unes de leurs commandes, leur enregistrement client, certains enregistrements de détail de commande, des enregistrements de configuration de commande, etc. Ensuite, vous pouvez exporter cela dans une base de données dans une instance Docker, lancer cette instance, et juste comme ça, vous êtes voir la même chose que le client voit. Tout cela, bien sûr, doit être fait avec le soin approprié pour garantir qu’aucun développeur n’a accès aux données sensibles.

Astuce # 6: Il devrait être évident où placer les points d’arrêt dans l’application

Si vous avez un écran Client, il devrait y avoir un objet Client où vous pouvez placer les points d’arrêt pour déboguer un problème sur cet écran. Parfois, les développeurs tombent dans la fièvre de l’abstraction et proposent des concepts incroyablement intelligents sur la façon de gérer les événements de l’interface utilisateur. Au lieu de cela, nous devons toujours nous baser sur le principe KISS (Keep it Simple, Ster, Silly) et avoir une méthode facilement localisable par événement UI. De même, pour les travaux de traitement par lots et les tâches planifiées, il devrait y avoir un moyen facile de repérer où les points d’arrêt de lieu pour évaluer si ce code fonctionne ou non.

Astuce # 7: Assurez-vous que toutes les dépendances externes sont explicitement documentées

Idéalement, faites-le dans le fichier README du système de contrôle de source afin que la documentation ne puisse pas être perdue. Documentez tous les systèmes, bases de données ou ressources externes qui doivent être disponibles pour que l’application s’exécute correctement. Notez également lesquelles sont facultatives et ajoutez des instructions sur la façon de les gérer lorsqu’elles sont facultatives et non disponibles.

Au-delà des techniques de débogage

Une fois ces recommandations suivies lors de la création de nouvelles fonctionnalités ou de la maintenance d’un système, le support de production deviendra beaucoup plus facile et votre entreprise passera beaucoup moins de temps (et d’argent). Comme vous le savez déjà, le temps est primordial lors du dépannage des bogues de production et des plantages – chaque minute qui peut être enregistrée fait une grande différence en fin de compte. Bon codage!

le Blog d’ingénierie Toptal est un hub pour des didacticiels de développement approfondis et des annonces de nouvelles technologies créés par des ingénieurs logiciels professionnels du réseau Toptal. Vous pouvez lire la pièce originale écrite par Flavio Pezzini ici. Suivez le blog Toptal Design sur Twitter et LinkedIn.

Lire ensuite:

Chipmaker Qualcomm investit 97 millions de dollars dans les plates-formes Jio

Pssst, hé vous!

Voulez-vous recevoir la newsletter technique quotidienne la plus sassée chaque jour, dans votre boîte de réception, GRATUITEMENT? Bien sûr que vous le faites: inscrivez-vous à Big Spam ici.