J'ai l'impression que votre idée est très problématique.
Le programme lui-même traite les données. Les modifications dans la table de données sont équivalentes aux modifications dans les données et la structure des données elle-même. Dans ce cas, cela aura certainement un impact sur la rationalité logique du code d'origine, et le code d'origine doit être corrigé. . Sans parler de la suppression d'une table ou de la modification d'un champ, il est normal que le programme ait des bugs, à moins que ces données ne soient que des dictionnaires de données, qui n'ont pas beaucoup d'impact sur la logique elle-même.
Et qu'est-ce qui est éduqué par le front-end. Le front-end et le back-end n'ont qu'à faire un bon travail d'interaction des données. Le back-end fournit les données et le front-end est responsable de leur affichage. Les modifications dans la structure du tableau n'ont rien à voir avec le. front-end Tant que l'interface de données et les données fournies par l'interface sont normales, le front-end ne saura pas ce qui s'est passé à la fin.

La conception de la base de données considère le paradigme de la base de données et trois modes,
Mais aucune des architectures que je connais ne peut être complètement découplée. Le couplage entre la base de données et le programme ne peut être réduit que par l'architecture. Un moyen efficace de résoudre ce problème consiste à concevoir la base de données. Essayez de comprendre les exigences autant que possible, réfléchissez davantage, réduisez les modifications de table, puis standardisez le code et adoptez certains modèles de conception pour augmenter l'évolutivité.

La base de données a été supprimée, comment voulez-vous toujours qu'elle fonctionne normalement ?
Je pense que vous devez bien gérer les exceptions. S'il y a une exception dans le PDO de la base de données, la page peut afficher directement [Le serveur est en panne] ou similaire, et l'interface peut renvoyer directement le statut = 500 ou similaire, à condition que la vraie erreur n'est pas une fois que l'information est exposée, c'est tout.

Quant au front-end ou Android dont je vous ai parlé, l'application que j'ai écrite n'a-t-elle jamais planté ?
Procédez toujours étape par étape lentement, vous ne pouvez pas grossir en une seule bouchée.

Je pense que l'ajout ou la suppression d'un champ empêchera le programme de s'exécuter. Il s'agit d'un problème personnel avant que le programme ne soit en ligne, il est normal que des problèmes de modification de la structure des tables se produisent en raison d'exigences et de modifications peu claires. la couche modèle doit être La requête doit être modifiée. S'il y a un problème, cela peut seulement signifier que vous avez écrit le programme de manière trop compliquée ou que vous n'avez pas testé l'API. Quant à avoir été trompé par le front-end, c'est simplement. que le front-end vous rejette immédiatement la faute. Le problème spécifique doit encore être spécifique. Analyse

Il n'y a aucun moyen de le découpler complètement, mais cela peut réduire l'apparition de telles tricheries.
1. Assurez-vous d'effectuer un contrôle de version. C'est un must. En fait, vous avez dit qu'un autre gars avait supprimé les modifications apportées à la table principale. Ces modifications de données doivent être développées et implémentées dans la prochaine version lorsque les exigences sont satisfaites. Si cela peut être fait par n'importe qui, si vous modifiez la structure de la table de données, il doit y avoir un problème avec le cerveau de votre chef de projet. Par conséquent, il est nécessaire d'utiliser git, svn, etc. pour le contrôle de version
2. Faire un bon travail de contrôle des autorisations pour éviter les problèmes lors du déploiement de l'entrepôt vers en ligne. doit. Surtout lorsqu'il s'agit de modifications de bases de données, d'ajouts de versions, de suppressions et de modifications, n'oubliez pas que moins il y a de personnes disposant d'autorisations, plus le système sera sécurisé.

Améliorez la logique du programme, ajoutez la gestion des exceptions, améliorez le code d'état des messages de l'interface API et configurez un mécanisme de gestion des erreurs pour garantir que toutes les erreurs ou exceptions possibles peuvent toujours générer des données d'erreur vers le front-end. assez robuste. Quant à la couche de base de données, elle n'est pas du tout nécessaire.

Tu ne devrais pas penser de cette façon. Vous devriez envisager d'effectuer un test de fumée pour votre couverture API avant de la mettre en ligne pour éviter cette erreur.

