PADRÕES E BOAS PRÁTICAS - FLUTTER

Versão 1.0

I - Introdução

O objetivo deste documento é definir e apresentar os padrões e melhores práticas do time de Flutter da ioasys. O objetivo é que este documento seja usado como guia para o desenvolvimento de projetos dentro da ioasys, estabelecendo de forma comum a todo time as práticas, metodologias, arquiteturas, padrões, frameworks etc. que podem/devem ser usados.

Este ponto é importante, pois uma vez que estabelecida uma "linguagem comum" entre todo o time, pontos como controle de qualidade, alinhamento técnico do time, manutenibilidade, etc. são favorecidos, por isso é de extrema importância contar com a colaboração de todos para que o que aqui estabelecido seja seguido.

Outro aspecto importante, o conteúdo deste guia não será estático, ou seja, podendo ser alterado a medida que novas tecnologias e necessidades surgirem, por isso o time de Android está sempre aberto a escutar propostas e melhorias que possam ser agregadas a este documento. Para tal basta editar este documento e submeter um pull request com alteração ou abrir uma issue neste repositório.

II - FVM

A Versão do flutter que é utilizada neste projeto foi a 2.12.1, este projeto utiliza do Flutter Version Management (FVM) para utiliza-lo é necessário ativa-lo pub global activate fvm troque o apontamento do PATH do flutter para C:\Users\Usuario\fvm\default\bin Agora dentro do projeto execute fvm install para instalar a verão. Agora será necessário configurar as preferencias do VS CODE aperte F1

Adicione o trecho abaixo a configuração

{
    ...
    "dart.flutterSdkPaths": [".fvm/flutter_sdk"]
}

Agora basta pressionar F1 e selecionar Flutter: Change SDK

e escolher a versão no projeto

III - Apresentação geral da arquitetura

A arquitetura do projeto é dividia de forma modular subdividido em micro apps, onde tem o menor índice de acoplamento possível. Cada modulo contem seu próprio ecossistema de arquitetura e a proposta adotada foi a do clean dart. Veja a documentação sobre CLEAN aqui

Propostas de arquitetura

Dependendo de cada projeto podemos ter estrutura de projetos diferentes podendo estar em

• MONÓLITO
• MONOREPO
• MULTIREPO

IV - Pull Requests

Veja a documentação sobre Pull Request aqui

V - Git Flow

Veja a documentação sobre Git Flow aqui

VI - Testes

Teste é algo de grande importância para garantir a qualidade dos projetos, com a implantação do Clean Dart facilita a criação dos testes

Estrutura de pastas

É importante e bastante eficaz que a estrutura de pastas do testes sigam a mesma estrutura do projeto

Given-When-Then (Dado-Quando-Então)

O conceito Given-When-Then visa criar um “template” usado em todo e qualquer tipo de documentação escrita. Este template terá sempre 3 palavras já definidas e obviamente nem preciso falar quais são. Veja um exemplo de documentação de requisito escrito neste template

Given - Dado

O Given é a parte que você define o cenário. Qual a situação atual? O que deve existir/acontecer de antemão para que o problema ou o requisito aconteça?

When - Quando

When é o “trigger” da situação. Quando o problema é percebido? Quando a nova funcionalidade é chamada?

Then - Então

Obviamente, o Then descreve a consequência do problema ou o resultado esperado do novo requisito

Exemplo

test('''
      Dado uma requisição para buscar empresas
      Quando retorno for sucesso
      Então deve retornar Lista de Empresas
''', () async {
}

Mocks

Para Mocks utilizaremos o mockito, na versão nova é a utilização do build_runner para geração das classes mockadas. Para isto basta adicionar a classe a ser mockada na annotation GenerateMocks.

@GenerateMocks([IEnterpriseDatasource])
void main() {
  late EnterpriseRepository _repository;
  final _datasource = MockIEnterpriseDatasource();

  setUp(() {
    _repository = EnterpriseRepository(_datasource);
  });

  group('Testes de sucesso', () {
    test('''
          Dado uma requisição para buscar empresas
          Quando retorno for sucesso
          Então deve retornar Lista de Empresas
    ''', () async {
      //prepare
      when(_datasource.get()).thenAnswer((_) async => <EnterpriseModel>[]);

      //execute
      final result = await _repository.get();

      // assert
      expect(result.fold(id, id), isA<List<EnterpriseEntity>>());
      verify(_datasource.get()).called(1);
      verifyNoMoreInteractions(_datasource);
    });
  });
}

Recursos de terceiros

É importante que o time esteja alinhado sobre quais recursos de terceiros (libraries, frameworks, SDK's) podem ser utilizadas nos projetos do time de flutter, uma vez que essas dependências podem ter um impacto significativo no desenvolvimento e manutenção de um projeto (depreciação, bugs em aberto, incompatibilidades etc.).

Antes de adicionar um recursos que não esteja na lista abaixo, observar os seguintes itens:

• Issues abertas Github
• Likes, Pub Points, Popularity
• Data ultima alteração
• Resolução de bugs encontrados
• Atualização para recursos mais novos do Flutter/Dart, ex. Null Safety

Segue abaixo a lista dos recursos que podem ser utilizados:

• Bloc
• Dartz
• Dio
• Equatable
• HTTP
• Triple
• Mobx
• Mockito
• Hive
• Secure Storage
• Shared Preferences
• Asuka
• Effective Dart
• Todas os recursos do core do Flutter
• Todos os recursos do firebase

VIII - Boas práticas de desenvolvimento

Para garantir que as boas práticas de desenvolvimento seguindo a guia oficial do Dart utilizamos o package Effective Dart Isso ira gerar Avisos de linhas que não condiz com as boas praticas do Flutter e com um link para a documentação oficial do Dart explicando como corrigi-lo

IX - Bibliografias

Abaixo há alguns links de documentações e artigos que possam ser consultados

• Testes
• White Label Apps
• White Label in Flutter
• Modular
• Triple
• Get_IT
• Bloc