Tout d'abord, sans vous faire l'intégralité de ma présentation, ni de l'historique de mon parcours, sachez que je viens de terminer mes études d'architecture logicielle en informatique dans une école qui a pris soin de nous apporter des intervenants dont le but était de nous transmettre les nouveautés du secteur ainsi que toutes les bonnes pratiques, de façon à ce que nous ne soyons qu'un gain en capital à notre arrivée dans l'entreprise de notre choix.
C'est pourquoi je me permet de répondre à votre annonce en vous livrant des ressources que j'ai moi-même acquises dans le but d'améliorer l'existant d'une entreprise en recherche de novations.
Pour illustrer mes propos je vais prendre des éléments du contexte ainsi que des extraits de votre programme en me permettant d'y apporter des modifications.
Pour commencer, je comprends tout à fait votre contexte, vous voulez pérenniser votre architecture en la modernisant et en utilisant des outils afin d'améliorer vos processus.
Je peux voir tout de suite que vous utilisez la programmation orientée objet, il est donc primordiale que vous adoptiez
les 5 principes de bases de celle-ci : SOLID. Il serait arrogant de ma part de vous énoncer les définitions de cet acronyme,
je vais donc simplement vous expliquer en quelques mots l'idée globale : Vous devez garder en tete que ce qui permettra à votre code d'être gérable est votre capacité à tout séparer. De cette façon tout aura une place et une responsabilité. (On peut retrouver cela dans KISS également, l'idée est de tout faire au plus simple).
Je vous apporterai mon soutien dans la refonte de votre architecture, de sorte à ce qu'elle reste cohérente. Vous gagnerez en performance si vos objets et leurs parents ne subissent pas de modification inattendue.
Un autre des principes apporté par cette méthode est qu'il vous faut découper au maximum, même les classes et interfaces qui vous semblent appartenir au meme comportement.
En effet, je n'hésiterai pas à séparer votre code en différents fichiers, cela pourra également vous donner l'opportunité d'assimiler une autre valeur importante : éviter la redondance de code, les traitements identiques à plusieurs endroits du programme. Vous n'aurez qu'à appeler la fonction correspondante C'est d'ailleurs un nouveau principe que je m'efforcerai d'appliquer dans votre contexte, DRY, le but étant de faciliter le débogage et les tests en évitant au maximum de répéter le même code.
En parlant de tests, vous décrivez vos fonctions comme intestables, vous avez tout à fait raison de penser que ce point est important. Il s'agit d'une notion primordiale en terme de développement puisque les tests permettent tout d'abord de vérifier si votre programme fonctionne, mais également, dans la dimension de découpage de votre code, tester chacune des fonctions afin de vérifier, en dehors du besoin métier de votre programme, si tout fonctionne correctement, tests de non régression compris. Si vous me le permettez, après avoir aidé à mettre à jour l'existant de votre contexte, je mettrai en place un concept qui préconise de faire les tests avant le programme lui même, pour avancer pas à pas dans le code et tout mettre en place avant même le besoin métier : TDD.
Pour illustrer davantage mes propos je vais à présent prendre en exemple des morceaux de votre programme :
Aussi fonctionnel soit-il, votre code tel qu'il est présenté ne permet pas un suivi digne de son contenu, vos variables ayant des noms aléatoires, ne facilitent pas le travail de maintien. Je vous accompagnerai dans ce sens, donner un sens explicite à vos variables de façon à ce que, même un inconnu, puisse pointer du doigt l'objet utilisé.
Basket b = new Basket();Comme je vous l'ai dit plus haut, les tests doivent se faire bien à l'écart du fonctionnel métier, votre Main ne devrait contenir que celui-ci, tout le reste est reservé à être dans un endroit différent, pour faciliter la compréhension du chemin dans votre architecture. De la même façon, vous testez votre comportement sur le panier dans le Main (comme ci après) :
static void Main(string[] args)
{
try
{
NormalPricer np = new NormalPricer();
PromoPricer pp = new PromoPricer();
Basket b = new Basket();
b.add("pomme",3,np,pp);
b.add("orange",10,np,pp);
b.add("poire",4,np,pp);
//on affiche le contenu du panier pour imprimer le ticket de caisse
Console.WriteLine(String.Join(Environment.NewLine,b.Print()));
Console.WriteLine("--------------------");
//on recup le total:
var tl = "total = " + b.Total.ToString();
var esp="";
for (int i = 0; i < (20-tl.Length); i++){esp+= " ";}
Console.WriteLine(esp+tl);
}
catch (System.Exception ex)
{
Console.WriteLine(ex.Message);
Console.WriteLine(ex.StackTrace);
}
}Vos autres classes devraient être dans d'autres fichiers et vos tests bien à l'écart de vos classes :
//juste pour l'exemple
public static class PriceDbService
{
private static Dictionary<string, double> prices =
new Dictionary<string,double>(){
["pomme"] = 2,
["orange"] = 1,
["poire"] = 3
};
public static double GetPrice(string name)
=> prices.TryGetValue(name, out double val) ? val : 0;
}Pour finir, vos commentaires sont effectivement un bon reflexe, mais ceux ci devraient être l'objet d'un formatage spécifique dans le but de construire une documentation fonctionnelle. Il est donc peu convenable de mettre ceux ci en français et d'y noter des phrases sur le comportement, qui devrait être intuitif, de votre programme.
//le panier peut contenir des elements identifiés par leur nom, avec leur quantité et prixLorsque toutes ces bonnes pratiques seront en place, vous aurez une architecture pérenne et cohérente, ainsi que maintenable. Il vous sera également possible de mettre en place l'intégration continue et de produire et déployer au plus rapidemment.
En espérant que ces éléments que je vous ai humblement présenté seront gages de ma passion des bonnes manières sur le sujet ainsi que ma motivation à les réaliser dans votre contexte.
Bien à vous,
Candice Guitton.