Systèmes d'exploitation pour smartphone iOS et Android

Découvrez les spécificités des systèmes d'exploitation pour smartphones iOS et Android et le développement cross-platform avec React Native.

À l’heure du tout numérique et de l’utilisation massive des smartphones, on compte pas moins de 485 000 nouveaux téléchargements d’applications mobile par minute. Le développement de ces applications représente ainsi un excellent moyen pour les entreprises pour promouvoir leurs produits ou proposer des fonctionnalités innovantes. 

Dans ce domaine hautement concurrentiel, deux acteurs majeurs ont su tirer leur épingle du jeu entre le milieu des années 2000 et aujourd’hui. Ils dominent désormais le marché mondial du smartphone.

Ces deux géants très populaires font partie des GAFAM. En effet, il s’agit de la société Apple et son système d’exploitation (ou OS pour Operating System) pour smartphone « iOS » et Google avec son OS mobile Android.

Avec des utilisateurs divisés entre ces deux systèmes d’exploitation, il est crucial, pour les développeurs, de déterminer sous quel OS faire tourner leur future solution mobile.

Dans cet article, nous explorerons les langages natifs permettant de développer une application dédiée au système d’exploitation smartphone de son choix. Ensuite, nous nous concentrerons sur le développement multi-plateforme (ou cross-platform), avec l’utilisation de frameworks comme React Native.

iOS et Android : les titans du système d'exploitation smartphone

En 2007, Apple et son système d'exploitation pour iPhone (ou iOS) redéfinissent le monde des smartphones.

Conçu exclusivement pour les mobiles de la marque à la pomme, cet OS est optimisé pour offrir une expérience utilisateur fluide et graphiquement homogène.

Par ailleurs, l'App Store, qui héberge les applications pour iOS, est un environnement strictement contrôlé, garantissant aux utilisateurs une certaine sécurité et qualité.

Notez que la publication d’applications iOS sur ce magasin en ligne nécessite un compte « Apple Developer » à $99 par an. L’environnement de développement (ou IDE) Xcode, logiciel exclusif aux ordinateurs portables et fixes de Apple est également un prérequis à la publication d’application iOS.

De son côté, le système d'exploitation Android, développé par Google, est aujourd’hui le cœur de nombreux smartphones et tablettes.

En étant open source et basé sur le noyau Linux, Android offre une grande flexibilité aux fabricants et aux développeurs.

En outre, le Google Play Store, magasin phare de l’OS, abrite une myriade d'applications mobiles, des plus utiles aux plus innovantes. 

Pour être reconnu par Google en qualité de développeur Android à vie, il suffit de payer $25 et ainsi pouvoir publier des jeux et applications depuis la Google Play Console.

Les langages de natifs iOS et Android

Vous l’aurez compris, pour toucher un maximum d’utilisateurs, les développeurs doivent créer des applications mobiles fonctionnant à la fois sur iOS et Android.

Pour autant, chaque système d’exploitation requiert l’utilisation du langage de programmation natif associé. Chaque langage demandant une expertise et un temps de développement dédié, les coûts et les ressources sont bien souvent doublés.

Côté iOS, c’est Swift le langage natif officiel développé en 2014 par Apple pour la création d’applications mobiles. Il est puissant, intuitif et conçu pour être efficace tout en étant facile à lire et à écrire. Swift s’inspire d’ailleurs beaucoup du langage Objective C, créé en 1980, qui était auparavant utilisé par les développeurs iOS.

Swift demande néanmoins aux développeurs d’applications iOS d’utiliser l’environnement de développement Xcode, exclusif aux ordinateurs fixes et portables commercialisés par la marque à la pomme. Même si l’installation de machines virtuelle Mac OS est envisageable sous Windows ou Linux, cette seule contrainte a déjà refroidie de nombreuses entreprises et développeurs. Pour créer une application iOS, c’est vers des agences de développement spécialisées dans cette technologie que beaucoup se tournent.

Pour Android, c’est le langage Kotlin qui a rapidement gagné en popularité comme la solution de prédilection pour le développement d’application Android. Kotlin est développé et maintenu par Google depuis 2011. Anciennement, c’était le langage Java, créé en 1995, qui était utilisé par les développeurs Android.

Enfin, c’est l’environnement de développement Android Studio qui est majoritairement utilisé par les développeurs Android pour compiler leurs applications mobiles.

L'avènement du développement cross-platform

Les langages natifs nécessitent alors une de doubles expertises pour les développeurs. Il est également souhaitable d’éviter d’avoir à écrire du code source deux fois afin de réduire les coûts et temps de développement. C’est dans ce contexte complexe que des solutions cross-platform ont commencé à émerger dès la fin des années 2000.

En effet, le framework JavaScript React Native, développé par Meta (anciennement Facebook) en 2015, permet de construire une application fonctionnant sur iOS et Android.

C'est une aubaine pour les développeurs puisque React Native et les solutions similaires induisent ainsi plusieurs avantages notables :

  • Des temps de développement réduit,
  • Des ressources nécessaires moindres,
  • Une mise à jour synchronisée pour les deux systèmes d’exploitation.

