The latest articles on DEV Community by Gilles Gauthier (@spike31). https://dev.to/spike31 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F377739%2F650ad578-e540-470f-95c3-de5c415402f4.png https://dev.to/spike31 en Gilles Gauthier Sat, 07 Nov 2020 14:20:43 +0000 https://dev.to/spike31/transparence-1-1-organiser-ses-calculs-1he https://dev.to/spike31/transparence-1-1-organiser-ses-calculs-1he <p>Etre transparent sur son travail ça n'est pas toujours simple et possible. Pour des questions évidentes de confidentialité.</p> <p>On peut néanmoins en extraire des morceaux à partager.</p> <p>Récemment j'ai eu à travailler sur un projet dans le domaine de l'agriculture, où le besoin était de fournir une interface pour saisir des données et afficher des calculs. </p> <p>Le soucis que l’on a rencontré, c'est que les calculs il y en avait beaucoup, pas très simple et pour ceux qui n'y connaissent rien, assez compliqué à vérifier.</p> <blockquote> <p>En effet comment savoir que tel résultat est juste si on a aucune idée de ce qu'on doit obtenir ? Surtout où les données sont des pourcentages, des nombres à virgules...</p> </blockquote> <h2> Demander de l'aide à l'expert du domaine </h2> <p>Ce que j'ai fais en premier lieu, c'est demander à "l'expert" du domaine chez le client de nous remplir un fichier yaml sous un format précis.</p> <p>Je lui demandais de me donner le nom du calcul, les valeurs en entrées et le résultat attendu.<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight yaml"><code><span class="na">calculs</span><span class="pi">:</span> <span class="na">calcul_A</span><span class="pi">:</span> <span class="na">given</span><span class="pi">:</span> <span class="na">param_1</span><span class="pi">:</span> <span class="m">2.2</span> <span class="na">param_2</span><span class="pi">:</span> <span class="m">0.01</span> <span class="na">param_3</span><span class="pi">:</span> <span class="m">32</span> <span class="na">expected</span><span class="pi">:</span> <span class="m">8</span> </code></pre> </div> <p>Ainsi on a pu tester automatiquement énormément de calculs, et s'il nous soumettait un nouveau fichier yaml, on pouvait le valider rapidement.</p> <h2> Implémenter les calculs </h2> <p>Je me suis demandé comment organiser le code pour tous ses calculs.</p> <p>Mon architecture est basée sur le modèle hexagonale, et sur une philosophie DDD. J'ai donc un Dossier AgricultureContext (j'invente un nom pour l'article), et je ne voulais pas que les calculs fassent partie de ce contexte.</p> <p>Pourquoi ? et bien les calculs, c'est toute une connaissance à part entière à gérer, qui peut être indépendante du reste du projet. Je me suis dis, peut-être que je devrai penser comme si les calculs venaient d'ailleurs, comme une API externe.</p> <p>Du coup j'ai pensé, pourquoi ne pas faire un autre contexte dédié aux calculs. Au final tout ce qu'on veut c'est que pour des données en entrées, on souhaite obtenir un résultat. </p> <p>Dans ce contexte, on retrouvera des éléments commun en terme de nommage <em>(en DDD on parle tous le même language, mais selon les contextes on en fait pas la même chose)</em>, mais le but de ce contexte, c'est d'effectuer des calculs et de savoir comment les faire. </p> <p>Je suis un fervent défenseur de "la responsabilité unique". Une classe ne doit faire qu'une seule chose et bien. On peut étendre ce concept à un niveau plus général, c'est pourquoi j'ai voulu sortir les calculs du contexte Agriculture. </p> <p>Ainsi on peut faire évoluer le code dans le CalculContext sans aucun impact sur le reste. On pourrait même un jour faire un autre projet séparé, reprenant le code du CalculContext, et pourquoi pas à la place de partager une interface dans un monoprojet, de passer par une API.</p> <p>En tout cas c'est la voie que j'ai choisi. Avec le recul, est-ce que j'aurai pu mettre tous les calculs dans le même contexte ? J'y ai pensé, mais à faire ça, je sais que j'aurai eu un code très couplé avec le domaine et moins simple à tester.</p> <p>Donc pour faire le lien entre les deux contextes, j'autorise un service à être appelé dans le contexte Agriculture. Pour cela j'utilise le concept "d'anti-corruption layer". C'est à dire transformer le model d'un domaine vers un autre. Par exemple traduire une classe vers une autre, du json vers une classe, ou une classe vers du xml etc. Le but étant de ne pas manipuler les données d'un autre domaine sans l'avoir transformé pour son propre domaine auparavant. </p> <blockquote> <p>Si je n'avais pas fais ça, je me serai retrouvé à manipuler des classes d'un autre domaine (un autre namespace), ce qui viendrait à coupler notre code très fortement et casser les barrières de nos contextes. Ne faites pas cela.</p> </blockquote> <p>Concernant les calculs en eux mêmes, j’ai choisi de créer une classe par calcul, avec en paramètres un tableau de données, avec validation des noms et du type attendu.</p> <p>Et voilà, on arrive à la fin de cette petite transparence de code. </p> <p>J'essaierai d'en écrire d'autre, j'ai plein de sujet en tête.</p> ddd architecture Gilles Gauthier Tue, 22 Sep 2020 12:36:51 +0000 https://dev.to/spike31/pourquoi-je-n-aime-plus-trop-faire-du-angular-27n5 https://dev.to/spike31/pourquoi-je-n-aime-plus-trop-faire-du-angular-27n5 <p>J'ai beaucoup fais de javascript, de toute sorte. Vanilla, jquery, react, angular, vue, mootools...</p> <p>Faire du javascript c'est rarement expliqué et comprit par le client, lui tout ce qu'il veut c'est que son bouton bleu envoie un mail et affiche une notification verte.</p> <p>Ok ! traduisons ça en langue de développeur :</p> <ul> <li>j'ai un bouton bleu</li> <li>au clic, faire un appel ajax</li> <li>à la réponse, si tout va bien, afficher une notification verte</li> </ul> <p>Ok ça va ! c'est simple !</p> <p>J'ai fais d'autres projets plus complexe, dont un qui m'a épuisé mentalement et quasi dégouté de faire des applis angular. Surtout pour éviter à devoir gérer tous les problèmes que ça implique.</p> <p>C'était une appli pour gérer des voyages. Il fallait définir le pays, les lieux, en passant par la réservation d'hôtel, les tarifs, la location de véhicules, les visites groupées etc.</p> <p>En soit, dit comme ça, le genre de projet très intéressant à faire !</p> <p>En vrai, on a vu qu'on ne pourrait pas faire des pages php et des formulaires statiques. Il nous fallait du dynamique, de la réactivité, croiser les informations entre elles et afficher le tout...</p> <p>Coup de bol, on avait eu droit à une formation angular et typescript peu de temps avant, et j'avais très envie d'en refaire.</p> <p>Heureusement je ne m'occupais que de la partie angular et pas du code métier/api. </p> <h1> Organiser un voyage, comment ça se passe en coulisse ? </h1> <p>Il faut un jour d'arrivée et un jour de départ. C'est des personnes, adultes ou enfants. Un pays, un lieu et des activités.</p> <p>Le client voulait une interface pour construire les étapes du voyage :</p> <ul> <li>sur la gauche de l'écran, une liste verticale composée de journée</li> <li>sur la droite, une liste de produits</li> </ul> <p>Un produit c'était n'importe quoi, par exemple un safari en jeep, une balade sur le lac, une voiture de location etc.</p> <p>Les journées pouvaient être drag&amp;n drop comme on le voulait, en effet on pouvait décider d'inverser des produits par exemple. Ou bien décider de partir une semaine plus tard..</p> <p>Certains produits étaient sur plusieurs jours, par exemple une sortie en mer pour faire le tour d'une île en 3 jours. Difficile d'inverser ces journées, il fallait les grouper.</p> <p>Sur chaque journée, on pouvait cliquer et afficher un formulaire pour modifier encore des données. Celui-ci s'affichait dans une fenêtre qui venait de la droite, et on pouvait en superposer à l'infini (vu que tout est en asynchrone, si on voulait créer une donnée non disponible, il fallait garder néanmoins le contexte où on était).</p> <p>Petite anecdote : je m'étais inspiré de google tag manager pour ceux qui connaissent, ça marchait bien et j'étais assez fier du résultat. J'étais même allé voir le javascript utilisé sur leur site...tiens tiens, du angular1. Oh tiens le code source non minifié. Bravo les gars ! Bon j'avais regardé comment ils avaient pensé la chose et je m'en suis sorti en angular2. Pas très professionnel de la part de Google.</p> <h2> Les produits, tout et n'importe quoi ! </h2> <p>La création des produits étaient très complexe. On pouvait louer des voitures, mais pour ça il fallait un fournisseur, et définir les prix par saison et par année.</p> <p>Une sortie en mer, il fallait définir le prix, par groupe souvent, l'heure de départ et d'arrivée...</p> <p>Un aspect complexe et non détaillé par le client, c'était la description des produits. En effet il fallait une description côté commerciale, une description côté devis et une description complète avec souvent des photos pour donner à la fin, une sorte de gros PDF qui ajoute un "+" à la satisfaction du client.</p> <p>Je vous laisse imaginer les interfaces avec les formulaires.</p> <h2> Les hôtels </h2> <p>Les hôtels...j'ai appris beaucoup de chose, mais le calcul des prix des hôtels ça peut faire mal à la tête.</p> <p>Il y avait aussi la génération des vouchers. Quand vous réservez un hôtel, on vous donne des vouchers, avec le nom des personnes, date d'arrivée et départ et des informations sur l'hôtel...bref ! (à générer en pdf pour les imprimer)</p> <p>Il faut aussi contacter l'hôtel pour lui soumettre la réservation, et qu'il puisse y répondre favorablement ou non. Si l'hôtel était indisponible, il fallait automatiquement switcher vers un autre hôtel, ainsi de suite...</p> <h2> Itinéraire d'un voyage.. </h2> <p>Souvent les gens n'ont pas de GPS ou leur téléphone à l'étranger...donc il fallait pouvoir générer un itinéraire entre les produits, dans un PDF. (itinéraire généré via google maps). Ca veut dire que sur chaque produit, il fallait ajouter un lieu avec des coordonnées précises.</p> <h2> Et pour finir, le devis ! </h2> <p>Tout ça c'est pour générer un devis au final, avec le détail des prix de tous les produits.<br> Avec des calculs alambiqués, des calculs de marges etc etc..</p> <p>Le devis pouvait s'afficher de manière complexe pour le commercial, ou simple pour le client. On pouvait aussi dupliquer des devis pour proposer plusieurs choix. Dupliquer un devis ça revenait à dupliquer le voyage, c'était pas anodin comme action.</p> <h1> Côté technique </h1> <p>Beaucoup de données à gérer implique beaucoup de code ! pour le meilleur comme pour le pire...</p> <h2> RXJS </h2> <p>Heureusement que cette librairie existe, c'est sûrement une des plus cool ! On peut vraiment gérer toutes les sources de données comme on le souhaite. Mélanger, mixer, trier, attendre, grouper... une pépite ! De plus elle est adoptée par angular.</p> <h2> Redux...ou plutôt NGRX </h2> <p>Aie, ouille...Super librairie également, par contre bourrée de BC breaks à l'époque, et pas du genre facilement résolvable sur un gros projet. </p> <p>Ils ont été capable de complètement changer leur api entre deux versions majeur et complètement délaisser l'ancienne version. Ce qui veut dire que pour continuer à utiliser les nouvelles versions d'angular, il fallait utiliser la nouvelle version de ngrx. </p> <p>C'est dommage d'avoir fait ça, bon nombre de gens ont été déçu. La migration, malgré leur fichier d'update, étaient très très compliqué..</p> <h2> Typescript </h2> <p>Typescript est un super language, je ne reviendrai pas dessus pour vous dire pourquoi. </p> <h2> Un projet Angular </h2> <p>Mais un gros projet comme celui-là impliquait d'avoir une organisation et une structure robuste !</p> <p>Angular raisonne en module, c'est très bien et on s'y retrouve facilement. Là où ça devenait plus épineux, c'était NGRX, parce qu'il fallait gérer la mise à jour du state, voir...des states.</p> <p>Le fichier devenait assez gros, il fallait gérer les erreurs etc. Dans l'ensemble tout fonctionnait bien, le state également. Mais dans le sous-sol, derrière la porte d'où sortait une petite lumière verte, on entendait un bruit incessant. Celui de tous ces rouages qui tournaient, et qu'il fallait connaître par coeur pour ne pas s'y perdre.</p> <p>Parce que finalement, des gros projects, aussi bien structuré qu'ils le soient, on s'y perds un jour ou l'autre. On se demande comment on a pu laisser ce fichier dépasser les 500 lignes, pourquoi ce template a été mal pensé et que fait ce Subject (rxjs) exactement déjà dans cette classe ?</p> <p>C'était mon premier gros projet angular, et on pouvait vraiment faire ce qu'on voulait avec. Ca implique de gagner en connaissance et d'en apprendre encore et encore.</p> <p>Angular est une grosse boîte à outils. Dedans il y a plein de chose à utiliser, les templates, les directives, le routing, l'authentification...</p> <h1> Conclusion </h1> <p>Ce projet datait de 2017, depuis je n'ai plus refais d'angular, par crainte de devoir gérer des choses hallucinantes en javascript et typescript.</p> <p>Oui rien que de penser à l'idée de maintenir un projet angular sur le temps me pousse à fuir !</p> <p>Maintenant je fais un peu de vuejs, ça me semble plus simple. ReactJS, déjà fait, déjà re-fait...non merci ! faut aimer ça.</p> <p>Bref, voilà, c'était ma petite histoire et je voulais la partager...ça fait du bien d'en parler !</p> angular javascript rxjs