Développement back-end : comment écrire des interfaces fiables

Cela fait près d'un an que j'ai obtenu mon diplôme et rejoint mon entreprise actuelle, et j'ai pleinement participé au développement et au lancement de deux phases des nouveaux projets du département. développeur final, la chose la plus pénible est avant et après le lancement. Dans la phase de correction des bugs après la mise en ligne, face à toutes sortes de bugs soudains et inexplicables, je me sens souvent étourdi, confus et de plus en plus confus à mesure que j'apporte des modifications. conduit à des tragédies telles que la correction expérimentale de bugs, et deux bugs apparaissent après la correction d'un bug. Je ne peux m'empêcher de me demander pourquoi y a-t-il autant de bugs avant chaque lancement ?

J'ai lu un article de Douban il y a quelques jours. Ce qui n'est pas résumé, ce n'est pas l'expérience, juste l'expérience. Les programmeurs ne peuvent pas simplement écrire du code lorsque les affaires arrivent et corriger les bugs lorsqu'il y en a. Cela rend difficile l'amélioration de la technologie, il n'est donc pas étonnant qu'il y ait autant de bugs à chaque fois. Certains développeurs travaillent depuis de nombreuses années, mais le nombre d'interfaces est encore de temps en temps de 500. Ils sont occupés à écrire du code au début et à corriger les bugs à un stade ultérieur, ce qui les fatigue.

Dès la première phase, je me suis familiarisé avec le métier et le framework et j'ai écrit des interfaces Edge. Dans la deuxième phase, j'étais responsable d'un petit module et j'ai essayé de concevoir des bases de données et des programmes. Hier, je me suis connecté en douceur. Je le ressens aussi vaguement. J'ai donc essayé de résumer certaines expériences. Même si c'est simple, cela peut m'inspirer, ainsi qu'aux lecteurs. (Cet article se concentre uniquement sur le niveau de base, les bugs simples et n'implique pas de problèmes complexes tels qu'une concurrence élevée et des données massives)

1. Pourquoi les interfaces sont-elles boguées ?

L'interface pour laquelle j'ai travaillé si dur a bien fonctionné lorsque je l'ai testée moi-même, mais pourquoi s'est-elle mal passée dès que quelqu'un d'autre l'a ajustée ? ? (Il devrait y avoir des émoticônes ici, veuillez vous faire votre propre opinion.) Bien sûr, cela peut être un problème avec l'environnement d'exploitation, mais le programme est déployé uniformément sur le serveur. Cela relève généralement de la responsabilité de l'architecte ou de l'exploitation et de la maintenance. Quant au problème du langage de programmation ou du système d'exploitation, ils sont tous hors du champ de réflexion aujourd'hui, nous ne considérons que les bugs écrits par nous-mêmes.