React Native fait aujourd’hui partie des technologies cross-platform les plus populaires au monde mais il en existe d’autres tout aussi pertinentes. Il faudra surtout connaître ses besoins et ses prérequis techniques avant de faire un choix. En voici une sélection :

  • Apache Cordova développé en 2011 et écrit en JavaScript,
  • Xamarin développé en 2013 et écrit en C#,
  • Ionic développé en 2013 et écrit en JavaScript 
  • Flutter développé en 2017 et écrit en Dart.

Pour vous démontrer l’intérêt majeur d’une telle technologie, découvrons ensemble quelques exemples basiques de code source.

Le langage Swift pour iOS

Dans cet exemple de code Swift, nous créons une simple interface utilisateur avec un message de bienvenue.

Néanmoins, si nous souhaitons que notre application mobile, aussi basique soit-elle, puisse tourner également sur un téléphone Android, il nous faut développer la même chose à l’aide du langage natif Kotlin.

Le langage Kotlin pour Android 

Dans cet exemple de code Kotlin, nous affichons encore un message de bienvenue. Autrement dit, nous réalisons un traitement purement similaire à celui développé plus haut. 

Heureusement pour nous, une solution cross-platform, comme React Native, demande un code source unique, pour obtenir un rendu similaire sur les deux systèmes OS.

Remarque : Notez que, comme son nom l’indique, React Native est un framework dérivé de la librairie web frontend React. Ces deux technologies utilisent l’extension syntaxique au langage JavaScript « JSX », également développée par Meta.

Le framework React Native pour le développement cross-platform

Dans cet exemple de code React Native, nous utilisons des composants de base pour créer une interface qui fonctionne à la fois sur les systèmes iOS et Android. C'est la magie du cross-platform : un seul code qui existe, s'adapte et évolue sur plusieurs systèmes d'exploitation simultanément !

Ces exemples de code démontrent la différence entre le développement natif et le développement cross-platform.

Les codes natifs Swift et Kotlin nécessitent une connaissance spécifique de chaque plateforme. De son côté, React Native, grâce à sa nature cross-platform, simplifie le processus. Les développeurs peuvent alors utiliser une base de code pour les deux plateformes sans être expert avec d’autres langages que le JavaScript utilisé par React Native.

Avantages et limites du cross-platform

Malgré une promesse alléchante qui semble rendre obsolète les langages natifs, les solutions cross-platform présentent quelques inconvénients non négligeables.

  • Des performances moindres : Les applications natives ont généralement de meilleures performances car elles sont spécifiquement optimisées pour leur OS respectif.
  • Des fonctionnalités spécifiques non disponibles : Certaines fonctionnalités natives peuvent parfois ne pas être facilement accessibles. Elles peuvent même nécessiter des solutions de contournement lorsque l’on développe à l’aide d’une solution cross-platform comme React Native.

Pour illustrer ce dernier aspect, découvrons une implémentation basique consistant à donner à l’application mobile l’accès à une fonctionnalité matérielle spécifique. En l’occurrence, nous avons choisi de nous concentrer sur le moteur de vibration du smartphone. 

Le code source Swift

Une image contenant texte, capture d’écranDescription générée automatiquement

Cet exemple de code permet de faire vibrer un iPhone grâce à l'API native d'iOS qui permet d’accéder facilement et avec précision au moteur de vibration. 

Le code source Kotlin

Une image contenant texte, capture d’écranDescription générée automatiquement

Là encore, avec l'API native d'Android, on utilise le service de vibration avec des motifs de vibration plus ou moins complexes.

Le code source React Native

Une image contenant texte, capture d’écran, Police, carte de visiteDescription générée automatiquement

Comme vous pouvez le constater, avec React Native, le moteur de vibration reste accessible pour les deux systèmes d’exploitation mais il est moins flexible en termes de fonctionnalités avancées, comme la définition de motifs complexes.

Bien que React Native offre la possibilité d’accéder aux fonctionnalités matérielles du smartphone comme pour le faire vibrer, ces exemples de code démontrent que les options et la précision sont plus limitées en comparaison avec les APIs natives de Swift et Kotlin.

Dans le cadre de cas concrets spécifiques plus avancés, l’interaction avec des fonctionnalités matérielles plus évoluées pourrait nécessiter un développement natif.

C'est pour ces problématiques spécifiques ou avancées que le développement natif offre davantage de flexibilité et de performance. Notez néanmoins que pour la majorité des besoins courants des applications, React Native offre un réel équilibre entre portabilité, temps de développement et performance.

Pour conclure, les systèmes d’exploitation pour smartphone jouent un rôle crucial dans l’ère numérique actuelle. Dans les faits, le choix entre le développement natif et cross-platform doit surtout dépendre du projet à mener et des objectifs qui lui sont associés.

Pour autant, gardez à l’esprit qu’avec des technologies comme React Native, les frontières entre iOS et Android s'amenuisent. Ces puissantes solutions offrent aux développeurs et aux utilisateurs une expérience plus simple et accessible. Par ailleurs, les prérequis techniques et fonctionnels étant également amoindris, une plus vaste communauté peut s’adonner à la création d’application mobile.

Enfin, si cet article vous a motivé à construire votre propre solution pour smartphone iOS et Android, découvrez aussi nos conseils pour créer une application de A à Z ainsi que nos 10 astuces pour créer la meilleure application mobile !

Nos autres catégories
Notre newsletter tous les mois :
Je m'abonne
Merci ! C'est dans la boîte :)
Oops! Something went wrong while submitting the form.
Partager sur :
Nos autres catégories
Notre newsletter tous les mois :
Je m'abonne
Merci ! C'est dans la boîte :)
Oops! Something went wrong while submitting the form.
Partager sur :

