Vous avez décidé de lancer la refonte de votre application mobile Android (sûrement pour une de ces raisons) et vous êtes en train de lancer le projet. Nous vous avons listé dans cet article les 3 erreurs à éviter ?.

Jeter le code existant

La tentation est grande quand on se décide à faire une refonte de repartir à zéro et de redévelopper toute l'application. L'occasion de reposer des bases saines, d'intégrer les dernières technos à la mode et d'occuper les développeurs pour de nombreux mois ! Cependant, cette solution séduisante au premier abord ne va pas sans son lot d'inconvénients :

• En repartant de 0, on limite fortement voire on stoppe complètement le développement du produit existant.
• On perd également toute l'information contenue dans le code existant : corrections de nombreux bugs, règles et comportement non écrits...
• On risque de ne pas corriger les problèmes organisationnels qui ont mené à cette situation : manque de documentation, manque de rigueur dans le développement, habitude de privilégier la sortie de nouvelles features au détriment de la qualité...
• On risque enfin de dépasser le budget : en effet, connaissant parfaitement le produit et les défauts de la base de code, le risque est grand pour l'équipe de sous-estimer le temps de la refonte (d'un facteur bien pire que pour les estimations habituelles ?)

Dans la plupart des cas, il vaut mieux repartir du code existant. Voir aussi cet excellent article pour plus de détails.

Ne pas avoir d'indicateur pour piloter la refonte

Comme on l'a vu dans l'article précédent, plusieurs raisons peuvent avoir déclenché cette refonte. Il y a donc des éléments de l'application ou du code que l'on souhaite améliorer.

Il faut également avoir en tête que la refonte peut s'étaler sur un temps long, probablement plusieurs mois. Il est donc intéressant de mettre en place des indicateurs pour suivre l'avancement de la refonte.

On pense par exemple :

• Au temps de build incrémental
• Au retard pris sur les tickets dus à des problèmes d'architecture (et plus généralement la célérité)
• À la couverture de test

Cela peut aussi être des indicateurs d'avancement de la refonte comme :

• Le nombre d'écrans qui ont été refaits
• Le nombre de tickets réalisés sur la totalité des tickets de refonte

Il est surtout intéressant de vérifier que la refonte a bien généré les effets escomptés.

Si on cherche à améliorer le temps de build incrémental, pourquoi ne pas mettre en place un protocole de test pour vérifier que les performances évoluent dans le bon sens ? Bonne nouvelle, c'est prévu par le framework ! De même dans le cas d'une refonte UI, on suivra de près la note du store et le NPS.

Ne pas avoir de plan

Avant de s'engager dans la refonte de la totalité de l'application, il semble nécessaire d'avoir une idée de l'architecture cible. L'idée est également de lister les points douloureux liés à la base de code existante.

Idéalement, on peut prototyper la nouvelle architecture sur une nouvelle feature relativement indépendante de l'existant. On peut alors valider une architecture cible sur du code directement utile au produit, et donc en perdant le minimum de ressources.

S'il n'y a pas de telles features dans le backlog, on peut valider l'architecture sur une feature existante en la transformant vers l'architecture cible.

Enfin dans certains cas où l'architecture cible est très éloignée de la base de code actuelle, on peut réaliser un POC, c'est-à-dire une application aussi vide que possible mais où tous les éléments sont là (écrans, module de données, module domaine...). Cela permet de créer la discussion au sein de l'équipe (chacun peut proposer des patches, le but étant d'aligner l'équipe sur une série de standard de qualité) et de s'affranchir complètement des compromis de l'architecture existante.