Gérer l’incertitude et la complexité dans le développement logiciel

Ceci est le deuxième article d’une série de blogs qui résume les leçons que j’ai apprises lors d’une migration technologique avec une grande incertitude et complexité. Dans le post précédent, j’ai expliqué comment j’ai découvert le problème d’origine. Dans cet article, je vais parler de la façon dont j’ai fait face au problème.

Les détails, l’incertitude et la complexité ont ralenti mes progrès, j’ai donc décidé de soumettre quelques idées à mon chef car j’avais besoin d’un nouveau plan pour commencer à faire des progrès substantiels. L’objectif que nous nous étions fixé était de nous débarrasser de la complexité pour commencer à progresser dans le développement tandis qu’en arrière-plan je poursuivais l’analyse pour éventuellement couvrir toute la logique métier.

Le fichier ASP.NET contenait beaucoup de code qui n’était même pas lié à la portée de l’exigence, qui consistait à migrer le Page d’examen des transactions, la première étape a donc été d’identifier le chemin heureux de cette fonctionnalité et de ses principaux composants. Les étapes suivantes consistaient à itérer encore et encore pour migrer plus de fonctionnalités à chaque itération jusqu’à ce que j’atteigne les scénarios inhabituels.

L’autre chose que j’ai changée, c’est l’approche d’analyse. Au début, J’essayais de comprendre le front-end et le back-end pour déterminer ce qu’il fallait rendre (champs, libellés, boutons) et comment (quand masquer ou afficher les champs, quand afficher un champ comme modifiable ou en lecture seule), mais comme le code était illisible, cette approche ne fonctionnait pas. J’ai décidé de rendre chaque section et élément que je pouvais identifier directement dans l’interface utilisateur, puis je commencerais à ajouter la logique pour masquer les éléments, puis la logique pour les changer en lecture seule, et enfin les fonctionnalités restantes. Avec cette approche, je n’ai pas eu à plonger dans le code, du moins pour la première partie, j’ai juste eu à regarder l’interface utilisateur, et parfois à confirmer certaines hypothèses dans le front-end, ce que je n’avais jamais fait auparavant.

Avec ces changements, j’ai commencé à faire des progrès significatifs. Cette nouvelle façon de travailler sans regarder le code m’a beaucoup intéressé. Je me suis connecté à l’application en utilisant différents utilisateurs de différentes organisations, puis j’ai ouvert autant de transactions que possible. Pour chaque variation que j’ai vue dans l’interface utilisateur, j’ai pris une capture d’écran. Avec cela, j’ai identifié et documenté presque tous les composants qui devaient être construits pour l’interface utilisateur en changeant simplement le scénario. Après avoir identifié les sections, leurs éléments et leurs déclinaisons, j’ai pu créer et distribuer le tout dans des vues MVC et des vues partielles.

Construire la nouvelle interface utilisateur à partir de zéro m’a également permis de mieux comprendre le code hérité, ce que je ne pensais même pas être possible et auquel je ne m’attendais pas, surtout parce que je ne le regardais pas tellement. À chaque itération que j’ai faite pour ajouter plus d’éléments à l’interface utilisateur, j’ai dû approfondir l’ancien code, d’une manière ou d’une autre, je me suis familiarisé avec chaque section et soudain, l’ancien code n’était plus si difficile à lire. Et quand j’ai regardé en arrière vers l’ancien Page d’examen des transactions pour comparer s’il me manquait quelque chose, j’ai réalisé que la structure principale du code HTML que j’avais développé était très similaire à celle du code hérité, juste beaucoup plus propre et plus lisible. Cela m’a surpris!

Ce qui m’a le plus étonné, c’est qu’en quelques semaines, j’ai pu présenter une démo du nouveau Page d’examen des transactions écrit en ASP.NET MVC. Cette démo n’était que le front-end de la fonctionnalité, elle utilisait des données factices et n’avait aucune logique du tout, mais elle rendait presque toutes les sections et tous les éléments inclus dans la fonctionnalité.

À partir de là, le travail est devenu plus gérable et j’ai continué à mettre à jour ma planification. Les étapes suivantes étaient évidentes, j’ai juste continué à ajouter plus de fonctionnalités comme lire les informations de la transaction à partir de la base de données et remplir les éléments, ajouter la fonctionnalité pour masquer/afficher les éléments, identifier les méthodes JavaScript et les méthodes C# que je devais migrer, quelles méthodes Je pouvais réutiliser, quelles méthodes je devais découpler des données et afficher la logique et créer à nouveau, et ainsi de suite.