Nos experts vous parlent
Le décodeur

Chat application mobile : Intercom, Crisp, Brevo
1/1/2021

Dans le monde numérique moderne, l'intégration d'un chat dans les applications mobiles joue un rôle crucial pour renforcer l'engagement et la satisfaction des utilisateurs.

Avec des solutions comme Intercom, Crisp, et Brevo, offrir un support client en temps réel et faciliter la communication devient non seulement possible, mais aussi efficace. 

Que vous soyez un développeur chevronné ou simplement curieux de comprendre comment ces systèmes s'intègrent dans les applications mobiles, cet article vous guidera à travers les avantages, les techniques d'intégration, et les meilleures pratiques pour utiliser le chat mobile. 

En mettant l'accent sur des applications de messagerie adaptées aux besoins des utilisateurs et des entreprises, nous explorons comment ces outils transforment l'interaction numérique, rendant chaque conversation plus significative.

Pourquoi intégrer un chat dans votre application mobile ?

L'intégration d'un système de chat dans une application mobile n'est pas seulement une fonctionnalité supplémentaire ; c'est une stratégie essentielle pour améliorer l'interaction utilisateur et offrir un support client sans précédent. Voici pourquoi l'ajout d'un chat à votre application mobile peut être un véritable atout pour votre entreprise.

Amélioration de l'expérience utilisateur

Le chat en direct dans les applications mobiles crée une ligne de communication instantanée entre les utilisateurs et votre entreprise. Cela signifie que les questions, préoccupations et commentaires peuvent être adressés rapidement, améliorant ainsi l'expérience utilisateur (UX). Une réponse rapide peut transformer une expérience utilisateur médiocre en une expérience positive, augmentant la satisfaction et la fidélité des clients.

Support client en temps réel

Avec l'intégration de solutions de chat telles qu'Intercom, Crisp ou Brevo, vous offrez un support client en temps réel directement depuis l'application. Cela élimine le besoin pour les utilisateurs de quitter l'application pour obtenir de l'aide. Un accès facile au support client non seulement résout les problèmes plus rapidement mais renforce également la confiance dans votre marque.

Engagement accru (h3)

Les systèmes de chat permettent une communication bidirectionnelle qui peut être utilisée pour engager les utilisateurs. Que ce soit par des notifications push personnalisées, des offres spéciales ou des sondages, le chat peut servir de puissant outil d'engagement. En maintenant les utilisateurs engagés, vous augmentez les chances qu'ils utilisent votre application plus fréquemment et pour de plus longues périodes.

Collecte de retours utilisateurs

Le chat offre une plateforme pour recueillir des commentaires précieux des utilisateurs en temps réel. Ces retours peuvent être utilisés pour améliorer l'application, corriger des bugs, et développer de nouvelles fonctionnalités qui répondent mieux aux besoins des utilisateurs. Une meilleure compréhension des désirs des utilisateurs conduit à une meilleure prise de décision et à des mises à jour de l'application plus pertinentes.

Avantage concurrentiel

Dans un marché saturé, offrir un chat intégré dans votre application peut vous démarquer de la concurrence. Cela montre que vous êtes engagé à fournir un excellent service client et à faciliter la communication. Une telle fonctionnalité peut être un facteur décisif pour les utilisateurs lorsqu'ils choisissent entre votre application et celle d'un concurrent.

En intégrant un chat dans votre application mobile, vous ne faites pas que suivre une tendance ; vous investissez dans une meilleure expérience utilisateur, un support client amélioré, et une stratégie d'engagement plus forte. Ces éléments sont cruciaux pour le succès à long terme de toute application mobile.

Solutions de chat pour applications mobiles : vue d'ensemble

L'adoption de solutions de chat pour applications mobiles est une étape cruciale vers l'amélioration de la communication et de l'engagement des utilisateurs. Ces solutions, telles qu'Intercom, Crisp, et Brevo, offrent une variété de fonctionnalités conçues pour répondre aux besoins des entreprises et de leurs utilisateurs. Voici une vue d'ensemble de ce que ces solutions de chat peuvent offrir et comment elles se comparent.

Intercom

Intercom est largement reconnu pour sa plateforme de communication client intégrée, qui facilite le chat en direct, l'engagement des utilisateurs, et le support client. Son intégration dans les applications mobiles permet une communication fluide entre les utilisateurs et les représentants du service client, avec des fonctionnalités telles que les réponses automatisées et la segmentation des utilisateurs. Intercom se distingue par sa capacité à offrir des interactions personnalisées à grande échelle.

Crisp

Crisp propose une solution de chat multicanal qui supporte non seulement le chat en direct mais aussi le courrier électronique, les SMS, et les réseaux sociaux. Ce qui le rend particulièrement attractif pour les applications mobiles, c'est sa simplicité d'utilisation et sa capacité à unifier toutes les communications client en un seul lieu. Crisp est idéal pour les entreprises cherchant à offrir une expérience utilisateur cohérente à travers différents canaux.

Brevo

Brevo est une solution de chat mobile axée sur l'automatisation et l'intelligence artificielle. Elle permet aux entreprises de créer des bots de chat qui peuvent gérer des conversations de base, orienter les utilisateurs vers les ressources appropriées, et même effectuer des tâches simples. L'intégration de Brevo dans une application mobile peut considérablement réduire la charge de travail du service client tout en maintenant les utilisateurs engagés.

