Partage de technologie

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Je travaille sur un projet depuis un certain temps et j'aimerais partager quelques réflexions et sentiments personnels en utilisant mon temps après le travail ou pendant un moment occasionnel. Ensemble, encourageons-nous.

Plusieurs fonctionnalités que le front-end devrait avoir :

(1) La possibilité de préparer de fausses données (données simulées), car parfois l'interface back-end n'est pas prête et le front-end n'a pas de données, mais le calendrier est serré et ne peut pas attendre le back-end. end doit avoir la capacité de créer des données simulées.

(2) La possibilité de sauter une certaine logique métier. Si une entreprise en boucle fermée nécessite 5 étapes, si 2 est bloquée, alors 345 ne peut pas continuer à avancer. Bien sûr, c'est en effet un bon moyen de perturber le backend. changer la base de données. C'est simple. Si c'est un dernier recours et que c'est dans un environnement de développement, je pense que ce n'est pas grave.

(3) Capacités de traitement des données. Parfois, les données sont bien traitées par le backend et il est plus facile pour le frontend de les restituer directement. Cependant, si les données renvoyées par l'interface ne peuvent pas être utilisées directement, le frontend doit effectuer un certain traitement des données avant. le rendu de la page. Parfois, le traitement des données est La charge de travail est encore relativement importante. C'est une question relativement vague. Vous devez vous demander qui est le mieux placé pour effectuer ce travail de traitement des données ?

(4) Problèmes de vérification. La vérification frontale peut remplacer le back-end et économiser beaucoup de travail de vérification, mais il y aura des problèmes si vous utilisez directement l'outil d'interface Postman pour tester. Dans certains scénarios, le problème de vérification est mieux géré par le front-end, comme la vérification de formulaire ; dans d'autres scénarios, comme les problèmes de récupération répétitifs avec de grandes quantités de données, il s'agit définitivement d'une vérification back-end. Il reste encore à l’analyser sur la base de scénarios précis.

(5) Lorsque plusieurs projets sont développés simultanément, que faut-il faire si le fonctionnement de l'environnement de développement back-end affecte le développement itératif de différentes versions du front-end ?

(6) Gestion des branches de code La gestion du code est particulièrement importante lorsqu'il existe de nombreux projets ou lorsqu'un même projet doit itérer plusieurs versions en même temps. Les projets sur lesquels j'ai travaillé auparavant n'étaient pas standardisés à cet égard. Au fur et à mesure qu'ils devenaient plus formalisés et que davantage de branches étaient écrites, j'ai progressivement acquis une nouvelle compréhension du fait que ce domaine devait vraiment être maintenu. Si le code est perdu ou s'il n'est pas fusionné dans la version du projet, ce sera un grave accident de version.

(7) La capacité d'encapsuler des composants.Je voudrais partager ici certaines de mes propres réflexions, sur la base de mon expérience personnelle, je pense que les composants frontaux peuvent être simplement divisés en composants fonctionnels généraux publics et en composants métier qui implémentent les fonctionnalités générales. les composants sont omniprésents dans la mise en œuvre des systèmes. Les fonctions générales peuvent faciliter le développement ultérieur d’entreprises fonctionnelles similaires. Les composants métier sont étroitement liés à notre activité requise. Les données et la logique qu'ils contiennent sont fortement liées à notre activité et ne peuvent généralement pas être utilisées dans d'autres pages. Une chose dont notre front-end a vraiment besoin et doit prendre en compte lors de l'encapsulation de composants est d'essayer de ne pas placer les données commerciales et la logique dans de tels composants fonctionnels généraux. Cela entraînera un certain couplage de code. Lorsque notre projet deviendra progressivement plus fort, il deviendra difficile à exploiter. encore une fois. Par conséquent, lors de l'exploitation des composants, nous devons autant que possible préparer les données et la logique dans les composants métier. Si nous devons le faire, il est préférable d'écrire des notes et d'essayer de ne pas affecter la logique du code précédent. J'ai rencontré ce problème lorsque j'ai commencé à travailler sur le projet. En conséquence, un composant de table initialement encapsulé contenait trop de si et d'autres. Je pense que c'était parce que le couplage avec l'entreprise était trop fort. c'est d'une part, et d'autre part, le nombre d'itérations est fréquent, le cycle est relativement long, et il y a beaucoup de personnes qui s'en occupent, donc il devient plus difficile d'apporter des changements. Par conséquent, concernant le packaging des composants, j'ai progressivement découvert certains points qui peuvent être optimisés dans le développement du projet en cours. Ensuite, si les composants doivent être packagés dans les itérations ultérieures du projet, certains problèmes doivent être évités autant que possible. c'est aussi quelque chose qui doit être encore optimisé s'il y a suffisamment de temps dans le calendrier. Après tout, cela nous permet d’utiliser les composants de manière plus fluide.

à suivre...