Les clients et les prospects de BAM se posent beaucoup de questions sur la refonte d'application, c'est pourquoi j'ai décidé de démarrer une série d'articles sur cette thématique.

Entre bugs qui s'accumulent et UI vieillissante, vous vous posez la question de savoir s'il est opportun de démarrer une refonte ?

Voici donc quelques signes qui montrent qu'une refonte est nécessaire et ce qu'elle peut vous apporter. Et pour aider les personnes moins tech à prendre du recul sur certains points, je vous propose une analogie avec la rénovation d'un logement.

1. La base de code devient difficilement maintenable

Les symptômes sont connus : les bugs et les régressions s'enchaînent, la célérité diminue. Les nombreux "points qualité" et "Unit Test Afternoon" ne suffisent plus à contenir ces signes. Il est probablement temps d'entreprendre une véritable refonte technique.

De même que quand un logement vieilli on passe davantage de temps à l'entretenir et que les réparations de fortune ne durent pas dans le temps, on gagnerait à le rénover plus profondément et repartir sur des bases (plomberie, électricité...) saines.

2. L'UI et l'UX ne sont plus au goût du jour ?

Vous souhaitez revoir le thème de couleur, introduire ou faire évoluer le Design System ? C'est peut-être le moment de refondre l'application plus en profondeur. Repartir d'une feuille blanche sur le design vous permettra de moderniser l'application et d'optimiser le parcours utilisateur. Bien souvent cette refonte UI s'accompagne d'une refonte technique comme vue au point précédent.

On comprend bien qu'il est plus facile de revoir la décoration et l'habitabilité d'un logement au cours d'une rénovation profonde que si l'on se contente de passer un coup de peinture fraîche.

3. Une nouvelle équipe reprend le projet

Lorsqu'une nouvelle équipe récupère une base de code qu'elle ne maîtrise pas, elle a souvent tendance à dénigrer le code existant et à vouloir repartir de zéro. Ce n'est probablement pas une bonne idée, mais en s'appuyant sur les problèmes relevés on peut déclencher une refonte progressive de l'application : faire évoluer l'application vers une architecture cible de manière progressive, en gardant le code de l'application déployable à tout moment.

De même, la rénovation d'un bien immobilier a souvent lieu avec un nouveau propriétaire, moins à même de s'accommoder des défauts d'aménagement de l'existant.

4. Les technologies utilisées sont obsolètes

Toujours coincé avec les librairies RxJava 1 ou EventBus ? Ce type de bibliothèques étant souvent au c?ur de l'architecture de l'application, s'en passer nécessite une refonte vers une nouvelle architecture plus actuelle.

Notons aussi que si certaines technologies ne sont pas obsolètes à un instant T on sait qu'elles vont le devenir dans le futur. Ainsi, les jours des Fragments et des vues natives d'Android sont probablement comptés à moyen terme, puisque Google pousse maintenant le framework UI Jetpack Compose.

Pour continuer l'analogie avec les logements, il vaut mieux ne pas installer une nouvelle chaudière au fioul lors de votre rénovation même si c'est techniquement et légalement toujours possible.

5. On veut modulariser la base de code

Poussée par l'optimisation des temps de compilation et certaines features (dynamic features, instant apps) la modularisation d'application Android est un sujet à la mode dans le monde Android. Il s'agit de découper l'application en plusieurs modules ayant des liens de dépendance clairement définis. Cela permet d'augmenter les performances de compilation quand les développeurs travaillent dessus, ou bien facilite l'augmentation de la taille de l'équipe en évitant les conflits entre plusieurs feature teams.

Attention, la migration d'une base de code monolithique existante vers une architecture plus modulaire n'est pas forcément une tâche facile ; elle nécessite de relever de nombreux défis (navigation, dépendances cycliques...) et ne s'improvise pas.

Ainsi, dans le second article de cette série, on va s'attacher à bien préparer la refonte de son application.