Comparaison avec les applications de chat gratuites

Bien que les applications de chat gratuites comme WhatsApp ou Facebook Messenger offrent des moyens de communication efficaces, elles ne sont pas toujours idéales pour un usage professionnel en raison de leur manque de personnalisation et de contrôle. En comparaison, les solutions de chat payantes offrent des fonctionnalités avancées telles que l'analyse des données utilisateur, l'intégration avec d'autres outils professionnels, et un haut degré de personnalisation.

Compatibilité avec Android et iOS

Une considération importante lors du choix d'une solution de chat pour une application mobile est sa compatibilité avec les systèmes d'exploitation Android et iOS. Intercom, Crisp, et Brevo offrent tous une excellente compatibilité, garantissant que les utilisateurs bénéficient d'une expérience de chat fluide, indépendamment de leur appareil.

Intégration avec des comptes existants

La possibilité d'intégrer des solutions de chat avec des comptes existants, tels que les comptes Google ou Facebook, peut simplifier le processus de connexion pour les utilisateurs et améliorer l'expérience utilisateur. Ces intégrations peuvent également fournir aux entreprises des informations précieuses sur les préférences et les comportements des utilisateurs.

En résumé, choisir la solution de chat appropriée pour votre application mobile dépend de plusieurs facteurs, y compris les besoins spécifiques de votre entreprise, le niveau de personnalisation souhaité, et les préférences de vos utilisateurs. En offrant une vue d'ensemble des options disponibles, cette section aide les développeurs et les décideurs à naviguer dans le paysage des applications de chat et à choisir celle qui convient le mieux à leur application mobile.

Intégration Technique d'un Système de Chat

L'intégration technique d'un système de chat dans une application mobile est une étape cruciale qui nécessite une attention particulière pour assurer une expérience utilisateur fluide et efficace. Cette section aborde les différentes méthodes d'intégration, en mettant l'accent sur l'intégration en webview, les solutions natives, et l'utilisation des SDK.

Intégration en webview

L'utilisation d'une webview dans React Native permet d'intégrer facilement un chat web externe dans votre application en encapsulant la page web du chat dans un composant WebView.

Exemple de code React Native (JSX) pour intégrer une webview :

Une image contenant texte, capture d’écran, Police, logicielDescription générée automatiquement

Cet exemple montre comment charger une interface de chat web dans un composant WebView de React Native, permettant aux utilisateurs d'interagir avec le chat directement dans l'application.

Solutions natives via des SDK

Pour une intégration plus profonde et native, vous pouvez utiliser les SDK fournis par des plateformes de chat comme Intercom, Crisp, ou Brevo. Ces SDK nécessitent souvent l'utilisation de modules natifs ou de wrappers disponibles pour React Native.

Exemple d'intégration du SDK Intercom pour React Native :

Une image contenant texte, capture d’écran, PoliceDescription générée automatiquement

Cet exemple montre comment initialiser et enregistrer un utilisateur avec Intercom dans votre application React Native, permettant une interaction native avec le service de chat.

Utilisation des SDK

Les SDK spécifiques à chaque plateforme de chat, tels que ceux pour Crisp ou Brevo, peuvent être intégrés à React Native à travers des packages spécifiques ou des ponts natifs.

Exemple d'intégration générique d'un SDK:

Une image contenant texte, capture d’écran, PoliceDescription générée automatiquement

Bien que cet exemple soit générique, il illustre comment un SDK de chat pourrait être initialisé dans React Native. Consultez la documentation spécifique du SDK pour des instructions détaillées.

Considérations importantes

  • Sécurité et Confidentialité : Veillez à ce que le chat intégré offre un chiffrement de bout en bout et respecte les réglementations de protection de la vie privée des utilisateurs.
  • Compatibilité : Testez l'intégration sur les différentes versions d'Android et iOS pour assurer une compatibilité et une performance optimales.
  • Personnalisation : Utilisez les options de personnalisation fournies par le SDK pour harmoniser l'interface de chat avec le design de votre application.

En intégrant un système de chat dans votre application React Native, vous offrez une valeur ajoutée significative à vos utilisateurs en facilitant la communication et en fournissant un support en temps réel. Les exemples de code fournis devraient vous aider à démarrer avec l'intégration, mais assurez-vous de consulter la documentation de chaque SDK pour des détails spécifiques à votre mise en œuvre.

En conclusion, l'intégration d'un système de chat dans une application mobile est une démarche stratégique essentielle pour améliorer l'engagement des utilisateurs, fournir un support client en temps réel, et recueillir des feedbacks précieux. Avec des solutions de chat avancées comme Intercom, Crisp, et Brevo, les développeurs disposent d'outils puissants pour incorporer facilement ces fonctionnalités dans leurs applications mobiles, qu'elles soient développées avec React Native ou d'autres frameworks.

L'utilisation de Webviews, l'intégration de SDK spécifiques, ou encore le déploiement de solutions natives, offre une flexibilité permettant de choisir l'approche qui convient le mieux aux besoins spécifiques de l'application et à son public cible. Chaque méthode d'intégration présente des avantages uniques, allant de la facilité de mise en œuvre à la personnalisation poussée, en passant par l'optimisation de l'expérience utilisateur.

