Le but de ce document est de définir et présenter les normes et les meilleures pratiques de l’équipe Flutter d’ioasys. L’objectif est que ce document soit utilisé comme guide pour le développement des projets au sein d’ioasys, établissant de manière commune à toute l’équipe les pratiques, méthodologies, architectures, normes, cadres, etc. qui peuvent/devraient être utilisés.

Cet point est important, car une fois qu’une « langue commune » est établie entre toute l’équipe, des éléments tels que le contrôle de qualité, l’alignement technique de l’équipe, la maintenabilité, etc. sont favorisés, c’est pourquoi il est d’une importance cruciale de compter sur la collaboration de tous pour que ce qui est établi ici soit suivi.

Autre aspect important, le contenu de ce guide ne sera pas statique, c’est-à-dire pouvant être modifié au fur et à mesure que de nouvelles technologies et besoins apparaissent, c’est pourquoi l’équipe Android est toujours ouverte à écouter des propositions et des améliorations qui pourront être ajoutées à ce document. Pour cela il suffit de modifier ce document et de soumettre une demande de fusion avec modification ou ouvrir un ticket dans ce dépôt.

La version de Flutter utilisée dans ce projet est la 2.12.1. Ce projet utilise Flutter Version Management (FVM). Pour l’activer, il faut lancer pub global activate fvm et ajuster l’affectation du PATH de Flutter vers C:UsersUsuariofvmdefaultbin. Ensuite, au sein du projet, exécutez fvm install pour installer la version. Il sera ensuite nécessaire de configurer les préférences de VS Code en appuyant sur F1.

Ajoutez le fragment ci-dessous à la configuration

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

Il suffit maintenant d’appuyer sur F1 et de choisir Flutter: Change SDK

et choisir la version dans le projet

L’architecture du projet est divisée de manière modulaire en micro-apps, avec le plus faible degré de couplage possible. Chaque module contient son propre écosystème architectural et la proposition adoptée est celle du Clean Dart. Voir la documentation sur CLEAN ici

Selon chaque projet, on peut trouver des structures de projet différentes pouvant être organisées comme suit

• MONOLITHIQUE
• MONOREPO
• MULTIREPO

Consultez la documentation sur les demandes de fusion ici

Consultez la documentation sur Git Flow ici

Les tests sont d’une grande importance pour assurer la qualité des projets; avec l’implémentation de Clean Dart, cela facilite la création des tests

Il est important et très efficace que la structure des dossiers de tests suive la même structure que celle du projet

Le concept Given-When-Then vise créer un « modèle » utilisé dans tout type de documentation écrite. Ce modèle comportera toujours trois mots déjà définis et il va sans dire lesquels. Voici un exemple de documentation d’exigence rédigée selon ce modèle

Étant donné est la partie où vous définissez le scénario. Quelle est la situation actuelle ? Qu’est-ce qui doit exister/se produire à l’avance pour que le problème ou l’exigence survienne ?

Lorsque est le « déclencheur » de la situation. Quand le problème est-il observé ? Quand la nouvelle fonctionnalité est-elle appelée ?

Évidemment, Alors décrit la conséquence du problème ou le résultat attendu de la nouvelle exigence

test(''' 
      Étant donné une requête pour rechercher des entreprises
      Lorsque le retour est un succès
      Alors doit renvoyer la liste des entreprises
''', () async {
}

Pour les mocks, nous utiliserons mockito; dans la version récente, cela passe par l’utilisation de build_runner pour la génération des classes simulées. Pour cela, il suffit d’ajouter la classe à simuler dans l’annotation GenerateMocks.

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

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

  group('Testes de succès', () {
    test(''' 
          Étant donné une requête pour rechercher des entreprises
          Lorsque le retour est un succès
          Alors doit renvoyer la liste des entreprises
    ''', () async {
      //préparer
      when(_datasource.get()).thenAnswer((_) async => []);

      //exécuter
      final result = await _repository.get();

      // assertion
      expect(result.fold(id, id), isA>());
      verify(_datasource.get()).called(1);
      verifyNoMoreInteractions(_datasource);
    });
  });
}

Il est important que l’équipe soit alignée sur les ressources tierces (bibliothèques, frameworks, SDKs) qui peuvent être utilisées dans les projets de l’équipe Flutter, car ces dépendances peuvent avoir un impact significatif sur le développement et la maintenance d’un projet (obsolescence, bugs ouverts, incompatibilités, etc.).

Avant d’ajouter une ressource qui ne figure pas dans la liste ci-dessous, vérifier les éléments suivants :

• Issues ouvertes GitHub
• Likes, Pub Points, Popularité
• Date de dernière modification
• Résolution des bugs rencontrés
• Mise à jour vers des ressources plus récentes de Flutter/Dart, ex. Null Safety

Ci-dessous se trouvent les ressources qui peuvent être utilisées :

• Bloc
• Dartz
• Dio
• Equatable
• HTTP
• Triple
• Mobx
• Mockito
• Hive
• Secure Storage
• Shared Preferences
• Asuka
• Effective Dart
• Toutes les ressources du cœur de Flutter
• Toutes les ressources de Firebase

Pour garantir que les bonnes pratiques de développement suivent le guide officiel de Dart, nous utilisons le package Effective Dart. Cela générera des avertissements sur des lignes qui ne respectent pas les bonnes pratiques de Flutter et inclura un lien vers la documentation officielle de Dart expliquant comment les corriger.