location.assign('http://www.bing.com');S'il s'agit d'un code de saut de page qui doit être exécuté après la connexion ou si une certaine logique réussit, doit-il être encapsulé dans une méthode globale ? Une seule phrase est-elle vraiment nécessaire ?
En d'autres termes, utiliser pleinement le remplacement global de l'éditeur et d'autres fonctions peut également améliorer les performances, même si cela est minime~
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
S'il n'y a pas de jugement logique, mettez simplement une adresse de saut dans une constante. S'il existe un jugement logique métier, encapsulez-le.
S'il s'agit d'une pure logique de saut, il n'est pas nécessaire de l'encapsuler dans une méthode distincte. Vous pouvez mettre la connexion dans un fichier constant. Parce que ce que vous avez dit ici n'est qu'une phrase logique, il n'y aura aucun changement logique ici, mais ce qui peut changer, c'est l'adresse de connexion. Pour une gestion unifiée, placez-la dans un fichier constant séparé.
Si ce processus de saut de liens a son propre jugement logique, comme par exemple quelles conditions accéder à quelle adresse. Ensuite, il peut être encapsulé dans une méthode pour appeler ailleurs. De cette façon, un seul endroit doit être modifié lorsque cet élément de logique change.
Donc, l'opportunité d'encapsuler et ce qu'il faut encapsuler dépend de l'évolution des besoins
J'ai tout écrit directement dans le dernier projet et j'ai senti qu'il n'était pas nécessaire de l'encapsuler. Et je ne suis pas sûr que cela puisse améliorer les performances, je ne l'ai pas comparé moi-même.
Encapsuler du code consiste à réduire la duplication de code. Pour une ligne de code, c'est presque la même chose qu'elle soit encapsulée ou non Car si vous l'encapsulez, vous devez écrire un autre morceau de code pour le référencer, et la quantité de code. le code ne change pas grand chose.
Prémisse : il existe un tel morceau de code qui est utilisé dans de nombreux endroits, et il n'y a pas beaucoup de changements personnalisés à chaque endroit
Si c'était moi, je le mettrais au même endroit, puis je l'appellerais uniformément à partir d'un seul endroit (il peut être global, ou il peut être util, etc.) dans le but de :
Réduisez la difficulté des extensions possibles dans le futur. Si vous constatez que vous devez ajouter d'autres éléments plus tard, il sera facile d'apporter des modifications
Réduisez la charge de travail lors de la modification. Si vous souhaitez modifier le href, vous n'avez pas besoin de les rechercher et de les remplacer un par un, ce qui réduit le risque d'erreurs
Facile pour le débogage. Vous pouvez savoir exactement d'où sauter, au lieu de sauter vers de nombreux endroits. S'il saute inexplicablement, le point d'interruption est directement atteint à cet endroit, et vous pouvez alors trouver le problème en levant les yeux. Au lieu de devoir atteindre de nombreux points d’arrêt à différents endroits.
Avec cette logique simple, il est évident que la commodité et la simplicité du code sont bien supérieures aux performances du code, je ne considérerai donc pas les problèmes de performances