Il est crucial, cependant, de ne pas perdre de vue l'importance de la sécurité, de la confidentialité, et de la compatibilité lors de l'intégration de ces systèmes de chat. Ces aspects sont fondamentaux pour maintenir la confiance des utilisateurs et assurer le succès à long terme de l'application.

L'avenir des applications mobiles réside dans la capacité à créer des expériences utilisateur riches et interactives. L'intégration d'un système de chat répond parfaitement à cette exigence, en transformant les interactions numériques en conversations significatives et engageantes. En tant que développeurs et décideurs, il est de notre responsabilité de tirer parti de ces technologies pour construire des applications qui non seulement répondent aux besoins actuels des utilisateurs mais anticipent également leurs attentes futures.

Que vous soyez un développeur expérimenté ou un entrepreneur novateur, intégrer un système de chat dans votre application mobile est un pas en avant vers la création d'une expérience utilisateur véritablement dynamique et connectée. Les possibilités sont vastes, et avec les bonnes pratiques et les outils appropriés, votre application peut devenir un espace où les utilisateurs se sentent écoutés, soutenus, et engagés.

Git : initiation, merge vs rebase, démo
22/6/2023

Origine


Git a été inventé et développé par Linus Torvalds en 2005. Il s’agit un logiciel libre et gratuit permettant aux développeurs de gérer les changements apportés au code au fil du temps. Linus Torvalds c’est aussi le petit génie qui est à l’origine du noyau Linux qu’il a commencé en 1991, donc bien avant Git.


Linux c’est un projet plutôt conséquent et il a donc dû nécessiter l’usage d’un outil de gestion de version. Cet outil, à l’époque, c’est BitKeeper. Le problème de BitKeeper, c’est qu’il s’agit d’un logiciel propriétaire et que toute la communauté qui gravite autour de Linux, elle n’aime pas vraiment les logiciels propriétaires. Alors que BitKeeper n’est déjà pas totalement apprécié par la communauté Linux, ils vont faire une annonce qui va déclencher la colère de toute cette communauté et surtout de Linus Torvalds. Ils vont cesser, du jour au lendemain, d’être gratuit. C’est à ce moment précis que Linus Torvalds décide de développer lui même son propre système de gestion de version du code source et tout comme Linux, ce système sera libre et gratuit.


Système de contrôle de version (VCS)


Git est donc un système de contrôle de version, il permet tout simplement de suivre l’évolution du code au fil du temps, à l’aide de branche, de fichiers et d’opérations sur ces fichiers.


Git est structuré comme suit :

  • on y retrouve des fichiers (le code source)
  • des branches (correspondant à une arborescence de fichiers)
  • et des opérations pour faire évoluer les fichiers dans les branches


Grâce à ces opérations, git permet de savoir qui a touché à quel fichier, à quel moment et comment.


GitHub, GitLab, Bitbucket, etc.


Git est un logiciel qui permet de sauvegarder et de gérer localement l’évolution du code source au fil du temps. GitHub, GitLab, Bitbucket, etc. sont des plateformes (web) qui se servent du logiciel git pour gérer le code source. Les dépôts ne sont alors plus gérer localement mais sur des serveurs distants et permettent donc notamment la collaboration avec plusieurs personnes. Ces plateformes proposent également de nombreuses fonctionnalités de gestion de projets et d’équipes (wiki, affectations de tâches, suivi des problèmes, roadmap, statistiques, etc.).

Les bases

Git Flow


Git Flow est une organisation de travail basé sur la capacité de Git à gérer des branches. Par défaut il existe une branche principale qui s’appelle main (anecdote : anciennement master, ce nom par défaut a changé pour des raisons culturelles, ne plus assimiler la notion de master/slave à l’industrie du développement face aux nombreux cas de racisme dans le monde). Il existe une deuxième branche que nous allons créer et qui sera également considérée comme principale, il s’agit de la branche develop.

Nous avons donc 2 branches principales :

  • main (anciennement master), qui représente le code source utilisé sur la production
  • develop, qui contient les dernières fonctionnalités dont la phase de développement est terminée

