Cet article a été révisé par des pairs par Tom Greco, Dan Prince et Yaphi Berhanu. Merci à tous les pairs examinateurs de SitePoint pour avoir fait du contenu SitePoint le meilleur possible!
Presque tous les développeurs ont eu l'expérience de maintenir ou de reprendre un projet hérité. Ou, peut-être que c'est un ancien projet qui a été repris. Les premières pensées courantes sont de jeter la base de code et de commencer à zéro. Le code peut être désordonné, sans papiers et il peut prendre des jours pour tout comprendre. Mais, avec une planification, une analyse appropriée et un bon flux de travail, il est possible de transformer une base de code spaghetti en une base de spaghetti en une base propre, organisée et évolutive.
J'ai dû prendre le relais et nettoyer beaucoup de projets. Il n'y en a pas eu beaucoup que j'ai commencé à zéro. En fait, je fais actuellement cela. J'ai beaucoup appris concernant JavaScript, en gardant une base de code organisée et - surtout - ne pas être fou au développeur précédent. Dans cet article, je veux vous montrer mes étapes et vous dire mon expérience.
La toute première étape consiste à obtenir un aperçu de ce qui se passe. S'il s'agit d'un site Web, cliquez sur votre chemin via toutes les fonctionnalités: ouvrez les modaux, envoyez des formulaires et ainsi de suite. Ce faisant, demandez aux outils du développeur ouverts, pour voir si des erreurs apparaissent ou que tout est enregistré. S'il s'agit d'un projet Node.js, ouvrez l'interface de ligne de commande et passez par l'API. Dans le meilleur des cas, le projet a un point d'entrée (par exemple Main.js, index.js, app.js,…) où tous les modules sont initialisés ou, dans le pire des cas, la logique métier entière est située.
Découvrez quels outils sont utilisés. jQuery? Réagir? Exprimer? Faites une liste de tout ce qui est important à savoir. Disons que le projet est écrit dans Angular 2 et que vous n'avez pas travaillé avec cela, allez directement à la documentation et obtenez une compréhension de base. Rechercher les meilleures pratiques.
Connaître les technologies est un bon début, mais pour avoir une sensation et une compréhension réelles, il est temps d'examiner les tests unitaires. Le test unitaire est un moyen de tester les fonctionnalités et les méthodes de votre code pour vous assurer que votre code se comporte comme prévu. La lecture - et l'exécution - les tests unitaires vous donnent une compréhension beaucoup plus profonde que la lecture du code. S'ils ne sont pas des tests unitaires dans votre projet, ne vous inquiétez pas, nous y reviendrons.
Il s'agit d'établir une cohérence. Maintenant que vous avez toutes les informations sur la chaîne d'outils de projets, vous connaissez la structure et comment la logique est connectée, il est temps de créer une base de référence. Je recommande d'ajouter un fichier .EditorConfig pour garder le codage des guides de style cohérents entre différents éditeurs, IDE et développeurs.
La célèbre question (c'est plutôt une war cependant), que les espaces ou les onglets soient utilisés, n'a pas d'importance. La base de code est-elle écrite dans des espaces? Continuez avec les espaces. Avec des onglets? Utilisez-les. Ce n'est que lorsque la base de code a une indentation mixte est nécessaire de décider laquelle utiliser. Les opinions sont bien, mais un bon projet s'assure que tous les développeurs peuvent fonctionner sans tracas.
Pourquoi est-ce encore important? Tout le monde a sa propre façon d'utiliser un éditeur ou un IDE. Par exemple, je suis un grand fan du pliage de code. Sans cette fonctionnalité, je suis littéralement perdu dans un fichier. Lorsque l'indentation n'est pas cohérente, ces fonctionnalités échouent. Donc, chaque fois que j'ouvre un fichier, je devrais corriger l'indentation avant même que je puisse commencer à travailler. C'est une énorme perte de temps.
<span>// While this is valid JavaScript, the block can't
</span><span>// be properly folded due to its mixed indentation.
</span> <span>function foo (data) {
</span> <span>let property = String(data);
</span>
<span>if (property === 'bar') {
</span> property <span>= doSomething(property);
</span> <span>}
</span> <span>//... more logic.
</span> <span>}
</span>
<span>// Correct indentation makes the code block foldable,
</span><span>// enabling a better experience and clean codebase.
</span><span>function foo (data) {
</span> <span>let property = String(data);
</span>
<span>if (property === 'bar') {
</span> property <span>= doSomething(property);
</span> <span>}
</span> <span>//... more logic.
</span><span>}
</span>Assurez-vous que la convention de dénomination utilisée dans le projet est respectée. CamelCase est couramment utilisé dans le code JavaScript, mais j'ai beaucoup vu des conventions mixtes. Par exemple, les projets JQuery ont souvent une dénomination mixte des variables d'objets jQuery et d'autres variables.
<span>// Inconsistent naming makes it harder
</span><span>// to scan and understand the code. It can also
</span><span>// lead to false expectations.
</span><span>const $element = $('.element');
</span>
<span>function _privateMethod () {
</span> <span>const self = $(this);
</span> <span>const _internalElement = $('.internal-element');
</span> <span>let $data = element.data('foo');
</span> <span>//... more logic.
</span><span>}
</span>
<span>// This is much easier and faster to understand.
</span><span>const $element = $('.element');
</span>
<span>function _privateMethod () {
</span> <span>const $this = $(this);
</span> <span>const $internalElement = $('.internal-element');
</span> <span>let elementData = $element.data('foo');
</span> <span>//... more logic.
</span><span>}
</span>Alors que les étapes précédentes étaient plus cosmétiques et principalement pour aider à numériser le code plus rapidement, nous introduisons ici et assurons les meilleures pratiques courantes ainsi que la qualité du code. Eslint, Jslint et Jshint sont les liners JavaScript les plus populaires de nos jours. Personnellement, je travaillais beaucoup avec Jshint, mais Eslint a commencé à devenir mon préféré, principalement en raison de ses règles personnalisées et de sa prise en charge ES2015.
Lorsque vous commencez à libellir, si beaucoup d'erreurs apparaissent, réparez-les! Ne continuez avec rien d'autre avant que votre linter ne soit heureux!
La mise à jour des dépendances doit être effectuée attentivement. Il est facile d'introduire plus d'erreurs lorsque vous ne faites pas attention aux modifications que vos dépendances ont apportées. Certains projets peuvent fonctionner avec des versions fixes (par exemple V1.12.5), tandis que d'autres utilisent des versions génériques (par exemple v1.12.x). Si vous avez besoin d'une mise à jour rapide, un numéro de version est construit comme suit: major.minor.patch. Si vous n'êtes pas familier avec le fonctionnement du versioning sémantique, je recommande de lire cet article de Tim Oxley.
Il n'y a pas de règle générale pour mettre à jour les dépendances. Chaque projet est différent et doit être géré en tant que tel. La mise à jour du numéro de correctif de vos dépendances ne devrait pas être un problème du tout, et la mineure est généralement très bien également. Ce n'est que lorsque vous baissez le nombre majeur de vos dépendances, vous devriez rechercher ce qui a exactement changé. Peut-être que l'API a entièrement changé et que vous devez réécrire de grandes parties de votre application. Si cela ne vaut pas l'effort, j'éviterais de mettre à jour vers la prochaine version principale.
Si votre projet utilise le NPM en tant que gestionnaire de dépendance (et il n'y a pas de concurrents), vous pouvez vérifier les dépendances obsolètes avec la commande NPM pratique de votre CLI. Permettez-moi de l'illustrer avec un exemple de l'un de mes projets intitulé FronterBook, où je met à jour toutes les dépendances:
Comme vous pouvez le voir, j'ai ici beaucoup de mises à jour majeures. Je ne les mettrais pas à jour tous en même temps, mais un à la fois. Certes, cela prendra beaucoup de temps, mais c'est le seul moyen de s'assurer que rien ne se casse (si le projet n'a pas de tests).
Le message principal que je veux que vous preniez avec vous est que le nettoyage ne signifie pas nécessairement la suppression et la réécriture de grandes sections de code. Bien sûr, c'est parfois la seule solution, mais ce ne devrait pas être votre première et une seule étape. JavaScript peut être un langage étrange, donc donner des conseils génériques n'est généralement pas possible. Vous devez toujours évaluer votre situation spécifique et comprendre une solution de travail.
Avoir des tests unitaires garantit que vous comprenez comment le code est destiné à fonctionner et que vous ne rompez rien accidentellement. Les tests unitaires JavaScript valent ses propres articles, donc je ne pourrai pas aller dans les détails ici. Les cadres largement utilisés sont le karma, le jasmin, le moka ou l'AVA. Si vous souhaitez également tester votre interface utilisateur, Nightwatch.js et Dalekjs sont recommandés des outils d'automatisation du navigateur.
La différence entre les tests unitaires et l'automatisation du navigateur est que l'ancien teste votre code JavaScript lui-même. Il garantit que tous vos modules et votre logique générale fonctionnent comme prévu. L'automatisation du navigateur, en revanche, teste la surface - l'interface utilisateur - de votre projet, en s'assurant que les éléments sont au bon endroit et au travail comme prévu.
Prenez soin des tests unitaires avant de commencer à refactoriser autre chose. La stabilité de votre projet s'améliorera et vous n'avez même pas pensé à l'évolutivité! Un excellent effet secondaire n'est pas inquiet tout le temps que vous avez peut-être cassé quelque chose et que vous n'avez pas remarqué.
Rebecca Murphey comme écrit un excellent article sur la rédaction de tests unitaires pour JavaScript existant.
L'architecture JavaScript est un autre sujet énorme. Le refactorisation et le nettoyage de l'architecture se résument à la quantité d'expérience que vous avez avec cela. Nous avons beaucoup de modèles de conception différents dans le développement de logiciels, mais tous ne sont pas un bon ajustement en ce qui concerne l'évolutivité. Malheureusement, je ne pourrai pas couvrir tous les cas de cet article, mais je peux au moins vous donner quelques conseils généraux.
Tout d'abord, vous devez déterminer quels modèles de conception sont déjà utilisés dans votre projet. Lisez le modèle et assurez-vous qu'il est cohérent. L'une des clés de l'évolutivité est de s'en tenir au motif et de ne pas mélanger les méthodologies. Bien sûr, vous pouvez avoir des modèles de conception différents à différentes fins dans votre projet (par exemple, en utilisant le modèle Singleton pour les structures de données ou les fonctions d'assistance courtes et le modèle d'observateur pour vos modules) mais ne devrait jamais écrire un module avec un modèle et l'autre un avec un modèle différent.
S'il n'y a pas vraiment d'architecture dans votre projet (peut-être que tout est juste dans une énorme app.js), il est temps de changer cela. Ne faites pas tout en même temps, mais pièce par morceau. Encore une fois, il n'y a pas de moyen générique de faire des choses et chaque configuration de projet est différente. Les structures de dossiers varient entre les projets, selon la taille et la complexité. Habituellement - à un niveau très basique - la structure est divisée en bibliothèques tierces, modules, données et point d'entrée (par exemple index.js, main.js) où tous vos modules et logique sont initialisés.
Cela m'amène à la modularisation.
La modularisation n'est de loin pas la réponse à la grande question d'évolutivité JavaScript. Il ajoute une autre couche d'API que les développeurs doivent se familiariser. Cela peut valoir la peine cependant. Le principe est de diviser toutes vos fonctionnalités dans de minuscules modules. Ce faisant, il est plus facile de résoudre des problèmes dans votre code et de travailler en équipe sur la même base de code. Chaque module doit avoir exactement un seul but et une tâche à faire. Un module ne connaît pas la logique extérieure de votre application et peut être réutilisée dans différents endroits et situations.
Comment divisez-vous une grande fonctionnalité avec beaucoup de logique étroitement connectée? Faisons-le ensemble.
<span>// While this is valid JavaScript, the block can't
</span><span>// be properly folded due to its mixed indentation.
</span> <span>function foo (data) {
</span> <span>let property = String(data);
</span>
<span>if (property === 'bar') {
</span> property <span>= doSomething(property);
</span> <span>}
</span> <span>//... more logic.
</span> <span>}
</span>
<span>// Correct indentation makes the code block foldable,
</span><span>// enabling a better experience and clean codebase.
</span><span>function foo (data) {
</span> <span>let property = String(data);
</span>
<span>if (property === 'bar') {
</span> property <span>= doSomething(property);
</span> <span>}
</span> <span>//... more logic.
</span><span>}
</span>Ce n'est pas très modulaire. Tout est étroitement connecté et dépend des autres pièces. Imaginez cela avec des fonctions plus grandes et plus complexes et vous devrez déboguer cela parce que quelque chose se casse. Peut-être que l'API ne répond pas, quelque chose a changé à l'intérieur du JSON ou autre chose. Un cauchemar, n'est-ce pas?
séparons les différentes responsabilités:
<span>// Inconsistent naming makes it harder
</span><span>// to scan and understand the code. It can also
</span><span>// lead to false expectations.
</span><span>const $element = $('.element');
</span>
<span>function _privateMethod () {
</span> <span>const self = $(this);
</span> <span>const _internalElement = $('.internal-element');
</span> <span>let $data = element.data('foo');
</span> <span>//... more logic.
</span><span>}
</span>
<span>// This is much easier and faster to understand.
</span><span>const $element = $('.element');
</span>
<span>function _privateMethod () {
</span> <span>const $this = $(this);
</span> <span>const $internalElement = $('.internal-element');
</span> <span>let elementData = $element.data('foo');
</span> <span>//... more logic.
</span><span>}
</span>Très bien, nous avons maintenant trois nouveaux modules. Voyons l'appel de récupération refactorisé.
<span>// This example uses the Fetch API to request an API. Let's assume
</span><span>// that it returns a JSON file with some basic content. We then create a
</span><span>// new element, count all characters from some fictional content
</span><span>// and insert it somewhere in your UI.
</span><span>fetch('https://api.somewebsite.io/post/61454e0126ebb8a2e85d', { method: 'GET' })
</span> <span>.then(response => {
</span> <span>if (response.status === 200) {
</span> <span>return response.json();
</span> <span>}
</span> <span>})
</span> <span>.then(json => {
</span> <span>if (json) {
</span> <span>Object.keys(json).forEach(key => {
</span> <span>const item = json[key];
</span> <span>const count = item.content.trim().replace(<span>/<span>\s+</span>/gi</span>, '').length;
</span> <span>const el = <span>`
</span></span><span><span> <div token interpolation"><span>${item.className}</span>">
</span></span><span><span> <p>Total characters: <span>${count}</span></p>
</span></span><span><span> </div>
</span></span><span><span> `</span>;
</span> <span>const wrapper = document.querySelector('.info-element');
</span>
wrapper<span>.innerHTML = el;
</span> <span>});
</span> <span>}
</span> <span>})
</span> <span>.catch(error => console.error(error));
</span>Nous pourrions également prendre la logique de l'intérieur des méthodes .Then () et le séparer, mais je pense que j'ai démontré ce que signifie la modularisation.
Comme je l'ai déjà mentionné, la transformation de votre base de code dans de minuscules modules ajoute une autre couche d'API. Si vous ne voulez pas cela, mais que vous souhaitez garder plus facilement les développeurs à travailler avec votre code, il est absolument bien de garder les fonctions plus grandes. Vous pouvez toujours décomposer votre code en portions plus simples et vous concentrer davantage sur le code testable.
La documentation est un sujet fortement discuté. Une partie de la communauté de programmation préconise de tout documenter, tandis qu'un autre groupe pense que le code d'auto-documentation est la voie à suivre. Comme pour la plupart des choses dans la vie, je pense qu'un bon équilibre entre les deux rend le code lisible et évolutif. Utilisez JSDOC pour votre documentation.
JSDOC est un générateur de documentation API pour JavaScript. Il est généralement disponible en tant que plugin pour tous les éditeurs et IDE bien connus. Passons un exemple par un exemple:
<span>// While this is valid JavaScript, the block can't
</span><span>// be properly folded due to its mixed indentation.
</span> <span>function foo (data) {
</span> <span>let property = String(data);
</span>
<span>if (property === 'bar') {
</span> property <span>= doSomething(property);
</span> <span>}
</span> <span>//... more logic.
</span> <span>}
</span>
<span>// Correct indentation makes the code block foldable,
</span><span>// enabling a better experience and clean codebase.
</span><span>function foo (data) {
</span> <span>let property = String(data);
</span>
<span>if (property === 'bar') {
</span> property <span>= doSomething(property);
</span> <span>}
</span> <span>//... more logic.
</span><span>}
</span>Cette fonction prend deux paramètres et itère sur un objet, qui renvoie ensuite un tableau. Ce n'est peut-être pas une méthode trop compliquée, mais pour quelqu'un qui n'a pas écrit le code, cela pourrait prendre un certain temps pour comprendre ce qui se passe. De plus, il n'est pas évident ce que fait la méthode. Commençons à documenter:
<span>// Inconsistent naming makes it harder
</span><span>// to scan and understand the code. It can also
</span><span>// lead to false expectations.
</span><span>const $element = $('.element');
</span>
<span>function _privateMethod () {
</span> <span>const self = $(this);
</span> <span>const _internalElement = $('.internal-element');
</span> <span>let $data = element.data('foo');
</span> <span>//... more logic.
</span><span>}
</span>
<span>// This is much easier and faster to understand.
</span><span>const $element = $('.element');
</span>
<span>function _privateMethod () {
</span> <span>const $this = $(this);
</span> <span>const $internalElement = $('.internal-element');
</span> <span>let elementData = $element.data('foo');
</span> <span>//... more logic.
</span><span>}
</span>Je n'ai pas touché une grande partie du code lui-même. Juste en renommant la fonction et en ajoutant un bloc de commentaires court mais détaillé, nous avons amélioré la lisibilité.
Le refactorisation est une énorme mission en soi. Pour pouvoir toujours recommencer vos modifications (au cas où vous cassez quelque chose et que vous ne remarquez que plus tard), je vous recommande de commettre chaque mise à jour que vous faites. Réécrire une méthode? Git Commit (ou SVN Commit, si vous travaillez avec SVN). Renommé un espace de noms, un dossier ou quelques images? git commit. Vous avez l'idée. Il peut être fastidieux pour certaines personnes, mais cela vous aide vraiment à nettoyer correctement et à vous organiser.
Créez une nouvelle branche pour tout l'effort de refactorisation. Ne travaillez jamais sur Master! Vous devrez peut-être effectuer des modifications rapides ou télécharger des corrections de bogues dans l'environnement de production et vous ne voulez pas déployer votre code (peut-être non testé) jusqu'à ce qu'il soit testé et terminé. Il est donc conseillé de toujours travailler sur une branche différente.
Dans le cas où vous auriez besoin d'une courte mise à jour comment tout cela fonctionne, il y a un guide intéressant de GitHub sur leur flux de travail de contrôle de version.
Outre toutes les étapes techniques requises pour un nettoyage, il y a une étape importante que je voyais rarement mentionné n'importe où: ne pas être en colère contre le développeur précédent. Bien sûr, cela ne s'applique pas à tout le monde, mais je sais que certaines personnes en font l'expérience. Il m'a fallu des années pour vraiment comprendre cela et en surmonter. J'avais l'habitude de devenir assez en colère contre le code des développeurs précédents, leurs solutions et pourquoi tout était un tel gâchis.
En fin de compte, toute cette négativité ne m'a jamais amené nulle part. Cela ne fait qu'à refactoriser plus que nécessaire, perdre votre temps et peut-être briser les choses. Cela vous rend de plus en plus ennuyé. Vous pourriez passer des heures supplémentaires et personne ne vous remerciera jamais d'avoir réécrit un module déjà fonctionnel. Cela n'en vaut pas la peine. Faites ce qui est nécessaire, analysez la situation. Vous pouvez toujours refacter de minuscules bits chaque fois que vous retournez à un module.
Il y a toujours des raisons pour lesquelles le code est écrit tel qu'il est. Peut-être que le développeur précédent n'avait tout simplement pas eu assez de temps pour le faire correctement, ne savait pas mieux, ou autre chose. Nous avons tous été là.
passons à nouveau toutes les étapes, pour créer une liste de contrôle pour votre prochain projet.
J'espère vraiment que cet article vous a aidé. Faites-moi savoir si vous avez du mal avec l'une des étapes, ou peut-être d'avoir de bons conseils que je n'ai pas mentionnés!
Le code spaghetti est un terme utilisé pour décrire un Web de code complexe et emmêlé qui est difficile à lire, à comprendre et à maintenir. Il résulte souvent de mauvaises pratiques de programmation, telles que le manque de planification, le non-respect des normes de codage ou ne pas utiliser de principes de programmation orientés objet. Ce type de code peut entraîner de nombreux problèmes, y compris des bogues difficiles à retrouver, des difficultés à ajouter de nouvelles fonctionnalités et une augmentation du temps et du coût de la maintenance. Par conséquent, il est crucial d'éviter d'écrire du code de spaghetti et de vous efforcer de nettoyer le code propre et maintenable.
Écriture du code JavaScript maintenable implique plusieurs meilleures pratiques. Tout d'abord, planifiez toujours votre code avant de commencer à écrire. Cela comprend la compréhension du problème que vous essayez de résoudre et de concevoir une solution. Deuxièmement, suivez les normes et conventions de codage. Cela rend votre code plus facile à lire et à comprendre. Troisièmement, utilisez des principes de programmation orientés objet. Cela aide à organiser votre code et le rend plus réutilisable. Enfin, documentez toujours votre code. Cela comprend la rédaction de commentaires pour expliquer ce que fait votre code et pourquoi vous avez pris certaines décisions.
Quelques pièges courants à éviter lors de l'écriture de code javascript Inclure n'utiliser pas le mode strict, ne pas déclarer correctement les variables, utiliser l'opérateur '==' au lieu de '===', et ne pas gérer correctement les erreurs. Éviter ces pièges peut vous aider à rédiger un code plus propre et plus maintenable.
Refactoring Code Spaghetti dans le code maintenable implique plusieurs étapes. Tout d'abord, vous devez comprendre le code existant. Cela peut impliquer de lire le code et de documenter ce que fait chaque partie. Deuxièmement, identifiez les zones du code qui peuvent être améliorées. Il peut s'agir de sections de code répétées et complexes de logique conditionnelle ou de code difficile à comprendre. Troisièmement, apportez les modifications nécessaires au code. Cela pourrait impliquer de décomposer des fonctions complexes en plus petites et plus gérables, de supprimer du code en double ou de réécrire des sections de code pour les rendre plus faciles à comprendre. Enfin, testez vos modifications pour vous assurer que la fonctionnalité du code reste la même.
Il existe plusieurs outils disponibles qui peuvent vous aider à écrire du code JavaScript maintenable. Il s'agit notamment de liners comme Eslint, qui peuvent appliquer les normes de codage et mettre en évidence les problèmes potentiels de votre code. Les éditeurs de code comme Visual Studio Code peuvent également aider en fournissant des fonctionnalités telles que la mise en évidence de la syntaxe et la complétion automatique. De plus, les systèmes de contrôle des versions comme GIT peuvent vous aider à suivre les modifications de votre code et à faciliter la collaboration avec les autres.
La programmation orientée objet (POO) est un paradigme de programmation qui aide à écrire du code maintenable. Il vous permet d'organiser votre code en objets, qui peuvent contenir à la fois des données et des fonctions. Cela rend votre code plus modulaire et réutilisable, car vous pouvez créer des objets qui effectuent des tâches spécifiques, puis les utilisent tout au long de votre code. La POO rend également votre code plus facile à comprendre, car il vous permet de modéliser les concepts du monde réel dans votre code.
Les commentaires sont cruciaux pour maintenir JavaScript JavaScript? code. Il aide les autres développeurs (et votre futur) à comprendre ce que fait le code et pourquoi certaines décisions ont été prises. Cela est particulièrement important dans les bases de code complexes, où la compréhension des fonctionnalités du code peut être difficile. Cependant, les commentaires doivent être utilisés judicieusement. La surexploitation peut rendre le code encombré et plus difficile à lire. Idéalement, votre code devrait être explicite, avec des commentaires réservés pour expliquer pourquoi certaines décisions ont été prises ou clarifier les sections complexes de code.
Assurer Votre code JavaScript est évolutif implique la conception de votre code d'une manière qui lui permet de gérer efficacement les charges accrues. Cela peut être réalisé en suivant de bonnes pratiques de programmation telles que l'utilisation d'algorithmes et de structures de données efficaces, d'éviter les variables globales et de minimiser la manipulation DOM. De plus, en utilisant une approche modulaire du codage, où votre code est décomposé en pièces plus petites et réutilisables, peut également améliorer l'évolutivité.
Les tests jouent un rôle crucial dans la rédaction du code JavaScript maintenable. Il permet de garantir que votre code fonctionne comme prévu et peut aider à attraper les bogues au début du processus de développement. Il existe plusieurs types de tests que vous pouvez utiliser, notamment des tests unitaires, des tests d'intégration et des tests de bout en bout. L'utilisation d'une combinaison de ces méthodes de test peut aider à garantir que votre code est robuste et fiable.
Suivre les dernières pratiques pour rédaction du code JavaScript maintenable peut être réalisé en lisant régulièrement des blogs de l'industrie, en assistant des webinaires et des conférences et participer aux communautés en ligne. De plus, pratiquer l'apprentissage continu et réviser et refactoriser régulièrement votre code peuvent également vous aider à rester à jour avec les dernières meilleures pratiques.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Comment utiliser l'expression de point d'interrogation en langage C
Historique des opérations de la table de vue Oracle
Quel logiciel est Twitter ?
Comment créer une page Web réactive
Méthode d'implémentation de la fonction js barrage
Quelles informations privées les amis proches de Douyin verront-ils ?
Qu'est-ce qu'ECharts
Comment trader sur Binance
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