J'ai trouvé que les réponses ci-dessus étaient toutes des « grands dieux » ! Parce que, dans ma compréhension limitée, je pense : puisque le tableau de données a changé, cela signifie que le business et le code doivent être ajustés. Si la table de données change et que le code n'a pas besoin d'être modifié, alors je voudrais demander : quel est l'intérêt de modifier la table de données ? (Ne nous demandons pas si la fiche technique de l’affiche est due à une erreur de quelqu’un d’autre). Il est indéniable que vous pouvez ajouter de nombreuses exceptions captivantes au programme. Alors, à quoi ça sert de détecter une telle exception ? Juste pour ne pas renvoyer une erreur 500 ? Par conséquent, si la base de données doit être ajustée, il faut confirmer que le code doit également être ajusté en conséquence. Après avoir confirmé qu'il n'y a pas de problème, les deux seront mis à jour en même temps.
Parlons du front-end, c'est juste un imbécile qui parle beaucoup et ne sait qu'être aveugle. Vous lui demandez : si la définition de l'interface renvoie un nom de champ nom, et qu'un jour le backend le change par hasard en titre, le frontend peut-il le reconnaître automatiquement sans l'en informer et ne pas signaler d'erreur ?
En bref, s'il y a des changements dans le front-end, le back-end et la base de données, ils doivent d'abord être testés via China Unicom. S'il n'y a aucun problème, ils seront mis en ligne. Une situation comme celle de l'affiche originale ne peut être considérée que comme étant causée par les actions humaines du collègue 2B.

Donc le niveau du front-end est de plus en plus bas maintenant... Bien sûr, votre collègue qui a supprimé la base de données est à peu près le même que ce front-end

Quelle entreprise ? Le tableau peut-il être supprimé à volonté ? Je suis également convaincu que la partie avant se moque du code back-end parce qu'il n'est pas assez robuste ? Le talent dans votre entreprise est vraiment gâché.

Tout d’abord, je dois dire que votre idée est fausse dès le départ.

1. Tout d'abord, je dois admettre qu'une fois la structure de la table modifiée, le programme peut toujours s'exécuter sans erreur, ce qui est réalisable. Dans la logique back-end, l'ajout d'un traitement de tolérance aux pannes et d'une capture d'erreurs avant le traitement des données peut empêcher les informations d'erreur d'être directement transmises au front-end et de provoquer un crash du front-end.

2. Cependant, ce n'est pas parce que le programme ne signale pas d'erreur que la fonction est sans erreur. Permettez-moi de prendre votre situation comme exemple. Supposons que votre table principale est une table de commande. Le champ du titre de la commande d'origine n'existe pas. En raison du traitement de tolérance aux pannes, aucune erreur ne sera signalée, mais les données du titre de la commande ne sont pas écrites dans le fichier. base de données. Dans ce cas, lors du débogage des opérateurs front-end et back-end, le problème n'a peut-être pas été découvert car le programme peut s'exécuter normalement. Ensuite, lorsque le programme est mis en ligne pour que les clients puissent l'utiliser, et que le client découvre ce problème, alors il y a un véritable BUG. name，后来你把这个数据库字段改成了title，而没有改变后端的代码。由于后端有容错处理，所以下单还是可以正常下单的，但是由于原本标题写入name字段，现在name

3. Prenons un autre exemple de passation de commande. Vous avez dit que votre collègue avait supprimé la table principale (je suppose qu'il a supprimé la table de commande principale). Dans votre code, l'opération de commande est la suivante : ajoutez d'abord la table principale, puis ajoutez des données aux autres tables si la table principale est ajoutée avec succès. Si la table principale ne parvient pas à être ajoutée, elle sera directement supprimée. Dans ce cas, même si la table principale est supprimée, aucune erreur ne sera signalée. Cependant, de cette façon, si lors du test post-développement, le front-end, le back-end et l'exploitation et la maintenance estiment tous que cette fonction était bonne avant et n'a pas besoin d'être retestée, alors d'autres fonctions sont testées et mise en ligne, la version en ligne peut alors être soumise. Commande, mais aucune donnée de commande ne sera réellement générée (car la table principale n'a pas été écrite avec succès). Après que ce BUG ait été découvert par le client, il a été considéré comme un accident de production.

4. Donc, je crois personnellement qu'il est nécessaire de faire de la tolérance aux pannes de code et de la capture des erreurs sur le back-end, mais cela ne signifie pas que simplement parce que le programme front-end n'a aucun problème visible à l'œil nu, nous ne pouvons que changer la base de données sans modifier la logique correspondante. Après avoir modifié la base de données et corrigé la logique front-end et back-end, l'ensemble de la fonction indépendante doit être retestée pour s'assurer qu'elle est correcte avant de pouvoir être mise en ligne.