Compartilhamento de tecnologia

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

Estou trabalhando em um projeto há algum tempo e gostaria de compartilhar alguns pensamentos e sentimentos pessoais usando meu tempo após sair do trabalho ou em momentos estranhos. Vamos encorajá-lo juntos.

Vários recursos que o front-end deve ter:

(1) A capacidade de preparar dados falsos (dados simulados), porque às vezes a interface de back-end não está pronta e o front-end não tem dados, mas o cronograma é apertado e não pode esperar pelo back-end. final deve ter a capacidade de criar dados simulados.

(2) A capacidade de pular uma certa lógica de negócios. Se um negócio de circuito fechado exigir 5 etapas para ser concluído, se 2 estiverem travados, então 345 não poderá continuar a avançar. mudar o banco de dados. É simples. Se for o último recurso e estiver em ambiente de desenvolvimento, acho que está tudo bem.

(3) Capacidades de processamento de dados Às vezes, os dados são bem processados ​​pelo backend e é mais fácil para o frontend renderizar diretamente. No entanto, se os dados retornados pela interface não puderem ser usados ​​diretamente, o frontend precisará realizar algum processamento de dados antes. renderizar a página Às vezes, o processamento de dados é A carga de trabalho ainda é relativamente grande. Esta é uma pergunta relativamente vaga. Você precisa considerar quem é melhor para fazer esse trabalho de processamento de dados?

(4) Problemas de verificação. A verificação de front-end pode substituir o back-end e economizar muito trabalho de verificação, mas haverá problemas se você usar diretamente a ferramenta de interface do postman para testar. Em alguns cenários, o problema de verificação é melhor tratado pelo front-end, como a verificação de formulário; em outros cenários, como problemas de recuperação repetitiva com grandes quantidades de dados, é definitivamente a verificação de back-end; Ainda precisa ser analisado com base em cenários específicos.

(5) Quando vários projetos são desenvolvidos ao mesmo tempo, a operação do ambiente de desenvolvimento back-end afeta o desenvolvimento iterativo de diferentes versões do front-end.

(6) Gerenciamento de ramificações de código O gerenciamento de código é particularmente importante quando há muitos projetos ou quando o mesmo projeto precisa iterar várias versões ao mesmo tempo. Os projetos em que trabalhei antes não eram padronizados nesse aspecto. À medida que se tornaram mais formalizados e mais ramificações foram escritas, gradualmente ganhei um novo entendimento de que essa área realmente precisa ser bem mantida. Se o código for perdido ou não for mesclado na versão do projeto, será um grave acidente de lançamento.

(7) A capacidade de encapsular componentes. Aqui, gostaria de compartilhar algumas de minhas próprias idéias. Com base na experiência pessoal, acho que os componentes front-end podem ser simplesmente divididos em componentes funcionais gerais públicos e componentes de negócios que implementam negócios. os componentes são onipresentes na implementação de sistemas. Funções gerais podem facilitar o desenvolvimento subsequente de negócios funcionais semelhantes. Os componentes de negócios estão intimamente relacionados aos nossos negócios necessários. Os dados e a lógica neles estão fortemente acoplados aos nossos negócios e geralmente não podem ser usados ​​em outras páginas. Uma coisa que nosso front-end realmente precisa e deve considerar ao encapsular componentes é tentar não colocar dados e lógica de negócios em tais componentes funcionais gerais. Isso causará algum acoplamento de código. Quando nosso projeto se tornar gradualmente mais forte, ficará difícil de operar. isso de novo. Portanto, ao operar componentes, devemos preparar dados e lógica nos componentes de negócios tanto quanto possível. Se tivermos que fazer isso, é melhor escrever notas e tentar não afetar a lógica do código anterior. Eu encontrei esse problema quando comecei a trabalhar no projeto. Como resultado, um componente de tabela que foi originalmente encapsulado tinha muitos ifs e elses adicionados a ele. Mas acho que foi porque o acoplamento com o negócio era muito forte. por um lado, por outro lado, o número de iterações é frequente e o ciclo é relativamente longo e há muitas pessoas lidando com isso, por isso fica mais difícil fazer alterações. Portanto, em relação ao empacotamento de componentes, descobri gradualmente alguns pontos que podem ser otimizados no desenvolvimento do projeto atual. Então, se os componentes forem empacotados em iterações subsequentes do projeto, alguns problemas devem ser evitados tanto quanto possível. também algo que precisa ser otimizado ainda mais se houver tempo suficiente na programação. Afinal, isso nos permite usar os componentes com mais fluidez.

continua...