Préface
Avez-vous déjà senti qu'il y avait des fantômes dans le monde lorsque vous réglez un certain morceau de code?
Avez-vous déjà eu un problème dans la régulation de l'API, vous pensez toujours que c'est un problème pour appeler des interfaces tierces ou que la documentation est incorrecte?
Avez-vous déjà senti que la source du problème était la mauvaise façon de l'utiliser?
Avez-vous toujours pensé que la documentation ou l'environnement ne correspond pas lors de l'installation d'un service?
Croyez au processus et à la méthode et ne jamais être induit en erreur par les résultats .........
Aperçu
Le code modulaire est souvent similaire à l'étude d'un cas, mais l'importance du résultat est différente. La police enquête sur l'affaire pour que les gens soient en sécurité, tandis que notre code modulaire est pour la stabilité du système. De cette façon, nous ne devons accuser à tort aucun morceau de code et de programme, afin de ne pas être puni de façon déraisonnable.
Les méthodes de processus suivantes proviennent d'un résumé personnel. D'un point de vue personnel, certaines des méthodes des générations précédentes ont été accumulées par une expérience à long terme, et bien sûr, elles sont très référencées et théoriques. En tant que méthodes personnelles, elles peuvent être plus adaptées à DS comme nous.
Méthode d'essai
Mode procédural de code
La première chose à laquelle faire attention lorsque le mode de codage est le processus. Vous devez clarifier l'idée du résultat final, c'est-à-dire le processus de commettre le crime et un suivi étape par étape du processus de criminalité pour obtenir le résultat du crime. Au cours de l'analyse du processus de criminalité, chaque doute doit être marqué (c'est-à-dire les informations du journal mentionnées dans le code). Après un tel processus d'analyse, un test de boîte noire est effectué, une entrée est ajoutée et les résultats sont vérifiés. Enfin, vérifiez votre jugement en fonction des marques de chaque étape pour trouver la raison.
La solution ci-dessus est un mode procédural. Les avantages de cette méthode sont évidents. Vous pouvez analyser directement l'ensemble du processus grâce à un test, mais cette méthode prend du temps et il est normal de clarifier votre propre logique de code, mais il est difficile de comprendre le code logique des autres.
Mode de test unitaire
Le but de base des tests unitaires est d'assurer le fonctionnement normal d'une fonction, d'une classe ou d'un module fonctionnel, y compris les tests et la vérification de ses situations anormales. En tant que programmeurs, la méthode de vérification la plus préférée est "l'empilement" (la signification de la conduite de la pile est de fournir de fausses données par défaut). Cette méthode est très pratique à ajuster, mais un inconvénient est qu'il ne peut plus être utilisé, car une fois notre vérification normale, de nombreux développeurs le commenteront ou le supprimeront. Par conséquent, si nous terminons le développement dans l'environnement de développement, mais nous espérons que lors du test de la vérification de l'environnement, nous devons réécrire une autre logique de conduite de pile. Ensuite, de cette façon, ce sera encore plus gênant lorsque nous serons sur Internet. Puisqu'il y a tellement de inconvénients, vous pouvez essayer les méthodes suivantes.
Ajoutez une classe de test unitaire. Cette classe doit contrôler ses autorisations et ne peut être exécutée que via la connexion d'arrière-plan ou la ligne de commande. La fonction de cette classe est de détecter la logique clé du système et de faire des résultats de sortie de test correspondants. Vous devez croire que toutes les classes d'interface peuvent être testées via des classes de test unitaires. Plusieurs fois, les programmeurs se demandent si nous devrions faire cela? En fait, nous devons vraiment le faire. Après tout, de nombreux tests sont maintenant effectués dans les tests de boîte noire.
Cette méthode modulaire convient au cours du processus de développement et peut garantir que notre code réseau actuel s'exécute normalement après sa sortie. J'espère que tout le monde transférera également ce processus au stade de développement lors de la planification de l'heure de développement.
Méthode de positionnement rapide
Les deux premiers processus si compliqués sont-ils trop idéaux? Mon code n'est que de 100 lignes et le système n'est pas compliqué. Si tel est le cas, effectuez une analyse de positionnement rapidement. Plusieurs fois je le rencontre
1. L'entrée est normale, la sortie est anormale;
2. L'entrée est normale, la logique est anormale et la sortie est anormale;
3. L'entrée est anormale, la logique est normale et la sortie est normale;
4. Exception d'entrée, exception logique, sortie Aucune.
Au cours de mon processus de développement personnel, je rencontre souvent un certain type de problèmes ci-dessus. Par exemple, pendant le processus de développement de Node.js, j'ai rencontré String.Length et j'ai dit qu'il n'y a pas de méthode de longueur pour la chaîne. À ce moment-là, j'ai été perplexe et m'a demandé pourquoi les autres chaînes ont des méthodes de longueur et pourquoi il n'y a pas de méthode de ce type? De nombreux étudiants savent probablement que le problème est que cette chaîne n'est pas du tout une chaîne, mais juste que vous l'avez idéalisée comme une chaîne vous-même, ce qui signifie qu'il y a un problème avec ce que vous saisissez. Ensuite, la meilleure façon de localiser ce problème est d'imprimer l'entrée et d'imprimer la sortie.
Peut-être que d'autres programmes ne sont pas si simples, mais la chose la plus élémentaire est de faire des jugements d'entrée et de sortie sur les fonctions qui rencontrent des exceptions dans la fonction principale, afin qu'ils puissent rapidement localiser.
N'oubliez pas: ne le sortez pas de son contexte et soyez autonome.
Les méthodes et procédures ci-dessus ne sont résumées que sur la base de PHP ou Node.js. Il peut y avoir des similitudes ou des différences en C&C ++. Si vous ne l'aimez pas, veuillez le chérir.