Para os experientes, nosso conselho pode parecer óbvio. Mas para iniciantes, recomendamos fortemente a leitura. Reserve um tempo para traduzir essas ideias em seus projetos, para que você não gaste ainda mais em refatorações intermináveis posteriormente.
Idéias semelhantes podem ser expressas em quase todas as áreas de desenvolvimento, mas falaremos sobre elas usando o exemplo de projetos em React.
Começando do zero, você pensa na melhor forma de organizar tudo para que depois não seja terrivelmente doloroso devido ao retrabalho sem fim. Em projetos pessoais de estimação, você pode cercar o que quiser - e então viver com isso você mesmo. Mas, no trabalho em equipe, é preciso agir de forma a facilitar aos colegas a compreensão da essência e o mergulho nos detalhes. Essa. Não reinvente as abordagens de desenvolvimento - é melhor se ater a práticas bem estabelecidas e reconhecidas pelo setor.
Pense em digitar
Independentemente das liberdades nas linguagens de desenvolvimento, a tipagem estática é muito útil em grandes projetos de longo prazo. Se, por algum motivo, for impossível usar a tipagem estática em tal projeto, mesmo o JSDoc ajudará significativamente a manter a qualidade do código.
Mas não vamos aconselhar você a usar sempre a digitação. Acima, não foi à toa que se fez uma reserva para grandes projetos, pois a digitação é, antes de tudo, ajudar a equipe. Mas sua organização e manutenção (o mesmo tipo muda de acordo com mudanças no backend) requer certos recursos. Em um pequeno projeto de curto prazo em que 1-2 pessoas trabalham, esse investimento é inútil. Mas são necessários quando a equipe é grande e vai se expandir.
Se o uso da digitação for justificado, recomendamos que você inicie os tipos desde o início, caso contrário, você terá que gastar muito mais tempo neste trabalho. Mesmo que você não tenha nenhuma API pronta e não conheça o modelo de dados, pelo menos faça stubs para que o tipo genérico não apareça em lugar nenhum.
À medida que o projeto vai se desenvolvendo, a digitação deve ser respeitada, mesmo que todos os prazos tenham se esgotado há muito tempo. Então você vai se agradecer por esse perfeccionismo.
Divida o código em blocos, destaque a lógica
O código não deve ser misturado. Vale a pena considerar a hierarquia na estrutura do projeto - quebrando o código em módulos e blocos, dividindo os componentes em inteligentes e estúpidos. É mais conveniente manter e desenvolver tal estrutura do que procurar por partículas dessa lógica em uma grande pilha, especialmente se essas partículas estiverem interconectadas. Talvez este conselho se aplique não apenas ao frontend.
A utilidade deste princípio era muito claramente visível no projeto com grandes formulários, sobre o qual escrevemos recentemente ( https://habr.com/ru/company/maxilect/blog/511322/ ). Nesse projeto, as verificações de bloco e a visibilidade desses blocos foram inicialmente vinculadas. Mas quando coletamos toda a comunicação dos campos em um só lugar, ficou muito mais fácil rastrear as mudanças na lógica. E o mais importante, fomos capazes de reutilizar o código em um novo projeto semelhante.
Não existe um padrão único para a estrutura de um projeto - aqui você tem que confiar no seu conhecimento. Existem duas abordagens que podem funcionar para muitos projetos: Primeiro o tipo de arquivo e primeiro o recurso.
Para encontrar um ponto de partida para encontrar uma estrutura que seja conveniente para você, recomendamos que consulte a documentação. A melhor prática geralmente é descrita lá. Por exemplo, React e Redux em sua documentação oferecem padrões para organizar a lógica e a estrutura de arquivos de um projeto. Com alguma experiência, você pode experimentar e desviar-se dos padrões se isso permitir que você contorne algumas restrições para um projeto específico, mas na maioria dos casos isso não é necessário. E, claro, não se esqueça de princípios “básicos” como SOLID. Bom artigo sobre como aplicar esses princípios no React:https://habr.com/ru/company/ruvds/blog/428079/ . Bom artigo sobre arquitetura limpa: https://habr.com/ru/post/499078/ .
Sobre a organização da base de código no React e questões relacionadas, existe uma boa coleção de materiais, embora não seja atualizada há muito tempo: https://github.com/markerikson/react-redux-links/blob/master/project-structure.md .
Formule uma convenção de codificação
O arquiteto que inicialmente planeja o projeto com base no caminho ao longo do qual o aplicativo será desenvolvido tem certos modelos em mente. Vale a pena expressá-los explicitamente na forma de um passaporte de projeto, complementando-o com as regras de escrita de código, por exemplo, o que pode e não pode ser incluído em um módulo separado (em geral, esta é uma questão bastante filosófica). Esse "passaporte" ajudará os desenvolvedores a determinar com antecedência como escrever, para que depois não reescrevam. Isso pode reduzir o tempo de revisão e ajudar a padronizar as abordagens de codificação, o que é especialmente útil quando um projeto está sendo trabalhado por trabalhadores remotos ou equipes distribuídas.
Atenha-se ao paradigma escolhido
Se no início você decidiu aderir a alguma abordagem, por exemplo, web design atômico, não deve abandoná-la assim que os prazos começarem a se esgotar. O suporte iniciado e abandonado para um paradigma às vezes é quase pior do que sua ausência completa. Se você “dar rédea solta ao caos” um pouco, será extremamente difícil restaurar a ordem - você terá que gastar tempo voltando ao paradigma. E você não conseguirá “pular” rapidamente para outro, pois uma bagunça informe já se formou no projeto.
A rejeição do paradigma por questão de tempo ou outros fatores é como trocar de cavalo em um cruzamento. É doloroso e não recomendado. Mas se não houver saída, você precisará cobrir a maior parte de sua aplicação com testes. E aqui passamos para a próxima dica ...
Lembre-se de testes
Os testes em um projeto não precisam ser apenas. Eles têm que trabalhar. E é necessário incluí-los no projeto desde o primeiro estágio - assim que o desenvolvimento começar. Caso contrário, em um determinado ponto, é possível mudar algo na aplicação, e então sair dos prazos de lançamento, restaurando o desempenho de diferentes partes do projeto, que são cobertas apenas por testes manuais.
Que os testes sejam pequenos no início e não verifiquem absolutamente nada. Mas é muito melhor desenvolvê-los à medida que a funcionalidade cresce, do que gastar uma semana depois pagando essa “dívida técnica”. Em termos de tempo gasto, a primeira abordagem é mais eficaz. Aliás, muitos estão bem cientes disso, mas ainda deixam os testes para depois.
Também gostaria de mencionar a integração e os testes ponta a ponta.
Os testes de integração devem ser executados toda vez que você corrigir bugs ou adicionar novos recursos, para ter certeza de que os ajustes não afetaram nada. Em nossos projetos, tentamos lançá-los automaticamente quando carregamos os resultados de nosso trabalho (implementamos isso por meio de um gancho). Os testes não funcionaram - você não deve carregar as alterações no projeto. Primeiro você precisa consertar tudo.
Mas os testes de integração só dizem respeito ao front-end. Os testes de ponta a ponta são mais lentos e testam a interação do aplicativo com todos os itens dependentes. Esses testes simulam ações do usuário. Aqui não estamos zombando de nada, mas realmente esperando pelas respostas do back-end e verificando as interações dentro de todo o ecossistema do projeto usando o Cypress (também podemos recomendar o Puppeteer como um análogo).
Pense antes de atualizar, mas não desista
No mundo do frontend, tudo muda muito rapidamente - versões de framework substituem umas às outras, aparecem bibliotecas com mais sucesso. Vale a pena mantê-los atualizados, mas não fanáticos.
Como a digitação, da qual falamos acima, qualquer atualização custa recursos (ou seja, indiretamente, dinheiro). Mas existem algumas coisas que tornam impossível desativar completamente as atualizações.
Primeiro, o suporte até mesmo para as bibliotecas mais bem-sucedidas às vezes termina. Nessa situação, você terá que buscar análogos mais promissores.
Em segundo lugar, trabalhar com a pilha de tecnologia antiga raramente inspira os desenvolvedores. Se você perceber que a equipe não pode ser mantida em algum Backbone empoeirado, ou perceber que uma pilha desatualizada está afetando criticamente o fluxo de novos desenvolvedores, você terá que atualizar.
Os refrescos devem ser considerados parte da ordem natural das coisas. Mas antes de alterar uma biblioteca ou atualizar um framework, você deve sempre fazer alguma pesquisa.
A nova versão é certa para você? Como organizar a transição em geral? E, claro, você precisa planejar tudo com antecedência.
As atualizações são extremamente difíceis se não houver testes no projeto. Mesmo uma pequena biblioteca de dados pode abranger muitas partes diferentes de um projeto e atualizá-la leva a um teste de regressão completo. Com o crescimento do projeto, não será possível fazê-lo de forma eficiente, havendo apenas testes manuais no arsenal.
Você está bem agora?
A medida de quão eficientemente você desenvolve seu projeto pode ser a razão entre o tempo gasto no desenvolvimento de novos recursos e o tempo gasto em bugs. Dependendo da abordagem, este indicador pode ser mais ou menos, por isso não vamos nos comprometer a definir níveis “alvo”. Você mesmo pode comparar a situação antes e depois de quaisquer transformações.
Além das características não numéricas, como “satisfação do desenvolvedor com o projeto”, existe um indicador como o tempo que uma nova pessoa se junta ao projeto. Esta é uma característica de quão bem um projeto é claramente descrito por meio de documentação, testes e convenção de codificação.
E lembre-se, é melhor deixar um código melhor do que era antes de você. Não gere dívida técnica, caso contrário atrapalhará o desenvolvimento do projeto posteriormente.
Talvez você tenha suas próprias dicas? Deixe nos comentários!
PS Publicamos nossos artigos em vários sites do Runet. Assine nossas páginas no canal VK , FB , Instagram ou Telegram para conhecer todas as nossas publicações e demais novidades da Maxilect.
PPS A imagem do título da Competição Playhouse recentemente realizada.