Muitas linguagens acabam orientando os seus programadores em uma direção de padronização. O antigo Delphi já trazia seu estilo PascalCase, também conhecido como UpperCamelCase, com letras prefixando os nomes identificando seu propósito (T para tipo, I para interface, etc.). Esse estilo acabou sendo adotado na plataforma .Net (alguns arquitetos da Borland foram contratados pela Microsoft exatamente para criar a sua nova plataforma na época, para rivalizar com a crescente tecnologia J2EE...). Java e Javascript adotam o padrão CamelCase, e o Maven acabou padronizando a estrutura das pastas dos projetos Java pela sua adoção maciça pela comunidade. Essa padronização é algo bom e positivo e toda equipe deve procurar buscar um padrão para adotar. Se a linguagem utilizada já traz um padrão pronto, inicie o seu a partir desse, para não ter que recriar a roda.
O Guia de Estilo Angular traz toda uma série de recomendações que procuram padronizar as aplicações desenvolvidas na plataforma e torná-las fáceis de manter e evoluir. Geralmente é o que queremos de nossas aplicações, não é mesmo?
Gostaria de destacar algumas dessas recomendações presentes no Guia, as mais importantes na minha visão:
- Nomenclatura dos arquivos - esta recomendação me causou estranheza e levei tempo para me acostumar com ela, mas faz todo sentido. A recomendação é que o nome do arquivo traga seu tipo e propósito, além da extensão. Assim, quando você abrir um projeto Angular você vai encontrar arquivos nomeados assim: hero-list.component.ts; hero-list.component.html; hero.service.ts. A primeira parte indica a funcionalidade - uma lista de heróis, por exemplo. Repare que separamos termos por um hífen, não juntamos e colocamos a primeira letra maiúscula, como no Java (essa parte me causou maior estranheza, mas faz todo sentido; maiúsculas e minúsculas em um arquivo não chamam tanta atenção quanto um hífen). A segunda parte traz o propósito do arquivo, com sufixos como component para um componente, service para um serviço e assim por diante. Pode parecer redundante, mas torna a identificação imediata. Por fim, a extensão do tipo de arquivo: ts para um programa TypeScript, html para uma página HTML e assim por diante. Pontos separam uma parte da outra. Seguindo essa nomenclatura você já identifica o propósito de um arquivo pelo nome. Se seguirmos as recomendações de estrutura das pastas do mesmo guia, o trabalho de localizar um arquivo que precisamos mexer será bem fácil. E essa é a próxima recomendação que vamos falar...
- LIFT - essa pequena sigla é uma super recomendação que engloba quatro recomendações: LOCATE, IDENTIFY, FLAT e T-DRY. Já falamos um pouco na recomendação acima, localizar facilmente um arquivo em um projeto te poupa muito tempo, então são duas dessas recomendações, LOCATE e IDENTIFY. A recomendação FLAT diz respeito à estrutura de pastas e os arquivos contidos nela. Manter poucos níveis de pastas, com no máximo 8 a 10 arquivos em cada pasta é a recomendação. Por último, T-DRY significa tentar ser DRY, que é outra sigla: Don't Repeat Yourself. Não se repita, evite a duplicação de código ao máximo para facilitar a manutenção futura.
- Módulos Core e Shared e um módulo por funcionalidade - derivada da super recomendação acima, temos a recomendação de criação dos módulos core e shared, para guardar componentes, diretivas, pipes e serviços comuns e utilizados ao longo da aplicação. E também da criação de um módulo por funcionalidade, os chamados Feature Modules. Com essas recomendações, você já terá sua estrutura de pastas, as regras para nomear os arquivos de seu projeto e terá a vida facilitada no desenvolvimento e manutenção.
 |
| Estrutura recomendada de pastas para um projeto Angular |
- Serviços - toda a lógica de negócio que será utilizada em mais de um ponto da aplicação deve ficar localizada em classes especiais chamadas de serviços (services). Em especial, o acesso aos serviços externos REST. A recomendação é sempre utilizar o decorador @Injectable e tornar o serviço um singleton (padrão de projeto que indica uma única instância da classe para todo o projeto). Desta forma:
@Injectable({
providedIn: 'root',
})
export class Service {
}
- Regra de apenas um - para finalizar, uma regra simples mas muito importante. Em cada arquivo, manter um e somente um tipo. Somente uma classe, um componente, um serviço. Não caia na tentação de adicionar algo a mais, no futuro você vai certamente se arrepender.
Poucas recomendações a seguir, porém objetivas e todas com excelentes justificativas. Acredito que este é um novo caminho no desenvolvimento de software: as ferramentas e os frameworks estão se esforçando cada vez mais para apontar um caminho de boas práticas para que os programadores possam maximizar os resultados alcançados. E o Angular é uma das plataformas que mais segue esse moderno conceito. Acredite em um cara que tem alguma experiência ao longo da vida: você vai deixando seu rastro conforme vai programando, e quanto melhor for esse rastro, mais respeito e consideração você vai conquistar!
Comentários
Postar um comentário