Tous ces points peuvent être appliqués au développement mobile, au frontend Web et au backend. J'ai rassemblé ces pratiques de différentes équipes et à travers les problèmes auxquels j'ai été confronté au cours des 6 dernières années. Ces pratiques peuvent être particulièrement utiles lorsque vous créez un projet à partir de zéro. Certains d'entre eux peuvent parfaitement vous convenir, d'autres non. Si vous avez vos propres approches et différentes expériences, je serais heureux si vous les partagez ici. Soit dit en passant, si vous êtes un développeur intermédiaire ou junior à la recherche d'une promotion, la mise en œuvre de ces pratiques dans votre équipe peut vraiment aider. Allons-y! 1. Se moquer des réponses du backend jusqu'à ce qu'il soit prêt Dans un processus de développement logiciel standard, lorsqu'une nouvelle demande de fonctionnalité provient de l'entreprise, elle est répartie entre plusieurs équipes : front-end, back-end et développement d'applications mobiles. Ensuite, chaque équipe procède à la planification et à la décomposition des tâches. Mais que se passe-t-il si l'équipe back-end a besoin de beaucoup plus de temps pour développer sa partie ? Et s'ils ne pouvaient livrer les terminaux qu'une fois par semaine ? Le backend devient un goulot d'étranglement. Les équipes de développement mobile et front-end finissent par travailler comme ceci : "Oh, le back-end a déjà implémenté cela. Laissez-moi prendre cette tâche." Ensuite, ils font une pause, basculent leur contexte vers une autre fonctionnalité, et le cycle continue. Cela entraîne de la fatigue, une diminution de la vitesse et une qualité réduite. convenir d'un contrat avec l'équipe back-end et se moquer de toutes les demandes. Solution : 1. Coordonner avec l'équipe back-end sur les terminaux et les entités. 2A. Implémentez l'API backend avec des réponses stub. La bibliothèque Faker peut aider à générer des exemples de données. 2B. Ou implémentez des stubs sur le frontend. Cela peut être un objet avec des données directement dans le code. Par exemple, dans Node.js, vous pouvez implémenter cela efficacement à l'aide d'importations dynamiques et éviter d'augmenter la taille du bundle : getUser() { return import('../../assets/mocks/users') .then(data => data.userById) .then(deserializeUser); }; Il peut également s'agir d'un faux service HTTP qui récupère des fichiers JSON à partir d'actifs au lieu de faire de vraies requêtes. Masquez la fonctionnalité derrière un indicateur de fonctionnalité. Lorsque le backend est prêt, passez à l'API réelle si vous avez utilisé l'approche des stubs frontaux et vérifiez que tout fonctionne comme prévu. Et activez cette fonctionnalité. 2. Indicateur de fonctionnalité Maintenant, comme vous l'avez probablement remarqué, dans la section précédente, j'ai mentionné les indicateurs de fonctionnalité. En un mot, les drapeaux de fonctionnalités, également appelés bascules de fonctionnalités, permettent aux développeurs d'activer ou de désactiver des fonctionnalités dans un environnement en direct. Il existe également quelques cas où ils sont utiles : déployer progressivement de nouvelles fonctionnalités, effectuer des tests A/B, activer des fonctionnalités bêta et implémenter des correctifs. Nous utilisons Gitlab pour stocker les drapeaux de fonctionnalités. Il s'agit d'un référentiel dédié utilisé à la fois par les projets backend et frontend. La bonne nouvelle est qu'il dispose d'une interface utilisateur conviviale, ce qui permet aux chefs de produit de gérer eux-mêmes les fonctionnalités. Auparavant, nous utilisions des indicateurs de fonctionnalité pour chaque référentiel de projet séparément. Cependant, cette approche ne permettait pas de désactiver les fonctionnalités pour l'ensemble du produit en une seule fois. Nous déplaçons donc tout vers le référentiel unique. Dans le code, ça a l'air assez simple : Dans le projet, nous récupérons tous les indicateurs de fonctionnalité actifs. Comme sous le capot, Gitlab est basé sur (feature toggle service), nous utilisons son client officiel. Unleash Et ensuite, mettez simplement dans le code qui doit être caché. if features.YOUR_FEATURE Vous pouvez étendre les cas d'utilisation en ajoutant différentes valeurs dans l'indicateur de fonctionnalité. Par exemple, en ajoutant la valeur de couleur ou la valeur de remise. 3. Surveillance des erreurs pour le suivi des problèmes dans un environnement de production Lorsque notre produit est passé de l'étape MVP à une application de production, nous craignions que les utilisateurs obtiennent des erreurs que nous ne pouvions pas reproduire et dont nous n'avions peut-être même pas conscience. Après avoir recherché des outils de suivi des erreurs, nous avons opté pour Sentry. L'expérience a été positive. Et maintenant, passons en revue quelques nuances importantes. Erreurs inutiles Sous le capot, toute exception non interceptée sera suivie. Au fur et à mesure que l'application et le nombre d'utilisateurs augmentent, le nombre d'erreurs peut devenir si écrasant qu'il devient presque impossible de remarquer quoi que ce soit de vraiment important. Sentry peut se transformer en poubelle si vous ne filtrez pas les éléments inutiles. Par exemple, des événements tels que des demandes annulées, des erreurs de connexion et des erreurs de scripts connectés sont totalement inutiles et ne feront que spammer votre messagerie professionnelle avec des notifications. Comme solution, vous pouvez ajouter des filtres à la configuration. Pour ce faire, définissez simplement un rappel et placez-le dans votre . Dans ce rappel, vous pouvez analyser chaque erreur détectée, puis la rejeter (en retournant null) si elle est inutile. Voici un exemple de filtre qui exclut les erreurs inutiles : beforeSend sentryPackage.init function beforeSend(event, hint) { const error = hint.originalException; const externalScripts = [ 'gtm.js', // Google Tag Manager 'watch.js', // X Analytics ].join('|'); const errorsToIgnore = [ AxiosError.ERR_NETWORK, AxiosError.ECONNABORTED, AxiosError.ETIMEDOUT ]; if (axios.isCancel(error) || errorsToIgnore.includes(error.code) || error.stack?.match(externalScripts)) { return null; } return event; } Inclure plus de données pour un meilleur débogage Par défaut, Sentry peut ne pas inclure le contenu de la demande et de la réponse dans le rapport d'erreurs. Sans ces informations, un débogage correct est impossible. Heureusement, dans le gestionnaire , nous pouvons inclure ces informations. beforeSend function beforeSend(event, hint) { const error = hint.originalException; if (error.isAxiosError) { const url = error.request?.responseURL; const response = error.response?.data; const request = error.config?.data; event.extra = { ...(event.extra || {}), url, response, request }; } return event; } Filtrer les informations sensibles Les données telles que les mots de passe, les adresses e-mail et les clés ne doivent pas être incluses dans le contenu de l'erreur. Sentry dispose d'un mécanisme intégré pour masquer ce type d'informations. Vous pouvez le configurer dans les paramètres de sécurité. De plus, vous pouvez également supprimer quelque chose dans l'objet événement dans beforeSend Solution autonome Si la nature de votre entreprise interdit de stocker ce type de données sur un serveur ailleurs, Sentry offre la possibilité de l'utiliser sur vos propres serveurs. 4. Traçage Imaginez une situation dans laquelle vous capturez avec succès une erreur dans Sentry, mais les informations contenues dans la description sont insuffisantes. Vous vous tournez vers les journaux, mais comment pouvez-vous identifier l'erreur spécifique parmi des milliers de requêtes et encore plus de lignes de journal par seconde ? Comment pouvez-vous distinguer les bonnes, construire la chaîne de demandes et identifier l'erreur exacte, en particulier lorsque votre entreprise compte plusieurs équipes et s'intègre à d'autres services ? C'est là que le traçage entre en jeu. Le traçage fournit un diagramme complet des appels et identifie la méthode précise qui a échoué, même lorsque vous avez une communication asynchrone effectuée par un courtier de messages. Il vous permet de déterminer facilement de quel côté l'erreur s'est produite lors de l'intégration avec différentes équipes. Le traçage est également utile pour le débogage des performances. Par exemple, cela peut aider à clarifier si le rendu prend plus de temps ou si une méthode dans un microservice n'est pas suffisamment optimisée. Dans notre implémentation spécifique, nous avons utilisé , qui est basé sur l'API OpenTracing. Jaeger En un mot, chaque requête et tous ses appels de méthode sont étiquetés avec une étiquette unique. Chaque étiquette a une référence à son parent et certaines métadonnées. La structure de ce numéro dépend de l'implémentation, mais comme pour OpenTracing, vous pouvez lire comment cela fonctionne et vous familiariser avec des termes tels que span, reference, child, parent, etc. sur la . Dans la vraie vie, le traçage sera heureusement rarement utilisé. Cependant, dans ces rares accidents, cela peut vous faire gagner du temps. page officielle du référentiel 5.Optimisation des performances Lorsque nous avons implémenté le MVP de l'application fintech, nous avions un formulaire assez compliqué. A cette époque, j'étais encore jeune et inexpérimenté. Et finalement, nous avons réalisé que notre projet ralentissait. Nous avons dû passer des heures supplémentaires à comprendre la raison. Nous avons eu de nombreux rendus inutiles car nous avons ignoré les règles de base liées aux accessoires dans React. Je voulais faire tout mon possible pour éviter de telles situations à l'avenir. J'ai donc ajouté au projet des linters comme et une configuration de départ supplémentaire à package.json pour exécuter . En bref, ce plugin émet un avertissement si quelque chose est rendu inutilement et suggère comment l'éviter. De plus, nous avons inclus l'exécution . Certaines personnes disent que les optimisations prématurées sont mauvaises, mais pour moi, c'est un principe : . celui-ci why-did-you-render de Lighthouse en mode sans tête faites-le dès le départ 6. Style de code défini pour tous les projets d'équipe Vous avez probablement entendu parler de la S'il y a une fenêtre cassée dans un bâtiment et que personne ne la remplace, il ne restera finalement plus une seule fenêtre intacte dans ce bâtiment. théorie des fenêtres brisées. Moins il y a de règles et de contrôles dans un projet, plus la tentation est grande d'écrire du code de mauvaise qualité ou de l'écrire dans un style totalement différent. Un code incohérent augmente le temps nécessaire pour le comprendre, tandis qu'un code clair, familier et concis permet une lecture rapide. Dans l'une de nos équipes, nous avons décrit le style de codage . Comme excellent point de départ, vous pouvez prendre le style de code ou . en un seul endroit Prettier Airbnb 7.Tests de régression Une quantité importante de littérature a déjà été écrite sur les différents types de tests, les approches et la manière de les rédiger correctement. La seule chose qui mérite d'être mentionnée ici est qu'aucune application de production ne peut survivre sans test de régression. C'est pourquoi nous avons concentré tous nos efforts sur la création d'un cadre de test complet de bout en bout et sur cette base, nous avons écrit des tests qui sont liés aux scénarios BDD et aux user stories. Nous avons utilisé le modèle Page Object pour organiser notre code et le framework Playwright pour interagir avec le navigateur. Pour tester sur différents navigateurs, y compris Safari, vous pouvez utiliser une solution appelée . Il peut être déployé sur l'un de vos serveurs. Moon Conclusion Merci d'avoir pris le temps de lire cet article ! En conclusion, cet article met en lumière les principales pratiques d'ingénierie logicielle qui améliorent les processus de développement et la qualité du code. En adoptant des techniques telles que la simulation de réponse backend, les indicateurs de fonctionnalité, la surveillance des erreurs, l'optimisation des performances, les normes de style de code, les tests de régression et le traçage, vous pouvez créer des logiciels plus efficaces et plus fiables. Continuons à améliorer notre logiciel et restons en contact ! :)

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Making security fun one episode at a time

7 pratiques éprouvées pour accélérer le développement et la qualité des projets

Trop long; Pour lire

Daniil Sitdikov

STORY’S CREDIBILITY

Code License

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

7 pratiques éprouvées pour accélérer le développement et la qualité des projets

Trop long; Pour lire

Daniil Sitdikov

STORY’S CREDIBILITY

Code License

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

HISTOIRES CONNEXES