Tout au long du développement du projet, de nombreuses branches seront créées lors du développement des fonctionnalités et des corrections diverses. Ces branches respecteront des conventions de nommages comme suit :

  • feature/*, pour les branches de fonctionnalités
  • hotfix/* ou bugfix/*, pour les branches de corrections
  • refactor/*, pour améliorer la qualité du code

Conventional Commits


Conventional Commits est une spécification dont le but est d’améliorer la lisibilité des commits et l’historique des modifications du code source. À l’aide de ces conventions on peut identifier immédiatement le type, le contexte et l’objectif des modifications apportées au code sur un commit (nota bene : Cela permet aussi d’être compris par des outils automatisé pour générer de la documentation en autres).

Format Conventional Commits

Les types de commits les plus utilisés sont :

  • feat, développement d’une feature
  • fix, correction d’un bug
  • refactor, amélioration du code
  • test, ajout ou mise à jour de tests
  • chore, tâche technique non assimilée à une feature
  • remove, revert, style, ci, docs, etc.
Exemples de commits suivant la convention

Workflow : merge vs rebase


Avec Git Flow on travaille donc sur des branches partant de develop (ou autre) et une fois le travail terminé on met à jour develop pour qu’il ai connaissance des modifications apportées.

Il existe plusieurs façons de ramener les modifications d’une branche vers une autre. On peut utiliser la politique de merge ou bien la politique de rebase. Ces deux méthodes ont des avantages et des inconvénients.


Politique de merge


Lorsque le travail de développement est terminé sur une branche (de feature, de refactor, etc.), la branche contient un certain nombre d’opération qui n’existent pas sur la branche d’origine. Le principe de la politique de merge est simple : récupérer les modifications faites sur une branche et les ramener sur une autre branche qui n’a pas connaissance de ces modifications. Ces modifications sont ramenées telles quelles.

Avantages :

  • traçabilité totale, l’historique du code source correspond totalement à ce qui a été fait
  • résolution des conflits en une seule fois (peut être un inconvénient dans certains cas)


Inconvénients :

  • historique du code source vite pollué par des opérations inutiles “wip” ou des opérations qui s’annulent
  • historique peu fiable et difficile à debugger
  • résolution des conflits en une seule fois (peut être un avantage dans certains cas)


Politique de rebase


Lorsque le travail de développement est terminé sur une branche (de feature, de refactor, etc.), la branche a donc un certain nombre d’opération qui diverge de la branche principale. Lorsqu’on suit une politique de rebase, notre objectif va être de nettoyer ces opérations en les réécrivant jusqu’à avoir le nombre minimum d’opérations pertinentes.  

Avantages :

  • historique du code source linéaire et lisible qui peut servir de documentation
  • messages de commit clairs et respectant les conventions, plus de “wip”
  • plus de commits qui s’annulent et donc une fiabilité de l’historique
  • facilité pour revenir en arrière et trouver l’origin d’un bug car l’historique n’est pas pollué
  • facilité pour revoir une feature complète, pour la modifier ou l’annuler
  • résolution des conflits opération par opération (peut être un inconvénient dans certains cas)


Inconvénients :

  • demande une grande rigueur car on réécrit en permanence l’historique
  • demande une bonne communication ou des règles précises si on travaille en équipe sur la même branche
  • la réduction d’une nombre d’opération au minimum est parfois trop extrême et atténue la clarté du contexte dans certains cas
  • résolution des conflits opération par opération (peut être un avantage dans certains cas)


Nettoyage avec rebase Interactif


Avec la politique de rebase on réécrit l’historique des opérations faites sur le code source. Pour cela on peut utiliser des outils comme GitKraken ou autre, mais on peut également utiliser la commande git rebase interactive.


Les rebases réécrivent l’historique et donc écrasent totalement ce qui existait avant. En équipe il est donc indispensable de bien communiquer, de bien se mettre à jour et de prendre le soin de ne pas travailler sur la même branche. Si ces règles ne sont pas respecter, les pertes de code sont plus que probables !


Le processus classique de développement pour ne pas rencontrer de problèmes et profiter de la puissance du rebase est le suivant (en plus  :

  • travailler en local en faisant autant d’opérations que nécessaires
  • lorsque le travail est terminé et que tout fonctionne comme il faut, créer une pull request et demander une revue de code en gardant l’historique de code tel qu’il est pour garder du contexte et donner à l’auteur de la revue de code un moyen de comprendre le cheminement de pensé qui a amené à ces modifications
  • une fois la revue de code terminée et acceptée, il faut utiliser le rebase interactive pour nettoyer le code et ne garder que les opérations nécessaires
  • intégrer les modifications sur la branche d’origine et supprimer la branche créée précédemment

🧑💻 Démonstration


Supposons nous avons un dépôt git avec une seule branche main et un seul fichier hello.ts qui contient une fonction “Hello World !” comme suit :

Maintenant, nous devons développer la fonctionnalité “Good Bye World!”.

Pour cela, nous allons donc commencer par créer une branche qui respecte les conventions de nommage : git checkout -b feature/good-bye
Puis, nous allons créer un fichier good-bye.ts et écrire la fonction suivante :

Et nous allons créer un commit contenant cette fonctionnalité : git commit -m “feat: good bye world”.


Vous l’avez peut-être remarqué, une erreur s’est glissée dans la fonction, nous allons donc faire un commit pour la corriger :

Avec le commit suivant : git commit -m “fix(good-bye): typo”.

Nous avons donc 2 commits alors qu’il serait plus pertinent d’en avoir qu’un seul. Nous allons donc utiliser le git rebase interactive pour réécrire l’historique des modifications.

Pour initialiser le rebase interactive on utilise la commande suivante : git rebase interactive HEAD~2

Cette commande va ouvrir l’interface suivante :

Sur cette interface on voit les 2 derniers commits de mon dépôt git (parce qu’on a utilisé HEAD~2). On y retrouve également une documentation des commandes qu’on peut utiliser devant l’identifiant de chaque commit.


Dans notre cas, on veut fusionner les modifications du deuxième commit avec le premier commit. C’est donc la commande fixup qui nous intéresse, nous allons donc remplacer pick devant le commit fix(good-bye): typo par fixup.


On enregistre et on obtient l’historique suivant (un seul commit) :

7f077f4 (HEAD -> feature/good-bye-world) feat: good bye world

Liens utiles

Test Driven Development (TDD) : Guide pour un Développement Efficace
21/9/2023

L'origine


Le Test-Driven Development plus communément appelé TDD n'a pas été inventé par une seule personne mais par plusieurs développeurs. Kent Beck est souvent la personne la plus affiliée au TDD parce qu'il est celui qui l'a popularisé lors de ses travaux sur la méthodologie Extreme Programming à la fin des années 90. Néanmoins il est important de rappeler qu'il n'est pas le créateur de l'outil qu'est le TDD, il a été mis en place pour tout un tas de personne, dont notamment Martin Fowler (co-auteur du Manifeste Agile) ou encore Ward Cunningham et Ron Jeffries qui ont fondé l'Extreme Programming avec Kent Beck.


Un outil de travail


L'outil


Le TDD est un outil de travail qui permet au développeur de coder en étant guidé par les tests. Il permet d'avancer étape par étape, petit pas par petit pas, pour avancer vers une solution toujours plus fiable.


Cette solution plus fiable est notamment due à sa forte proximité avec les principes SOLID. En effet, le TDD facilite la mise en place des principes SOLID. En écrivant d'abord des tests, il est plus naturel de concevoir un code simple et cohérent qui respecte les principes tels que l'encapsulation, le découplage, la gestion des dépendances et la séparation des responsabilités. On se retrouve plus naturellement avec des modules indépendants et l'injection de dépendances, ce qui conduit à du code plus propre.


Le TDD et les principes SOLID vont donc de pair pour une conception logicielle de qualité.



  1. Nous avons une première phase (rouge sur le schéma) où nous devons écrire un test qui échoue, basé sur une spécification. NB : on n'écrit pas de code de production (code final) tant que le test n'est pas en échec.
  2. La deuxième phase (verte sur le schéma) consiste à faire passer le test en succès en écrivant du code de production et tout en restant le plus simple possible. NB : on écrit uniquement le code nécessaire pour faire passer le test et sans retourner dans le code du test.
  3. La dernière phase (bleue sur le schéma) concerne le refactoring. On met à jour le code en appliquant les bonnes pratiques, le clean code, etc. Une fois que le refactoring est fait, si les tests passent toujours, on conserve le refactor et on passe aux prochaines spécifications, sinon, on annule le refactor et on essaye autre chose. NB : ne doit jamais effectuer de refactoring dans les autres phases, seulement ici.


L'approche TDD est un développement itératif et incremental qui met l'accent sur la qualité du code.


Le manifeste


Le TDD respecte certains principes qui sont :


  • Baby steps instead of large-scale changes

On avance petit pas par petit pas pour avoir une boucle de feedback rapide et régulière.


  • Continuous refactoring instead of late quality improvements

On améliore le code en continue, on s'en occupe tout de suite parce qu'un refactor annoncé pour plus tard n'arrive finalement en général jamais.


  • Evolutionary design instead of big design up front

On développe ce qui est nécessaire et suffisant et on évolue progressivement.


  • Executable documentation instead of static documents

Les tests mis en place pendant le TDD sont en réalité une documentation executable. L'idée est de lier la documentation avec le code pour s'assurer qu'elle est bien à jour et maintenue.


  • Minimalist code instead of gold-plated solution

Un code simple et qui fonctionne plutôt qu'une solution surdimensionnées avec un niveau de complexité bien trop élevé et pas nécessaire.




Le test propre

Given When Then


L'approche Given When Then est basée sur une convention développée dans le cadre du Behaviour-Driven Development autrement appelé BDD. Il s'agit d'une approche de développement axée sur la collaboration et la spécification du comportement à travers ds scénarios clairs et compréhensibles.


En utilisant cette convention on divise le test en trois parties :

  1. Given, la condition préalable au test
  2. When, l'exécution du système testé
  3. Then, le comportement attendu


Exemple : Given user is not logged in When user logs in Then user is logged in successfully


Should When


L'approche Should When est une convention de nommage facile à lire et plus largement utilisée.


En utilisant cette convention on divise le test en deux parties :

  1. When, la condition préalable au test
  2. Should, le comportement attendu


Exemple : Should have user logged in When user logs in


Arrange Act Assert


Le modèle Arrange Act Assert autrement appelé AAA est un pattern descriptif et révélateur des intentions pour structurer le test.


Le test est alors organisé de la manière suivante :

  1. La partie Arrange contient la logique de configuration du test. C'est ici qu'on initialise le test.
  2. La partie Act execute le système que l'on souhaite tester. C'est ici qu'on fait l'appel d'une fonction, d'un composant, d'un call API, etc.
  3. La partie Assert, vérifie que le système testé se comporte comme prévu. C'est ici qu'on vérifie que le résultat obtenu correspond au résultat attendu.


Exemple :




F.I.R.S.T.


Le principe F.I.R.S.T. est un ensemble de principes qui définissent les caractéristiques d'un test propre et de qualité.


Ces caractéristiques sont les suivantes :

  • Fast, un test doit être rapide et efficace de manière à pouvoir être exécuté fréquemment pour avoir un feedback régulier
  • Independent, les tests doivent être indépendants les uns des autres afin d'être exécutable individuellement et efficacement
  • Repeatable, un test doit être répétable dans n'importe quel environnement et à tout moment
  • Self-Validating, les tests doivent retourner un succès ou un échec afin de vérifier lui même si l'exécution du test a réussi ou échoué sans évaluation manuelle
  • Timely, les tests doivent être écrit avant ou en même temps que le code de production. ils doivent être maintenus et exécutés régulièrement


Quand l'utiliser ?


Quand ne pas l'utiliser plutôt !


Il n'est pas nécessaire et pas utile de faire du TDD quand on a pas de spécifications, quand les tests n'apportent rien, quand les tests sont trop lents, quand il n'y a pas de logique.


La démo


L'incontournable Fizz Buzz


Le Fizz Buzz est un exercice populaire qui permet d'appréhender la méthode TDD. Ce n'est qu'un échantillon et qu'un début de la méthode, mais ça reste intéressant.


Les spécifications sont les suivantes :

  • On commence à compter à partir de 1 jusqu'à 100
  • Lorsqu'on rencontre un nombre divisible par 3, on retourne "Fizz"
  • Lorsqu'on rencontre un nombre divisible par 5, on retourne "Buzz"
  • Lorsqu'on rencontre un nombre divisible par 3 et par 5, on retourne "Fizz-Buzz"


Nous allons utiliser le TypeScript pour mettre en place cet algorithme et le tester.


Première spécification


On créé un fichier test fizz-buzz.test.ts et on créé notre premier test qui va gérer la spécification où on teste le nombre 1.





Ici, le test ne passe pas parce qu'on a pas encore créé la fonction fizzBuzz() et encore moins l'algorithme associé. Nous sommes donc à la première phase du TDD, la phase rouge, celle où on écrit un test qui échoue.


On va maintenant passer à la deuxième phase du TDD, celle où on va faire passer le test au vert. Pour cela, on va créer le fichier fizz-buzz.ts et écrire le code permettant de gérer notre cas de spécification.




Ici, on pourrait avoir tendance à faire un return String(n) directement, mais TDD nous dit de commence par écrire le code le plus simple possible pour faire passer le test au vert, et en réalité le plus simple et rapide et de tout simplement retourner 1 directement.


On va passer au prochain test qui est de tester l'input 2.



Le test échoue parce qu'on a pas encore géré ce cas dans notre fonction. On retourne donc dans notre fonction et on essaye de résoudre ce cas de la manière la plus simple et rapide.




Ici, encore une fois, le plus rapide est de retourner 2 si on a 2 en input.


Maintenant on arrive à la troisième et dernière phase du TDD, celle du refactor. En effet, actuellement nos tests passent avec succès, le code est simple, mais il pourrait l'être encore plus en appliquant de bonnes pratiques.


On va donc revenir sur notre fonction fizzBuzz() sans modifier les tests.




Notre fonction est maintenant simple, propre et concise et les tests sont toujours verts. Notre refactor est donc réussit, on peut passer à la prochaine spécification.


Deuxième spécification


Nous devons maintenant faire en sorte de retourner Fizz si l'input est divisible par 3.



Le test échoue, on va maintenant gérer le cas du Fizz dans la fonction.




Le code le plus simple pour retourner  Fizz quand on a 3 et de tester si n === 3.


On va maintenant gérer un deuxième cas où on a un nombre divisible par 3.




Le test échoue, on met à jour le code.




Le code le plus simple pour retourner Fizzquand on a 3 ou 6 et de faire un ||, mais on se rend bien compte qu'on peut améliorer le code en utilisant le modulo de 3. Les tests sont tous verts, donc on peut se permettre de passer à la phase de refactor en modifiant uniquement le code de la production.



Refactor terminé, tous les tests sont verts, on peut passer à la prochaine spécification.


Troisième spécification


Nous devons maintenant faire en sorte de retourner Buzz si l'input est divisible par 5.


On va aller un peu plus vite, mais le procédé est le même, on va d'abord faire un test avec un input 5 puis 10, puis refactor.




Dernière spécification


Nous devons maintenant faire en sorte de retourner Fizz-Buzz si l'input est divisible par 3 et par 5.


Comme pour les spécifications précédentes, on va faire un test avec un input 15 puis 30 et enfin refactor.


Et voilà !


Le mot de la fin


Stop aux amalgames ! Le TDD n'est pas un outil pour avoir une bonne couverture de code avec les tests, ce n'est pas simplement "faire des tests". Le TDD est un outil dont le but est de guider le développeur vers un objectif. Il permet de donner un feedback régulier afin de s'assurer qu'on est toujours sur la bonne voie. Il faut le voir comme un GPS, qui nous donne des directions à suivre (tourner à droite, aller tout droit pendant 2km, etc.) jusqu'à atteindre un objectif.


Les dédicaces


Échangeons
sur votre projet !

Nous contacter

Simulateur

Bienvenue dans le
simulateur d’estimation

Sélectionnez
vos besoins

Sélectionnez un ou plusieurs choix

Définissez les
fonctionnalités

Sélectionnez un ou plusieurs choix

Dernière
étape !

Renseignez votre adresse mail pour recevoir l’estimation !
Obtenez l’estimation
Précédent
Suivant

Bravo ! Vous avez terminé
l’estimation de votre future app !

Vous recevrez dans votre boite mail l’estimation personnalisé. Une estimation vous offre la possibilité de vous projeter dans un budget, vous permettant ainsi de planifier en toute confiance. Néanmoins, chez Yield, nous adoptons une approche agile, prêts à remettre en question et ajuster nos évaluations en fonction de l'évolution de vos besoins et des spécificités de votre projet.
Retour au site
Oops! Something went wrong while submitting the form.