SwiftUI Series 15 ｜ Crie um projeto SwiftUI sustentável do zero

Se me pedissem para construir um projeto SwiftUI do zero, a primeira coisa que consideraria não seria a aparência do diretório, nem me preocuparia com isso primeiro:

• Você precisa enviar um modelo de arquitetura completo? -Preciso desenhar muitas camadas de base primeiro?

O que estou pensando primeiro são estas coisas:

• Como o status flui
• Como mudar as responsabilidades da página
• Quando e até que ponto os componentes são bombeados?
• O projecto tornar-se-á difícil de modificar após três meses?

Como muitos projetos SwiftUI são bastante leves no início, o verdadeiro divisor de águas geralmente ocorre depois de dois ou três meses:

• Mais e mais páginas
• O estado está cada vez pior
• A reutilização de componentes está se tornando cada vez mais aleatória
• Comece a empilhar a lógica de negócios no View

Portanto, o que a “manutenção” realmente quer resolver é a estabilidade após o crescimento, e não a velocidade de desenvolvimento na primeira semana.

1. Não vou construir uma estrutura pesada desde o início, mas primeiro esclarecerei as responsabilidades.

Um dos mal-entendidos mais comuns ao iniciar um projeto do zero é:

• O negócio ainda não começou
• Primeiro, desenhe um conjunto completo de estruturas que pareçam completas

Isso não é necessariamente errado, mas o risco é:

• abstrair muito cedo
• A estrutura não corresponde ao negócio real
• A equipe continuará contornando isso mais tarde

Então eu prefiro:

• Deixe claro os limites das responsabilidades primeiro
• Adicione camadas gradualmente à medida que a complexidade aumenta

Em vez de “ser grande e completo no primeiro dia”, dou mais valor a “ser tranquilo no primeiro mês”.

2. A primeira coisa que geralmente entendo são as três camadas: camada de página, camada de status e camada de capacidade.

1. Camada de página

Responsável por:

• Estrutura
• Combinação de componentes
• Mapeamento de status da página

2. Camada de estado

Responsável por:

• Situação comercial
• Processos assíncronos
• Mudança de estado semântico de página

3. Camada de capacidade

Responsável por:

• rede
• Armazenamento
• Serviços de domínio
• Componentes comuns e recursos de estilo

Estas três camadas podem não ser necessariamente desmanteladas muito bem desde o início, mas a consciência deve estar presente primeiro. Caso contrário, os projetos SwiftUI podem facilmente cair em “escrever tudo diretamente na Visualização”.

3. Serei muito cauteloso com “visões gigantes”

Escrever UI no SwiftUI é muito fácil, então um dos maus cheiros mais comuns é:

• A estrutura está escrita em View
• A solicitação está escrita em View
• O julgamento do status é escrito em View
• A montagem de copywriting também é escrita em View

É claro que parece muito rápido nos estágios iniciais, mas quando o projeto se torna complexo, a Visualização rapidamente se tornará:

• Difícil de ler
• Difícil de mudar
• Imprevisível

O problema aqui é que o View assume muitas responsabilidades de não exibição.

4. Vou desacelerar deliberadamente a reutilização de componentes em vez de fazer isso com dificuldade no início.

É fácil para muitas equipes buscar inicialmente uma “biblioteca de componentes universais”. Mas em projetos reais, abstrair muito cedo costuma ser mais perigoso do que abstrair mais tarde:

• A interface será projetada para ser muito ampla
• Muitas opções estão preparadas para possíveis cenários futuros
• Os componentes parecem ser reaproveitados, mas na verdade quem os utiliza se sentirá desconfortável

Portanto, prefiro deixar o componente crescer primeiro em uma ou duas páginas reais e depois extraí-lo depois que o padrão estiver estável o suficiente. Os componentes extraídos dessa forma costumam estar mais próximos do uso real do que da ginástica abstrata.

5. Os limites do estado são geralmente mais importantes do que a estrutura de diretórios

Muitos projetos passam muito tempo discutindo no início:

• Recurso primeiro ou camada primeiro
• Como dividir pastas

Claro que isso é importante, mas o que mais me importa é:

• Qual status é gerenciado pela própria página?
• Quais estados são gerenciados por objetos de negócios externos
• Qual status deve ser compartilhado e qual não deve ser compartilhado

Porque o que realmente determina os custos de manutenção é muitas vezes se o status está alterado.

6. O núcleo da manutenção é, na verdade, permitir que cada camada “explique claramente pelo que é responsável”

Se um projeto se tornar cada vez mais difícil de ser alterado posteriormente, geralmente há estes sinais:

• A estrutura da página não mostra a prioridade
• A atribuição de status torna-se cada vez mais confusa
• Os limites dos componentes estão se tornando cada vez mais abstratos
• Uma vez alterados os requisitos, a lógica deve ser complementada em muitas camadas

Portanto, para um projeto SwiftUI sustentável, o que mais valorizo geralmente é:

• A página pode ser lida rapidamente
• O status pode ser distinguido rapidamente
• Os limites dos componentes são naturais -A lógica de negócios não está empilhada no View

Estas quatro coisas são muito simples, mas extremamente valiosas a longo prazo.

7. Conclusão: Ao construir um projeto SwiftUI do zero, o que realmente precisa ser definido corretamente primeiro é o limite, não o modelo.

Para resumir, eu diria:

Para construir um projeto SwiftUI sustentável do zero, o mais importante é acertar os limites do estado, as responsabilidades da página e a abstração dos componentes.

Uma vez estabelecidos esses limites, o projeto crescerá mais e será mais estável; Se os limites não forem estabelecidos, não importa quão avançado seja o modelo, ele pode ser facilmente eliminado por negócios reais.