En fait, un programme en cours d'exécution n'implique rien de plus que trois choses : ressources (processeur, mémoire, etc.) + algorithme (processus en cours d'exécution du programme) + données (entrée utilisateur, base de données, interface tierce, etc. ). Habituellement, nous pensons que les ressources sont fiables et que les bugs surviennent principalement en raison d'algorithmes peu fiables ou d'anomalies de données.

De plus, la machine exécute les instructions strictement selon 0/1. L'algorithme s'est exécuté normalement la dernière fois. Pourquoi a-t-il échoué cette fois-ci ? Essentiellement, c'est parce que les données ont changé et que l'algorithme n'a pas réussi à couvrir cette situation. Par conséquent, afin d'assurer la stabilité de l'interface, nous considérons principalement deux aspects : garantir la fiabilité des données et la robustesse de l'algorithme, et. la robustesse de l'algorithme est à considérer. Dans toutes les situations de données, les deux sont indissociables.

2. Comment écrire une interface avec moins de bugs

Comme analysé précédemment, les modifications de données sont la cause la plus courante et la plus essentielle des bugs d'interface. Parmi eux, la saisie des utilisateurs est la principale raison des modifications des données. Le programme doit avoir une entrée utilisateur, sinon cela n'a aucun sens.

Il existe un dicton célèbre dans le monde de la programmation : ne faites jamais confiance aux entrées de l'utilisateur. Vous ne savez jamais ce que l'utilisateur va taper dans une zone de saisie qui attend un nom. Ne vous inquiétez pas simplement parce que le front-end l'a filtré. D'une part, les utilisateurs peuvent utiliser des robots d'exploration et d'autres moyens pour accéder directement à votre interface. D'autre part, le front-end est également votre utilisateur, et il y en a. également des erreurs de communication. Le front-end peut vous appeler dans le mauvais sens, et cette erreur peut être plus subtile.

La première suggestion : vérifiez strictement les entrées de l'utilisateur, y compris le format et le contenu.

Je sais que beaucoup de gens sont trop paresseux pour vérifier les entrées des utilisateurs une par une, pensant que tant que la fonction est normale, tout ira bien. Cependant, cela conduit souvent à plus d'expérience dans la correction. bugs plus tard. Fréquemment, des bugs sont signalés lors des tests, et vous vérifiez encore et encore et constatez que le front-end a transmis les mauvais paramètres, ou n'a pas raisonnablement restreint la saisie de l'utilisateur. Bien sûr, vous pouvez être très rigide et laisser le front-end apporter des modifications. , mais ce processus vous a déjà fait perdre beaucoup de temps et d'énergie. Il est préférable de le vérifier vous-même au début et de renvoyer les messages d'erreur appropriés, ce qui vous fera économiser beaucoup d'énergie plus tard.

Cela est particulièrement vrai pour les langages dynamiques tels que PHP Par exemple, si nous utilisons le framework Laravel, j'utiliserai d'abord $request->validate() à toutes les entrées de l'interface pour vérifier le format de. toutes les données d'entrée. Si nécessaire, le code sera également écrit pour vérifier davantage le contenu d'entrée, tel que la plage horaire, si les données demandées sont valides, etc.

La deuxième suggestion : considérez les opérations gênantes de l'utilisateur, les soumissions répétées, les soumissions retardées

Les soumissions répétées devraient être une situation à laquelle la plupart des backends peuvent penser, et c'est la idempotence de l'interface. Certaines ressources ne peuvent être exploitées qu'une seule fois et doivent être vérifiées. En fait, il ne s'agit pas seulement de soumissions répétées, mais aussi de la situation où le même événement est traité de manière répétée par deux personnes.

En ce qui concerne la soumission retardée, il s'agissait en fait d'un problème dont je ne me suis rendu compte qu'après que le testeur m'a signalé un bug. Par exemple, si nous renvoyons une certaine ressource à l'utilisateur via l'interface get, l'utilisateur peut renvoyer l'ID de ressource via l'interface de publication et soumettre des modifications. Puisqu'il est renvoyé par sa propre interface get, nous souhaiterons peut-être uniquement vérifier que la ressource est renvoyée. L'ID est légal, ce qui semble former une boucle fermée stricte, mais si l'utilisateur reste sur cette page et retarde la soumission, la ressource peut avoir expiré pendant cette période, ou la ressource a été modifiée par d'autres, et l'utilisateur a réussi la modification. le bug. En fait, si vous y réfléchissez davantage, vous constaterez que cela ressemble à une défaillance de ressources dans des scénarios à forte concurrence.

La troisième suggestion : Vérifiez les données de retour de la base de données et de l'interface tierce

En plus des entrées des utilisateurs, les sources de données courantes incluent les bases de données et les interfaces tierces. Relativement parlant, ces interfaces de données seront beaucoup plus fiables et le format du contenu sera plus standardisé. Cependant, pour la stabilité de l’interface, il est préférable de faire quelques tests. Par exemple, si les données sont souvent vides, l'exécution du programme doit être interrompue rapidement et les informations appropriées doivent être supprimées.

D'ailleurs, pour la base de données, j'ai également rencontré des bugs, qui sont des problèmes de mise à jour des données causés par un retard maître-esclave. En raison de mon manque d'expérience, je ne suis pas très doué pour ce type de problèmes, donc je n'écrirai plus là-dessus.

La quatrième suggestion : l'algorithme du programme couvre autant que possible les situations anormales.

Il s'agit en fait d'un complément aux trois premières. Pour certaines entrées utilisateur illégales, vous pouvez. Abandonnez directement le programme et renvoyez un message d'erreur, mais certaines situations peuvent nécessiter que le programme continue de s'exécuter et effectue un traitement spécial. Dans ces situations, vous devriez essayer de les examiner attentivement au début de la conception du programme. moins de bugs et il sera plus facile à maintenir.

3. Comment écrire une interface plus efficace

Enfin, écrivons un peu plus de réflexions sur l'efficacité de l'interface et la qualité du code.

1. Le principal facteur qui affecte l'efficacité de l'interface est les opérations de base de données.
D'après mon expérience limitée, le long temps d'interface est essentiellement dû aux opérations de base de données déraisonnables de la plupart de nos activités. n'a pas de problèmes de performances. J'ai vu beaucoup de code qui interroge la base de données dans une boucle for. Cela doit être évité. Nous pouvons d'abord supprimer toutes les données en même temps, puis les traiter une par une. Par exemple, nous enregistrerons toutes les opérations de base de données au niveau de la couche framework. Lors du débogage de l'interface, nous pouvons voir toutes les opérations de base de données et la consommation de temps correspondante. Les requêtes fusionnées doivent être fusionnées et les requêtes chronophages optimisées doivent être optimisées en conséquence. .

2. Utilisation raisonnable de l'exception, journal

Cet article concerne principalement le langage PHP Pour des raisons historiques, j'ai vu de nombreux codes qui reposent sur le retour pour abandonner. le programme et transmet les informations d'erreur, ce qui rend la maintenance extrêmement difficile lorsque le code est complexe et le niveau d'appel profond, et c'est beaucoup moins intuitif et pratique que le mécanisme d'exception. En outre, les informations importantes doivent être écrites dans un journal pour faciliter la découverte des problèmes et le débogage ultérieur, et elles peuvent également être utilisées pour prouver l'innocence.

3. Le code doit être raisonnablement divisé et abstrait

Ne copiez pas et ne collez pas le code, les fonctions répétées doivent être séparées lors de la conception, une considération raisonnable doit être accordée ; pour exiger des changements et des extensions ; écrire petit Quant aux fonctions ciblées, n'implémentez pas de fonctions complexes en une seule fois ; le code écrit de cette manière est facile à modifier, tester et développer. Je ne suis pas doué pour ça non plus. Après être allé en ligne, mon code est compliqué et difficile à maintenir. Ensuite, je dois réfléchir davantage et m'entraîner davantage.