Comment assurer un moteur de calcul des prix au millimètre ?

L’importance du mécanisme de calcul des prix (PCE)

Pour un site web réussi, orienté vers le e-commerce, l’un des points principaux est le prix. Tout au long de la navigation du client, le prix doit rester cohérent avec les articles sélectionnés. Les changements de prix d’une page à l’autre vont créer une certaine frustration et une incertitude chez le client, qui se traduiront par de la méfiance. Cette méfiance se traduira par une mauvaise expérience et la mauvaise expérience fera que le client ne reviendra jamais. Mais un client qui ne reviendra pas n’est pas seulement une vente unique qui n’est pas réalisée, mais aussi tous les clients potentiels de son entourage. Voici comment un seul élément peut avoir un impact majeur sur le chiffre d’affaires d’un site web.

Son effondrement

Pourquoi le Price Calculation Engine (PCE) se transforme-t-il si souvent en boîte noire dans le développement d’un site web ? Au rythme auquel un site web d’aujourd’hui se développe, les caractéristiques fonctionnelles qui définissent le PCE suivent également ce rythme. Cela signifie une complexité sans cesse croissante, et une expérience et un savoir-faire rapidement obsolètes. Peu à peu, le PCE devient une boîte noire, et plus personne ne veut travailler avec. Personne ne sait vraiment comment elle fonctionne, mais tout le monde sait qu’une seule modification se traduira par une longue liste de problèmes.

Je vais maintenant décrire comment j’ai traité ce problème pour un site web qui permet d’obtenir un devis en ligne pour la réparation ou l’entretien d’un véhicule. Notre PCE contenait plusieurs types de réparations (pneus, vitres, mécanique ou carrosserie), mais la partie la plus délicate était les remises (applicables par type de réparation, par montant minimum, par convention, cumulables ou non…). Le problème venait du fait que les prix pouvaient être différents du début à la fin. L’ajout d’un nouveau type de réparation ou d’une promotion pouvait donc s’avérer très complexe.

Sa récupération

Maintenant, je vais exposer certaines étapes que j’ai suivies pour résoudre ces problèmes et rendre le PCE plus gérable. Notre PCE s’est développé trop rapidement. Trop de règles sont apparues sans que l’on pense aux risques de dysfonctionnement, ce qui a fait du PCE une sorte de monstre ingérable. Au début, tout a commencé par une bonne conception, c’est plus tard que de multiples sujets sont entrés en conflit.

L’isolement

La plupart du temps, la boîte noire ne fonctionne pas vraiment comme elle le devrait . Mais il y a des morceaux du PCE répartis dans toute l’application. Cela pose différents problèmes :

• Trouver les erreurs, car il y a plusieurs endroits où regarder (et certains sont cachés);
• Comprendre son comportement, car il est compliqué de suivre correctement le workflow de l’exécution;
• Difficile à tester, car il y a trop de dépendances.

Pour tenter de résoudre ces problèmes, nous devions d’abord essayer d’avoir tous les PCE à un seul endroit. Si nous parvenions à avoir toutes les règles au même endroit, nous aurions défini des limites sans rien de plus à l’intérieur. Cela a été notre première réussite.

Une architecture hexagonale

En ayant tous les éléments de logique dans cette même boîte noire, nous avons pu constaté que le PCE sollicitait d’autres services et notamment plusieurs informations telles que des données sur les remises, les prix des pièces détachées, les taux horaires, etc pour fournir un prix correct.

Où se situe le problème désormais ?

• Trop de points d’entrée;
• Trop de dépendances;
• Contexte trop compliqué pour demander le PCE.

L’architecture hexagonale décrit l’indépendance de chaque partie du système, ce qui signifie que le PCE ne doit pas avoir besoin d’une autre partie pour fonctionner correctement.

Comment y parvenir ?

1. En identifiant toutes les données/informations dont le PCE a besoin;
2. En identifiant tous les points d’entrée du PCE;
3. En créant un objet qui comprend toutes les informations identifiées au premier point;
4. En modifiant tous les points d’entrée énumérés au point 2 pour n’accepter que l’objet créé au point 3.

De cette façon, tous les points d’entrée auront le même format, mais mieux encore, il sera plus facile à tester. Nous avions un objectif important à demander au PCE qui exigeait trop d’informations (parfois inutiles),mais à ce stade, cela ne nous a pas posé de problème.

Tests unitaires

Nous voici donc à l’étape qui nous permettra de nous assurer que les futures modifications n’auront pas d’incidence sur les anciennes règles. Mais cette étape est loin d’être facile. Voici la séquence que j’ai suivie pour mettre en place les tests nécessaires :

1. Création d’un seul test par type de réparation avec les paramètres de base
2. Ajouter des tests supplémentaires avec les paramètres et les rabais les plus courants
3. Continuer avec les paramètres et les rabais les moins courants
4. Ajouter les cas extrêmes
5. Ajouter les cas impossibles (si c’est impossible, nous devons nous assurer que le client en est conscient)

Ce fut une longue tâche. J’ai dû discuter avec plusieurs personnes pour comprendre certaines règles fonctionnelles, et j’ai enquêté sur l’historique des demandes fonctionnelles. J’ai également découvert des problèmes entre le résultat attendu et le résultat réel. Mais je n’ai pas perdu mon temps à essayer de les corriger, je m’en suis occupé plus tard. J’ai donc pu garantir la stabilité du PCE.

La documentation

Maintenant que j’ai fait un gros travail d’investigation sur le passé du PCE, je ne dois pas écarter toutes ces informations. Je dois maintenant documenter autant que possible le système.

Mais où ?

Le meilleur endroit reste à l’intérieur de l’application. Si la documentation et les algorithmes sont séparés, ils n’évolueront pas ensemble. Certaines parties complexes ont été décrites juste à l’intérieur du code, mais la plupart des parties de l’application ont été décrites avec les tests. Nous devons donc nous assurer que les mécanismes sont bien décrits et compris (et pas seulement par celui qui les a écrits).

Remaniement

C’est la dernière étape. J’ai déjà réussi à isoler le PCE. J’ai également réussi à stabiliser les modifications. Et enfin, j’ai documenté le système pour en améliorer la lisibilité. Il est maintenant temps de repenser la logique, de trouver une architecture qui corresponde au mieux aux besoins actuels et aux fonctionnalités futures. Il est temps de supprimer les anciennes règles qui sont dépassées.

Il n’y a pas de procédure que je puisse donner pour cette tâche, car elle dépendra de l’architecture, des technologies utilisées, et de bien d’autres aspects. Néanmoins, le système est maintenant stable et prêt à accepter sans crainte une grande refonte du PCE.

Les derniers mots

En fin de compte, nous avons réussi à avoir un PCE stable :

• Les tests assurent la non-régression;
• La documentation permet un embarquement rapide et facilite les modifications;
• L’isolement aide à l’intégration de nouveaux types de réparation
• Et quelques autres avantages.

Peut-être que dans quelques années, l’architecture actuelle sera dépréciée, mais comme le système est isolé, il ne générera pas plus de difficultés .

Des procédures comme celle que j’ai décrite dans cet article peuvent être utilisées pour stabiliser et remanier n’importe quelle partie d’un système. Je me suis surtout concentré sur le PCE parce que c’est l’une des parties les plus sensibles, l’une des plus importantes de l’entreprise. La procédure que j’ai décrite assurera la stabilité, montrera les caractéristiques/problèmes cachés et vous permettra de commencer le refactoring de n’importe quelle partie critique.