Fundamentos de Frontend

O chapter de frontend da Toss publicou um site que apresenta os critérios que considera para um bom código de frontend.

• Explicado com base em TypeScript, muito usado por desenvolvedores frontend
• Apresenta best practices a partir de quatro perspectivas: legibilidade, previsibilidade, coesão e acoplamento
• Fornece exemplos usando bibliotecas frequentemente utilizadas no frontend real

4 critérios

1. Legibilidade
   Legibilidade (Readability) é o grau de facilidade de leitura do código. Para que o código seja fácil de modificar, primeiro é preciso entender que comportamento ele tem.

2. Previsibilidade
   Previsibilidade (Predictability) se refere ao quanto os colegas que colaboram com você conseguem prever o comportamento de funções ou componentes. Um código com alta previsibilidade segue regras consistentes, e só de olhar para o nome, os parâmetros e o valor de retorno de uma função ou componente já dá para entender o que ele faz.

3. Coesão
   Coesão (Cohesion) se refere a se o código que precisa ser alterado é sempre alterado em conjunto. Um código com alta coesão não gera erros inesperados em outras partes quando uma parte é modificada. Isso acontece porque a estrutura garante que as partes que precisam ser alteradas juntas realmente sejam alteradas juntas.

4. Acoplamento
   Acoplamento (Coupling) se refere ao alcance do impacto quando o código é modificado. Um código fácil de alterar é aquele em que o alcance do impacto é pequeno quando há mudanças, permitindo prever o escopo das alterações.

[savvykang]

Tenho curiosidade sobre por que se usa arquivo como a menor unidade de gerenciamento para componentes e hooks. Imagino que possa ser por limitações no suporte da IDE ou no tree shaking, mas não tenho certeza, então gostaria de perguntar.

Ao ler código, quando vejo um arquivo com apenas uma função ou um arquivo index.ts que só tem instruções de import/export, sinto que aumenta a quantidade de coisas que preciso lembrar. Em comparação com a abordagem de misturar hooks e componentes dentro de um único arquivo, parece uma organização que eleva a carga cognitiva além do necessário. Ainda assim, existem vantagens ou motivos para usar esse tipo de organização?

[firea32]

Normalmente, a grande premissa de “bom desenvolvimento” de que se fala nesses contextos é que há muitos desenvolvedores trabalhando.
O que você mencionou — aumentar a quantidade de coisas para lembrar — significa que a própria pessoa está assumindo responsabilidade pelo projeto inteiro, mas
em um ambiente com muitos desenvolvedores, cada um desenvolve apenas a parte pela qual é responsável.
Se surgir um problema, basta olhar só para aquela parte; não é necessário examinar todas as partes relacionadas.
De certa forma, eu vejo isso como uma escolha pela produtividade em vez de uma otimização extrema.

[savvykang]

Como você disse, em um ambiente em que é possível detalhar a divisão de responsabilidades do trabalho, a abordagem do texto faz sentido. Acho que o texto ficaria mais completo se explicasse os trade-offs da separação de código e os critérios para tomar essa decisão.

[beenzinozino]

No meu caso, ao fazer desenvolvimento frontend, os motivos para usar arquivos como a menor unidade de gerenciamento de componentes ou hooks são os seguintes.

1. Facilidade de teste.

Ou seja, fica mais fácil fazer a correspondência entre um módulo e um teste unitário.

Acredito que, no desenvolvimento frontend, predomina um paradigma baseado em funções puras, mas quando existem várias funções dentro de um único arquivo, fica difícil fazer uma correspondência 1 para 1 ao escrever testes unitários.

Se, por exemplo, houver várias funções utilitárias dentro de um único arquivo chamado remark-plugin.js, como os testes deveriam ser escritos? Seria uma boa escolha criar apenas um arquivo remark-plugin.test.js e escrever ali, de forma agrupada, os testes para várias funções utilitárias?

Nessa situação, se criarmos um diretório chamado remark-plugins e separarmos as funções utilitárias uma a uma ali dentro para escrever os testes, acho que isso traz vantagens como deixar o papel de cada função mais claro no futuro e também tornar o rastreamento de commits no GitHub muito mais limpo.

2. Estruturação de diretórios

Module bundlers como o commonjs no desenvolvimento de servidor ou o webpack no cliente costumam definir o arquivo index.js como arquivo de entrada de um determinado diretório. Isso também é, em parte, uma convenção usada com frequência há muito tempo, então há um aspecto de simplesmente aceitá-la e utilizá-la.

Mas, na minha opinião, o motivo mais importante é que, no paradigma de funções puras da programação funcional, não se deve depender de estado externo, então quando várias funções ficam concentradas em um único arquivo, acho que aumenta a chance de cometer o erro de referenciar estado externo. (Vale a pena pensar no motivo de o escopo de módulo ter surgido no ES6.)

3. Facilidade para rastrear commits.

Pessoalmente, acho que quando as funções estão divididas em arquivos separados, em vez de várias funções utilitárias misturadas dentro de um único arquivo, fica muito mais simples acompanhar o histórico de commits.

Quando uma funcionalidade é adicionada ou um bug é corrigido em algum módulo, basta focar apenas nesse módulo sem precisar consultar outros módulos.

---

Acabei me alongando e o texto ficou meio sem muita organização. (Ainda não tenho tanto entendimento sobre tree shaking, então prefiro não falar muito sobre isso...) Claro, o que estou dizendo pode não ser a resposta certa, então acho que seria bom considerar isso apenas como referência!

[thkimdev]

Isso é bom.

[illiil1lii]

Foi muito bem escrito e flui facilmente na leitura. Recomendo.

[tsboard]

Obrigado por compartilhar! Eu também preciso ler com atenção.

[bbulbum]

Embora tenha sido escrito com foco em FE, acho que são ideias boas para aplicar a qualquer software. Obrigado por compartilhar insights tão bons.