Codifier la sauce secrète

Chaque application a sa sauce secrète, sa raison d’être. Codifier la sauce secrète est essentiel pour écrire des applications maintenables et réussies.

Attendez. Qu’est-ce que codifier ? Patience mon ami, nous y arriverons.

Commençons par une hypothèse :

Vous venez d’être promu ingénieur logiciel principal (Félicitations !). La première tâche de votre PDG est de créer un nouveau produit pour l’entreprise. C’est une application comptable construite de zéro. Les cadres pensent qu’une solution comptable personnalisée leur donnera un avantage sur la concurrence.

Quelques mois ont passé, la plupart des préoccupations transversales sont développées (bravo !). L’équipe se concentre maintenant sur la partie savoureuse de l’application : le domaine métier (la sauce secrète). C’est là que commence la codification de la sauce secrète.

Codifier, c’est mettre de la structure autour d’un concept essentiel du domaine métier.

En comptabilité, le ratio cours/bénéfice (ratio P/E) est une mesure des bénéfices d’une entreprise. Un ratio P/E élevé suggère une croissance des bénéfices élevée à l’avenir. Le ratio P/E est calculé en prenant la valeur marchande par action (prix de l’action) divisée par le bénéfice par action (profit – dividendes / nombre d’actions en circulation).

Une implémentation simple, et j’oserais dire, naïve :

public class Metric
{
    public string Name { get; set; }
    public decimal Value {get; set}
    public int Order {get; set;}
}
public class AccountingSummary
{
    public Metric[] GetMetrics(decimal price, decimal earnings)
    {
        var priceEarningsRatio = price/earnings;
        
        var priceEarningsRatioMetric = new Metric 
        {
            Name = "P/E Ratio",
            Value = priceEarningsRatio,
            Order = 0
        }
        return new [] {priceEarningsRatioMetric};
    }
}

Si cela n’est utilisé qu’à un seul endroit, c’est correct. Que se passe-t-il si vous utilisez le ratio P/E dans d’autres domaines ?

Comme ici dans PriceEarnings.cs

var priceEarningsRatio = price/earnings;

Et ici dans AccountSummary.cs

var priceEarningsRatio = price/earnings;

Et ici dans StockSummary.cs

var priceEarningsRatio = price/earnings;

Le ratio P/E est au cœur de cette application, mais la façon dont il est implémenté, codé en dur à différents endroits, fait perdre l’importance du ratio P/E dans une mer de code. C’est juste un autre arbre dans la forêt.

Vous courez également le risque de modifier le ratio à un endroit mais pas à l’autre. Cela peut fausser les calculs en aval. Ces types d’erreurs sont notoirement difficiles à trouver.

Souvent, les testeurs supposeront que si cela fonctionne dans un domaine, c’est correct dans tous les domaines. Pourquoi l’application n’utiliserait-elle pas le même code pour générer le ratio P/E pour l’ensemble de l’application ? N’est-ce pas le point de la programmation orientée objet ?

Je peux imaginer une erreur comme celle-ci se retrouver en production et ne pas être découverte jusqu’à une visite de votre cadre qui demande pourquoi les calculs du ratio P/E de la SEC sont différents de ce que l’entreprise a déposé. Ce n’est pas une bonne position.

Revisitez notre implémentation du ratio P/E et voyons comment nous pouvons l’améliorer par rapport à notre première tentative.

Dans les systèmes comptables, les formules existent, mettons de la structure autour des formules en ajoutant une interface :

public interface IFormula
{
    decimal Calculate<T>(T model);
}

Chaque formule est maintenant implémentée avec cette interface, ce qui nous donne de la cohérence et de la prévisibilité.

Voici notre ratio P/E amélioré après implémentation de notre interface :

Nous avons ajouté un PriceEarningsModel pour passer les données nécessaires à notre méthode Calculate.

public class PriceEarningsModel
{
    public decimal Price {get; set;}
    public decimal Earnings {get; set;}
}

En utilisant notre PriceEarningsModel, nous avons créé une implémentation de l’interface IFormula pour le ratio P/E.

public class PriceEarningsRatioFormula : IFormula
{
    public decimal Calculate<PriceEarningsModel>(PriceEarningsModel model)
    {
        return model.Price / model.Earnings;
    }
}

Nous avons maintenant codifié le ratio P/E. C’est un concept de première classe dans notre application. Nous pouvons l’utiliser n’importe où. C’est testable, et une modification impacte l’ensemble de l’application.

Pour rappel, voici l’implémentation avec laquelle nous avons commencé :

public class Metric
{
    public string Name { get; set; }
    public decimal Value {get; set}
    public int Order {get; set;}
}
public class AccountingSummary
{
    public Metric[] GetMetrics(decimal price, decimal earnings)
    {
        var priceEarningsRatio = price/earnings;
        
        var priceEarningsRatioMetric = new Metric 
        {
            Name = "P/E Ratio",
            Value = priceEarningsRatio,
            Order = 0
        }
        return new [] {priceEarningsRatioMetric};
    }
}

C’est simple et fait le travail. Le problème est que le ratio P/E, qui est un concept fondamental de notre application comptable, ne se démarque pas. Les ingénieurs qui ne connaissent pas l’application ou le domaine métier ne comprendront pas son importance.

Notre implémentation améliorée utilise notre nouvelle classe de ratio P/E. Nous injectons la classe PriceEarningsRatioFormula dans la classe AccountSummary.

Nous remplaçons notre ratio P/E codé en dur par notre nouvelle classe PriceEarningsRatioFormula.

public class AccountingSummary
{
    private PriceEarningsRatioFormula _peRatio;
    
    public AccountingSummary(PriceEarningsRatioFormula peRatio)
    {
        _peRatio = peRatio;
    }
    
    public Metric[] GetMetrics(decimal price, decimal earnings)
    {
        var priceEarningsRatio = _peRatio.Calculate(new PriceEarningsModel 
        { 
            Price = price, 
            Earnings = earnings
        });
        
        var priceEarningsRatioMetric = new Metric 
        {
            Name = "P/E Ratio",
            Value = priceEarningsRatio,
            Order = 0
        }
        return new [] {priceEarningsRatioMetric};
    }
}

On pourrait soutenir qu’il y a un peu plus de travail avec PriceEarningsRationFormula par rapport à l’implémentation précédente et je serais d’accord. Il y a un peu plus de cérémonies, mais les avantages valent bien la petite augmentation du code et des cérémonies.

Premièrement, nous gagnons la capacité de modifier le ratio P/E pour l’ensemble de l’application. Nous avons également une seule implémentation à déboguer si des défauts surviennent.

Enfin, nous avons codifié le concept de PriceEarningsRatioFormula dans l’application. Quand un nouvel ingénieur rejoint l’équipe, il saura que les formules sont essentielles à l’application et au domaine métier.

Il existe d’autres méthodes de codification (encapsulation) du domaine, comme les microservices et les assemblies. Chaque approche a ses avantages et ses inconvénients, vous et votre équipe devrez décider ce qui convient le mieux à votre application.

Enfermer les concepts clés du domaine dans des classes et des interfaces crée des composants réutilisables et des limites conceptuelles. Cela rend une application plus facile à comprendre, réduit les défauts et abaisse les barrières à l’intégration de nouveaux ingénieurs.