## Bonne année les développeurs !

Je vous souhaite une très bonne année 2025 et que tous vos projets se concrétisent. 🎉🎉

**Qu'avez vous décidé de faire cette année ?**

Pour ma part je vais explorer de nouvelles technologies et probablement de nouvelles missions. 

### Quel sera le langage que je vais maîtriser cette année ?

Ce sera le **Go**, j'ai commencé **golang** il y a peu, et j'apprécie beaucoup son approche. Je ne suis aujourd'hui qu'un débutant mais je compte bien devenir un expert avec cette technologie, sous peu.

Je dois surtout apprendre les bonnes pratiques et essayer de m'habituer avec les commandes **CLI**, pour le reste c'est assez clair, simple et intuitif.

### Quels sont les news ?

#### Mise à jour du projet Versus-DB

![Mise à jour de Versus-DB](https://bo.dev-freelance.fr/uploads/versusdb_6ed33e3185.jpg)

Changelog:
- Optimisation du **SSR** pour améliorer la performance
- Changement de runtime **node** -> **bun**
- Optimization de l'encodage on the fly

La page d'accueil met à peine plus d'une seconde à se charger, ce qui est incroyable vu le système de stream buffer encodé client-server... Et les pages de détails mettent 500ms, je suis assez content du résultat !


#### Mon nouveau composant React

Dernièrement je bossais sur un petit projet, et je constatais que sur mes formulaires, il était difficile de proposer un composant lisible pour un choix multiple de 3, 4 ou 5 items.

Utiliser un **select** ou un **option**  à chaque fois, cela rendait la page pas très intuitive, du moins pas très ludique. 

J'ai opté pour une approche différente, un Circle Button Choice.

Regardez la différence, voici la page avant le nouveau composant:

![Avant optimisation composant React](https://bo.dev-freelance.fr/uploads/cs2strats_before_7cefe43a65.gif)

Voici la page maintenant:

![Après optimisation composant React](https://bo.dev-freelance.fr/uploads/cs2strats_after_f85135f9d7.gif)


C'est à peu près tout, je vous partagerai ce composant très bientôt, je vous dis à très vite !




medium_bonne_annee_2025.jpg

small_bonne_annee_2025.jpg

thumbnail_bonne_annee_2025.jpg

bonne_annee_2025.jpg

Bonne année 2025 ! Découvrez mes projets : maîtrise de Go, mise à jour de Versus-DB, et un nouveau composant React pour des choix intuitifs. 🎉🚀

Bonne année 2025, et bon code !

## Les besoins en performance

Vous connaissez peut-être **Lighthouse** ? L'**extension Chrome** de **Google** qui permet d'évaluer la performance de votre site. Je me suis penché dernièrement sur la performance du blog et j'essaie d'obtenir les meilleurs scores afin d'améliorer votre confort et aussi afin de m'amuser un peu, je dois l'admettre.

La performance, ce n'est pas que pour faire joli : plus votre site est **pratique**, **rapide** et **ergonomique**, plus le classement **SEO** est meilleur.

J'ai fait pas mal de choses sur le blog pour qu'il soit optimisé pour le **SEO**. Je me pensais pas mal à ce niveau. Mais en ce moment, je me fais accompagner par un **expert SEO**, en la personne de [Sébastien Schuck](https://fr.linkedin.com/in/sebastien-schuck), qui est à la fois bon techniquement et bon en contenu. Il m'a prouvé que j'avais tort de penser que le travail était fini. Je suis très satisfait de nos sessions, et je ne peux que vous recommander ses services.

### Mon score Lighthouse avant optimisation

En mobile, j'obtenais un très mauvais **37/100** : 
![Score Lighthouse Mobile avant optimisation](https://bo.dev-freelance.fr/uploads/perfs_mob_1_705119a6ac.png)

En desktop, j'étais à **58/100** : 
![Score Lighthouse Desktop avant optimisation](https://bo.dev-freelance.fr/uploads/perf_desk_1_29a0dabc0e.png)

#### Pourquoi ces résultats ?

**Next.js** seul est très performant, mais il se trouve qu'au fil du temps, j'ai ajouté des modules additionnels. Entre les extensions de charts, la coloration syntaxique pour les blocs de code, la gestion du markdown, les iframes YouTube, les iframes SoundCloud, etc... Tout cela ne fait qu'alourdir le chargement de mes pages.

**Pour autant, faut-il supprimer les modules ?**

Absolument pas, il faut optimiser notre manière de nous en servir. Compresser au maximum, décaler le chargement des modules non bloquants pour la page, etc. En gros, si vous n'avez pas besoin d'un **CSS** pour que la page commence à s'afficher, vous pouvez faire en sorte que son chargement soit non bloquant, et il en va de même pour les scripts.

De plus, les iframes peuvent se gérer différemment. Étant donné que les robots **SEO** ne prennent pas en compte ce contenu, il est inutile de les charger automatiquement si vous n'en avez pas besoin. Vous pouvez créer une façade (une image ou un bloc placeholder) qui pourra charger dynamiquement le contenu sur un **mouseover** ou avec un **intersection-observer**. 

Voici un exemple de **façade** (à gauche) et d'**iframe** à droite : 

![Exemple de façade Next.js](https://bo.dev-freelance.fr/uploads/facade_example_fa7608bd40.jpg)

Ici, à gauche, vous avez une **façade**, et une fois que la souris passe dessus, avec un **mouseover**, je vais intégrer dynamiquement l'**iframe YouTube**. Cette manœuvre permet de charger du contenu lourd après le contenu de vos pages, en permettant à **Google** de crawler tout ce qui est important d'abord.

Il en est de même pour tout le contenu en dessous de la ligne de flottaison. Si votre contenu est en bas de la page, l'utilisation d'une façade est plus que recommandée !

J'avais déjà travaillé sur des optimisations côté serveur, mais j'admets que je n'avais pas trop poussé les optimisations côté front. Maintenant que je m'y suis mis, je trouve que les changements sont drastiques : il y a un avant et un après !

### Mon score Lighthouse après optimisation

En mobile, je passe à **88/100** : 
![Score Lighthouse Mobile après optimisation](https://bo.dev-freelance.fr/uploads/perf_mob_3_077d2d5b11.png)

En desktop, je passe à **97/100** : 
![Score Lighthouse Desktop après optimisation](https://bo.dev-freelance.fr/uploads/perf_desk_3_e8cdf2f460.png)

### Bilan après optimisation du blog

Ces optimisations sont assez rapides à faire et demandent moins d'une journée de travail, pourquoi s'en priver ?

Aussi, je recommande à tous ceux qui veulent se lancer sur ce chantier d'utiliser les bons outils et de ne pas hésiter à se faire accompagner. Nous n'avons pas la science infuse.

large_update_perf_blog.jpg

medium_update_perf_blog.jpg

small_update_perf_blog.jpg

thumbnail_update_perf_blog.jpg

update_perf_blog.jpg

J'ai travaillé sur la mise à jour de la perf du blog suite aux conseils d'un expert SEO. J'ai appris énormément de choses intéressantes grâce à lui et j'essaye de les mettre en application. Le but étant d'améliorer l'expérience de navigation sur la blog.

Mise à jour performance du blog

La Belgique est un pays limitrophe qui est au nord de la France. Je précise car avant d'y aller je pensais que c'était un peu plus bas (honte à moi).

Quoiqu'il en soit le pays est sympathique, facile d'accès, ses transports en communs sont propres et le service est courtois.

Pendant ces quelques jours, je suis allé au **Nomad Community - Coworking Café** à Bruxelles, j'y ai travaillé pour mon client et profité des salles de réunions que l'on peut réserver ou utiliser spontanément.

![coworking_bruxelles.jpg](https://bo.dev-freelance.fr/uploads/coworking_bruxelles_99e91248ec.jpg)

Je tenais à parler d'eux car ils sont très gentils. J'ai oublié mon chargeur de mac sur place et j'ai pu contacter le coworking via le **Whatsapp** de la page **Facebook**. Ils me l'ont mis de côté pour que je le récupère sans problème.

Le coworking est aussi un café et vous propose plusieurs boissons chaudes et pâtisseries maisons. Je vous recommanderai le **banana braid** pour ma part. 

La ville est sympathique et vous avez un super marché à proximité et des restaurants tout autour.

De quoi travailler, manger et faire des courses si besoin, je recommande !

large_coworking_belgique_cover.jpg

medium_coworking_belgique_cover.jpg

small_coworking_belgique_cover.jpg

thumbnail_coworking_belgique_cover.jpg

coworking_belgique_cover.jpg

J'étais en vacances à Bruxelles dernièrement et comme je travaillais certains jour, j'en ai profité pour faire un peu de coworking. Je vous raconte tout ça.

J'ai fait du coworking en Belgique

Dans ce tuto, nous allons découvrir comment cloner une voix avec Python en utilisant la bibliothèque Text-To-Speech ou encore TTS, basée sur PyTorch. 

N'hésitez pas à jeter un oeil [au repository](https://github.com/coqui-ai/TTS)

L'objectif est de prendre un fichier audio de la voix de Cartman (de South Park) comme modèle, puis de lui faire dire ce que nous voulons. Le tout, bien sûr, en respectant l'humour et la voix unique de ce personnage emblématique.

### Prérequis

Il va falloir utiliser le langage Python. En sachant que Python est le langage pour lequel il y a le plus de librairie IA aujourd'hui.

Assurez-vous que PyTorch et TTS sont installés dans votre environnement Python. Vous pouvez les installer avec les commandes suivantes :

```
pip install torch
pip install TTS
```

### Préparez un fichier audio

Il vous faut un extrait audio clair de la voix de Cartman, que je vais vous fournir pour l'exemple.

[sample voix de cartman](https://1fichier.com/?pkci2tsly0jmupwnp29d) - password: **dev-freelance**

Enregistrez ce fichier dans un répertoire local, par exemple : 

```./input/cartman.wav```

Je vais vous le fournir 


### Notre code source

Tout ne tiendra qu'en peu de lignes:

```python
import torch
from TTS.api import TTS

device = "cuda" if torch.cuda.is_available() else "cpu"

print(TTS().list_models())

tts = TTS("tts_models/multilingual/multi-dataset/xtts_v2").to(device)

text_sample = "Je tiens à vous dire que je vous emmerde et je rentre à ma maison."

input_wav = "./input/cartman.wav"

wav = tts.tts(text=text_sample, speaker_wav=input_wav, language="fr")

tts.tts_to_file(text=text_sample, speaker_wav=input_wav, language="fr", file_path="cm-maison.wav")
```

On exécute ça avec:

```
python3 sample.py
```

Et voici le résultat:

<audio controls src="https://resources.dev-freelance.fr/uploads/cm_maison_da932f7d58.wav"></audio>

Enjoy 🥳.

Je trouve que le résultat est vraiment pas mal, en sachant qu'on peut encore faire mieux en réessayant plusieurs fois, ou en améliorant le sample en input.

medium_cloner-voix-python.jpg

small_cloner-voix-python.jpg

thumbnail_cloner-voix-python.jpg

cloner-voix-python.jpg

On va apprendre à utiliser Text-To-Speech en Python pour cloner une voix. Ceci est un exemple avec les samples et le résultat pour que vous puissiez voir à quel point les outils IA d'aujourd'hui sont puissants. 

Je clone la voix de Cartman avec Python, PyTorch et TTS

### Coder, une passion

J'ai toujours aimé coder, j'y passe des heures, à faire des choses, créer des produits, j'aime ça, c'est une passion et vous devez probablement le savoir si vous consulter ce blog. 

Cependant, à un moment, il est vrai que j'aimerais aller plus vite étant donné que j'ai de plus en plus d'idée mais un temps limité. C'est pourquoi je n'ai jamais vraiment eu d'à priori sur l'IA, je pense que c'est un outil génial et j'ai même plutôt hâte de le voir aboutir à son meilleur.

Afin de toujours coder et coder plus vite, je cherche les outils les plus adapter à cette fin.

### Cursor, le nouvel IDE

Connaissez-vous [Cursor](https://www.cursor.com/) ?

Initiallement, moi non plus, mais Elliot, un ami développeur me l'a recommandé. 
Alors je me suis dit "pourquoi pas". Merci à lui de m'avoir fait découvrir ce produit qui jusqu'à présent, m'enchante pleinement.

Il se présente comme un **Visual Code** de premier abord: 

![l'IDE Cursor](https://bo.dev-freelance.fr/uploads/Cursor_7ad4fd0415.jpg)

Mais tout l'intérêt tourne autour de sa capacité d'auto complétion et de suggestion: 

![Autocomplete avec Cursor](https://bo.dev-freelance.fr/uploads/Cursor_autocomplete_13927398e1.jpg)

Ici, comme vous le voyez, je n'ai encore rien tappé, mais **Cursor** me montre déjà ce qu'il souhaite mettre automatiquement. Il suffit de presser _tab_ pour ajouter ces lignes automatiquement au code. 

Là, où il devient intéressant, c'est qu'il analyse le code existant du projet et aura tendance à faire des suggestions qui suivent votre coding style. Ainsi, il ne vous fera pas de suggestions généralistes qui ne correspondent pas à vos attentes.

C'est cela qui fait sa force, à mon gout. Je ne suis pas fan des morceaux de codes copiés depuis **Stackoverflow** qui la plupart du temps ne sont pas optimisés et qui se contente de faire fonctionner les choses. J'ai mon approche perso et j'aime bien que le code suive mes propres guidelines.

Je pense que c'est pour cela que j'ai adopté cet outil.

### L'IA dans tout ça

On le sait, **Copilot** est basé sur l'IA, une sorte de **GPT 3.5** orienté code. L'approche de **Cursor** est à peu près la même, sauf qu'il s'appuie sur un **GPT 4.0** et sur le code existant du projet. 

Vous pouvez afficher une fenêtre interactive pour directement formuler une demande à l'IA:

![Cursor AI panel](https://bo.dev-freelance.fr/uploads/Cursor_AI_pane_c5464517c1.jpg)

Je trouve que ses réponses sont plus précises et nécessitent moins souvent des ajustements. Ayant utilisé **Copilot** dans le cadre du travail, il m'arrive souvent de devoir repasser dessus pour faire fonctionner le tout.

**Copilot** se contente généralement d'auto complete le code à partir des bonnes pratiques ou de la doc. Il faut souvent ajuster avec les variables du projet. Ici **Cursor**, fait le travail pour vous et le fait avec énormément de précision.

Par exemple, il est capable de requêter la bonne table de remonter les bons champs à partir des déclarations **Prisma** du projet. De même, il va automatiquement appeler les bonnes variables et faire toute la vérification de typage au préalable.

En bref, c'est un outil pratique, rapide, efficace qui me permet d'aller encore plus vite. J'ai donc opté pour un abonnement annuel et pour le moment j'en suis plutôt satisfait. 

medium_Futur IDE compressed.jpg

small_Futur IDE compressed.jpg

thumbnail_Futur IDE compressed.jpg

Futur IDE compressed.jpg

Testez Cursor, un IDE boosté à l'IA : plus précis que Copilot, il révolutionne votre façon de coder. Découvrez mon avis complet sur cet outil innovant.

Je teste l'IDE concurrent de Visual Code boosté à l'IA

### La Géorgie pour les techs

Premièrement, parlons du pays. Le pays se veut moderne dans son architecture, dans son mode de vie. Vraiment moderne !

![georgie.jpg](https://bo.dev-freelance.fr/uploads/georgie_848f95c564.jpg)

Vous prenez le bus, en payant en sans contact avec votre **CB** (plutôt que le téléphone, car compliqué pour les vérifications des contrôleurs).

Les caisses automatiques dans plusieurs magasins, de la **4G** partout (oui pas encore de **5G**)..

La population peut sembler froide au premier abord, mais en discutant avec eux vous réaliserez rapidement que ce sont des gens très sympathiques.

Au delà, de l'aspect touristique, car je n'ai pas fait que visiter, j'ai aussi travaillé, et je vais vous parler de comment j'ai pu aménager mes journées et m'organiser professionnellement là-bas.

Avec la France il y a 2 heures de décalage horaire. Etant donné que j'étais sensé déployer notre nouveau système d'**ETL** (Extract Transform Load) chez mon client actuel, je devais rester disponible, joignable et surtout actif pendant mon séjour.

La période d'été étant une période où beaucoup d'internes prennent les congés, nous autres les prestataires, récupérons une partie de la charge pendant ces quelques semaines.

Pour travailler, j'avais plusieurs choix qui s'offraient à moi, rester à l'hôtel pour profiter du confort, de la clim (car dehors il fait 32°) ou encore aller en espace de coworking pour travailler dans un openspace. 

J'en ai fait plusieurs, un espace qui s'appelle Network et un autre qui s'appelle Terminal. Entre nous, j'ai préféré Network. Tout deux coûtent une dizaine d'euros par jour et proposent un confort standard (chaises, tables, wifi, un espace détente, un espace café, les toilettes etc...).

La plupart du temps, ces coworkings sont ouverts H24, donc vous aurez tout le confort d'y aller et d'y restant autant que vous voulez pour travailler.

![georgie 4.jpg](https://bo.dev-freelance.fr/uploads/georgie_4_25a2a0095f.jpg)

### Déploiement d'un ETL 100% custom sur AWS

Avec mon équipe, nous avons développé un **ETL** créé de bout en bout en utilisant **AWS Glue** (**Python**) et en remplaçant un outil vieillissant: **Talend**.

Bien entendu, nous avons travaillé sur ce projet depuis un moment et avons passé beaucoup de temps sur les tests (sur des environnements **UAT**).

Nous sommes très content du résultat en production, tout s'est bien passé, peut être une petite retouche ou deux (comme d'habitude), mais tout est parfait. 

Livrer un produit 100% fiable est non seulement mon objectif, mais surtout me permet de dormir sur mes deux oreilles chaque nuit. 

Avec du recul, je dirai que **Python** n'est pas adapté pour notre utilisation dans ce cas. Même si j'aime beaucoup le langage en tant qu'outil pour faire de la config, des tâches et de l'automatisation, je préfère de loin **Typescript** pour la rigueur dans ce genre de besoin.

Donc je vous recommanderais de partir sur un langage qui vous permet une plus grande robustesse que **Python** dont le typage est uniquement décoratif et pré-runtime.

Quoiqu'il en soit, si vous avez envie d'explorer d'autres contrés et continuer à travailler car notre métier nous permet de le faire aux quatre coins du globe, la Géorgie est un coin très sympa pour s'expatrier quelques temps.

![georgie 2.jpg](https://bo.dev-freelance.fr/uploads/georgie_2_cba7d6a4bc.jpg)



large_georgie 3.jpg

medium_georgie 3.jpg

small_georgie 3.jpg

thumbnail_georgie 3.jpg

georgie 3.jpg

Dernièrement j'ai un peu voyagé en Europe de l'Est, plus précisément en Géorgie, pays pas très connu pour nous autres français, pourtant pays totalement dans l'ère du temps et dans la tendance Tech. J'ai passé une semaine là bas et je vous en parle ici...

Les cowork en Géorgie

Je suis désormais **partenaire de la French Tech Pau Béarn** avec une expertise en **automatisation logicielle** 🎉🎉

![frenchtech.png](https://bo.dev-freelance.fr/uploads/frenchtech_67fe5b3111.png)

Voilà, déjà de quoi se réjouir...

Côté dev, toujours des projets, du Typescript, du Next.js mais j'y reviendrai dans un autre article. 

Vous le savez, c'est un peu les vacances en ce moment. Ceci explique cela... à très vite 😉

harshil-gudka-77zGnfU_SFU-unsplash (1).jpg

medium_harshil-gudka-77zGnfU_SFU-unsplash (1).jpg

small_harshil-gudka-77zGnfU_SFU-unsplash (1).jpg

thumbnail_harshil-gudka-77zGnfU_SFU-unsplash (1).jpg

Je sais, cela fait un petit moment que je n'ai pas écrit ici. J'ai fait pas mal de choses, pris quelques vacances et entre temps il s'est passé cela...

Quick update

### Le nouveau mouvement anti-TDD

Beaucoup de développeurs qui se sont mis à **Typescript** dernièrement se sont sentis pousser des ailes grâce à ses fonctionnalités de vérification en temps réel du matching des typages directement dans l'**IDE**. Il est vrai que cette approche de développement, par opposition au **JavaScript**, change énormément de choses et réduit déjà un grand nombre d'erreurs possibles avant même l'exécution. Je n'ai rien à redire là-dessus, je suis totalement convaincu qu'il y a un changement radical entre **TS** et **JS** avec une nette amélioration de la capacité à anticiper les bugs.

Cependant, ce mouvement va très loin, en allant même jusqu'à renier les méthodes **TDD** et les juger inutiles sur la base des vérifications **TS** uniquement. Ce mouvement a été renforcé par l'accélération des projets de type **startup/POC**. On veut faire du _quick and dirty_, on veut aller vite et sortir quelque chose, privilégier la rentabilité contre la fiabilité. Cependant, je pense qu'il y a un souci avec cette façon de penser. La fiabilité ne doit jamais être opposée à la rentabilité. Les meilleures applications et les applications qui durent dans le temps ont souvent réussi à allier les deux : _rester fiables et rentables, grâce à un équilibre subtil entre les tests et la sortie de fonctionnalités_.

L'idéal est de garder le maximum de performance en ne faisant pas trop de compromis sur la fiabilité. Entre nous, aux deux extrêmes, nous assistons à des points de vue aberrants, entre ceux qui veulent un coverage de 100 % et ceux qui ne veulent absolument pas faire de tests, je peux vous garantir que personne n'a raison dans ces extrêmes. J'ai vu trop de projets se planter lamentablement à cause de problématiques issues de ces points de vue :

- le 100 % coverage qui ne sort quasiment aucune feature,
- le no TDD qui est une passoire à bugs.

Et pour vous citer encore **Clean Code**, il y a trop de boîtes qui ont négligé les tests pendant très longtemps, jusqu'au jour où elles se sont mises à **bugfix** mais perdaient des dizaines de milliers d'utilisateurs par jour à cause des bugs. Dans ces moments-là, il est probablement déjà trop tard pour se dire : "Ah mais si on faisait du code fiable". Bravo, vous avez juste réussi à couler votre boîte !

### Le problème des projets non testés

Je peux vous assurer qu'un projet sans aucun test, c'est l'enfer sur terre et j'en ai déjà fait les frais. 🥵

Lorsque vous travaillez en équipe, chaque commit est susceptible de casser un comportement et de créer un bug, car des développeurs poussent souvent leurs modifications sans tenir compte d'un comportement voulu ou attendu initialement, mais plutôt sur un besoin spontané.

L'absence de tests ne permet pas d'intercepter les régressions à ce moment.

De même, sur un projet de taille conséquente, l'absence de tests ne donne aucune ligne directrice sur ce qui est attendu comme cheminement vers une fonctionnalité. Les développeurs auront tendance à créer plein de libs et de fonctions sans savoir s'ils vont s'en servir réellement. Bonjour la perte de temps !

Le risque encouru est d'entretenir une dette tellement lourde qu'il faudrait des semaines voire des mois pour repasser dessus. De nombreux projets n'ont pas surmonté cette épreuve car c'est un moment stressant et sollicitant financièrement avec un risque quotidien de **churn client** (churn : le client arrête d'utiliser vos services).

En vous rappelant que tout cela aurait été évité avec de l'organisation et de la rigueur. Faire du TDD c'est aussi faire preuve de responsabilité, vis-à-vis de la boîte et vis-à-vis des clients.

Des sociétés telles que **Knight Capital Group** ont coulé à cause de bugs qui généraient des trades erronés sur une période de 45 minutes, entraînant une perte de 440 millions de dollars, un incident qui a coûté **75 % du capital de la compagnie**. En 45 minutes !!! 🥵

### Trouver l'équilibre dans la mise en place de TDD

Pour faire efficacement du **TDD**, il ne suffit pas de tout tester et d'avoir un coverage de 100 % et une inertie digne d'un paquebot.

Le fait de faire des tests, c'est aussi imposer un fonctionnement attendu pour un composant. Par exemple, un argument supplémentaire et obligatoire dans une fonction qui n'en attendait pas initialement, c'est potentiellement une régression à d'autres endroits du code.

Passer les tests avant de pouvoir push son code, c'est bien souvent : s'assurer que ce qu'on envoie ne casse pas un comportement voulu.

De même, le **TDD** aide au développement, lorsque l'on est en train de construire une fonctionnalité complexe qui s'appuie sur un enchaînement de fonctions pour le moment encore inexistantes. Il va donner une ligne directrice sur les fonctions que l'on aura à livrer et permettra d'anticiper le comportement attendu de chaque fonction, en matérialisant la spécification de ces fonctions.

Si l'on retire cette partie, notamment dans les projets de taille moyenne voire grande, il peut être difficile de savoir où va mener une implémentation car les équipes n'ont aucune direction, les **TDD** auraient pu jouer un rôle de balise dans ce brouillard.

En sachant que plus vous avancez dans votre projet, plus vous entrevoyez l'objectif de manière claire et précise, il se peut que vous ayez à repasser sur les tests pour leur donner une direction nouvelle, mais au moins, la direction existe, elle est posée et le cadre est donné.

**Bilan après plusieurs années de TDD**

Mes recommandations sont les suivantes :

- Mettre en place le **TDD** sur les fonctionnalités clés de votre application.
- Avoir une attention particulière sur les chemins les plus critiques : paiement, manipulation de données clients, manipulation de documents, exposition de données confidentielles...
- Ne pas aller trop loin en faisant du **TDD** sur les libs externes utilisées (ce sont aux libs de tester leur code et il est de votre responsabilité de faire un choix avisé lorsque vous sélectionnez vos dépendances), en revanche, tester la combinaison de plusieurs libs dans des **TDD** peut se faire si vous pensez que l'on arrive à un niveau de complexité nécessitant une vérification.

Depuis que je travaille en **TDD**, je dois admettre que je suis bien plus serein sur ce que je livre et je dors sur mes deux oreilles. Ce sentiment n'a pas de prix en tant que développeur, et je ne peux que vous recommander cette méthodologie. À moins de n'avoir absolument aucune conscience professionnelle, je ne sais pas comment font ceux qui disent s'en passer.

large_dev-02.jpg

medium_dev-02.jpg

small_dev-02.jpg

thumbnail_dev-02.jpg

dev-02.jpg

Explorez les débats autour du TDD : découvrez mon retour d'expérience et mon avis sur cette méthodologie de développement contestée par certains courants.

Le TDD est-il inutile ?

## Le Clean Code

Alors, j'admets que je ne suis pas du genre à suivre au pied de la lettre tous les fondamentaux du Clean Code. 

Robert C. Martin m'excusera, mais je pense qu'étant donné que je suis seul, j'adapte à mes besoins (vitesse d'exécution, taille des projets...) ses précieux outils et conseils.

Cependant, je ne plaide pas coupable pour autant, car je maintiens qu'un savant mélange des bonnes pratiques permet:
- de ne pas se perdre
- d'avancer vite
- d'avoir un modèle pour chaque item de notre projet
- de réduire les bugs
- de savoir ce que l'on fait

Aujourd'hui, nous allons nous attarder sur comment j'organise la logique métier dans mes projets **Next.js** en **Typescript**. Il s'agit d'une première partie de plusieurs articles où je m'attaquerai ensuite aux composants, etc...

### Mon modèle de Clean Code sur l'implémentation de la logique métier

Bien entendu, il ne s'agit que d'un exemple, et nous savons tous qu'il y a d'innombrables possibilités mais nous devons en choisir certaines, quand nous sommes seuls sinon, nous passerons plus de temps à organiser ce que l'on fait plutôt que de coder des fonctionnalités.

Je vous partage ici le fruit d'une mûre réflexion bâtie sur des dizaines de projets menés à terme. C'est pourquoi je vous parle d'équilibre, car nous pouvons toujours pousser le concept plus loin, mais ces projets n'ayant pas été aboutis, je n'ai pas retenu ces méthodos d'organisation pour vous le partager ici.

Voici comment je procède:

![Typescript structure ><](https://bo.dev-freelance.fr/uploads/ts_org_drawio_bcaef5e977.png)

### Explications

Avant toute chose, les briques **Database Type** et **Model abstract class** sont des outils que j'utilise pour l'interfaçage. 

#### Les classes Service

J'utilise des classes de **Service** en backend, qui vont me permettre de manipuler des classes de **Model abstrait** (par exemple le model **User** ou **Company**)

Les services peuvent faire des appels croisés par exemple la création d'une **Company** par **CompanyService** fera un update d'un **User** pour renseigner le champs company_id de ce **User**. On peut y stocker des dépendances de logique métier et opérations multi entités.

Les services s'appuieront sur mes classes de **Persist** pour communiquer avec la base de données. 

#### Les classes Persist

Les classes Persist manipulent des objets de type **Database** (qui sont des objets **serializables** de type primitif car il s'agit des données en base) les types **Database** utilisent souvent un format **snake_case**.

A chaque fois que j'ai besoin d'interagir avec un composant métier de mon application (les utilisateurs, les sociétés, les adresses etc...), je passe par mes classes **Service** et en aucun cas par les classes de type **Persist**. 

Les classes **Persist** sont uniquement utilisables en backend, elles respectent le **SRP** (Single Responsability Principle) et se concentrent sur leur scope. 

Par exemple, la classe **UserPersist** ne peut pas écrire dans les tables **Company** et vice versa.

#### Les types Database

Les types **Database** sont les types que j'utilise pour toutes les interfaces entrées/sorties vers la base de données, ou client/server. 

J'utilise des types **Typescript**, car ils sont serializables et s'appuient sur des primitives. Ce qui signifie qu'un **JSON.stringify** passe sans broncher et qu'ils peuvent être **dehydrated** pour des rendus de pages serveur etc...

J'utilise ces types pour mes classes d'interfaces comme les classes **Persist** qui communiquent avec la base ou encore mes hooks **react-query** lorsque j'appelle mon **API**.

En dehors de ces composants d'interface, je ne manipule pas mes types **Database**. Car le type **UserDatabase** par exemple, n'est qu'un type avec des champs au format **snake_case** et se concentre sur la gestion des propriétés d'un item **User** en base. 

Notez que j'ai employé le mot clé **Database**, car au nommage, j'ai préféré **UserDatabase** plutôt que **UserRecord** car **Record** est un mot clé ayant lui-même un sens particulier en **Typescript**.

#### Les classes Model

Ma classe abstraite **UserModel** est beaucoup plus puissante car non seulement, elle est isomorphique (s'utilise en back comme en front), elle passe mes champs au format **camelCase**, mais en plus elle me donne la possibilité de faire des méthodes très utiles pour la suite. 

Par exemple: **UserModel** peut disposer d'une propriété **addresses** de type **Address[]**, alors que ces éléments en base sont stockés dans une autre table.

En revanche, je m'organise toujours de manière à ce qu'une classe **Model** ne fasse jamais la manipulation de la base lui même, afin de rester isomorphique. Le but étant de permettre au frontend de manipuler des classes **Model** sans avoir à accéder aux données directement. 

De même, je donne à mes classes **Model** les méthodes suivantes, via l'implémentation d'une classe abstraite **DatabaseModel**: 
- static fromDatabaseObject(typeDatabase): Model
- toDatabaseObject(): TypeDatabase

Ce qui me permet de toujours serializer mon **Model** pour en faire un type **Database** avant persist, ou de les manipuler en tant que classe **Model** après récupération des types **Database** depuis un appel **API**.

### Exemple

Nous allons implémenter l'organisation ci-dessus concernant la table adresse des utilisateurs. Chaque utilisateur peut avoir plusieurs adresses stockées en base. 

Je vais vous donner un exemple avec une classe **AddressService**.

Les classes **Service** manipulent des classes **Model** et appellent les classes **Persist** via des interfaces typés en objet **Database** qui, je le rappelle, sont des primitives.

La chaîne complète ressemble à ceci:

![Service_to_Persist.drawio.png](https://bo.dev-freelance.fr/uploads/Service_to_Persist_drawio_1d2608ceab.png)

> Dans les exemples, je ne mets pas toujours les types de retour car ces derniers sont inféré automatiquement, bien que j'en ai ajouté certaines pour que cela soit plus lisible.

```tsx
import { AddressPersist } from "@/backend/database/persist/addresses"
import { BookingPersist } from "@/backend/database/persist/bookings"
import { Address } from "@/models/address"
import { AddressDatabase } from "@/types/address"

export class AddressService {
 static async getById(addressId: number): Promise<Address> {
 const address = await AddressPersist.getById(addressId)
 return Address.fromDatabaseObject(address)
 }

 static async listByUserId(userId: number): Promise<Address[]> {
 const userAddresses = await AddressPersist.listByUserId(userId)
 return userAddresses.map((addressDatabase) =>
 Address.fromDatabaseObject(addressDatabase)
 )
 }

 static async insert(newAddress: AddressDatabase): Promise<Address> {
 const address = await AddressPersist.insert(newAddress)
 return Address.fromDatabaseObject(address)
 }

 static async update(
 addressId: number,
 updatedAddress: Partial<AddressDatabase>
 ): Promise<Address> {
 const address = await AddressPersist.update(addressId, updatedAddress)
 return Address.fromDatabaseObject(address)
 }

 static async delete(addressId: number): Promise<boolean> {
 const address = await this.getById(addressId)

 const upcomingBookingsByAddress =
 await BookingPersist.listUpcomingBookingsByAddressId(addressId)

 const hasUpcomingBooking = upcomingBookingsByAddress.length > 0

 if (hasUpcomingBooking) {
 throw new Error("forbidden_delete_address_with_bookings")
 }

 if (address) {
 await AddressPersist.delete(addressId)

 if (address.defaultAddress) {
 const addressList = await AddressPersist.listByUserId(
 address.userId!
 )

 if (addressList?.[0]) {
 await AddressPersist.update(addressList[0].id!, {
 default_address: true
 })
 }
 }
 return true
 }

 return false
 }
}

```

Comme vous le voyez peut être j'utilise toujours le prefix list... lorsque je vais retourner un **Array**, cela me permet de comprendre le type et la structure de ce que retourne ma méthode par le nom. Je me dis qu'un get renvoie un **Objet**, donc list réfère plus facilement à un **Array**.

Dans l'exemple ci-dessus, la méthode **delete**, permet de faire des vérification sur les **Bookings** à venir, et savoir si oui ou non j'ai le droit de supprimer cette **Adresse**. Vérification que je ne peux pas me permettre de faire directement sur la couche **Persist** qui ne doit pas agir en dehors de son scope. 

Dans le cas où je supprime cette adresse, une autre deviendra l'adresse par défaut si l'utilisateur possède plusieurs adresses.

Par ailleurs, on aurait pu se poser la question de pourquoi je ne prends pas le type **Model** en input dans le **Service**, et bien ce type étant une classe complexe et pas un objet serializable, il serait plus difficile de prendre en entrée une composition de clé issue de plusieurs variables ou objets. 

---

Pour mes classes **Model**, j'étais initialement parti sur une classe abstraite, mais j'ai basculé sur une interface que j'ai nommé **DatabaseModel** à chaque fois que je code une classe représentant une table dans la base de données, car **DatabaseModel** implémente les méthodes de serialization. (Notez que les deux approches sont possibles.)

Bien entendu, je n'implémente pas la classe **DatabaseModel** pour toute classe **Model** "virtuelle", qui me sert surtout de classe **Helper**.

```tsx
export interface DatabaseModelConstructor<T> {
 new (): T
 fromDatabaseObject(databaseObject: any): T
}

export interface DatabaseModel {
 toDatabaseObject(): any
}
```

Voici ma classe **Model** pour **Address**: 

```tsx
import { AddressDatabase } from "@/types/address"

import { DatabaseModel, DatabaseModelConstructor } from "./model"

export class Address implements DatabaseModel {
 id?: number
 street: string = ""
 street2: string = ""
 addressInfo: string = ""
 zipCode: string = ""
 city: string = ""
 country: string = ""
 defaultAddress: boolean = true
 createdAt?: Date
 updatedAt?: Date
 userId: number | null = null

 constructor() {}

 static fromDatabaseObject(addressDatabase: AddressDatabase): Address {
 const address = new Address()

 address.id = addressDatabase.id
 address.street = addressDatabase.street
 address.city = addressDatabase.city
 address.country = addressDatabase.country
 address.zipCode = addressDatabase.zip_code
 address.userId = addressDatabase.user_id
 address.defaultAddress = addressDatabase.default_address
 address.createdAt = addressDatabase.created_at
 if (addressDatabase.updated_at)
 address.updatedAt = addressDatabase.updated_at
 if (addressDatabase.address_info)
 address.addressInfo = addressDatabase.address_info
 if (addressDatabase.street_2) address.street2 = addressDatabase.street_2

 return address
 }

 toDatabaseObject(): AddressDatabase {
 return {
 id: this.id,
 street: this.street,
 street_2: this.street2,
 city: this.city,
 country: this.country,
 zip_code: this.zipCode,
 default_address: this.defaultAddress,
 user_id: this.userId!,
 ...(this.createdAt ? { created_at: this.createdAt } : {})
 }
 }
}

const AddressConstructor: DatabaseModelConstructor<Address> = Address;

```

Le **Model** s'utilise comme ceci:
![Abstract_Model.drawio.png](https://bo.dev-freelance.fr/uploads/Abstract_Model_drawio_165f7b65b3.png)

On peut accessoirement ajouter d'autres méthodes pour compléter cette classes avec des utilitaires.

---

Voici ma classe **Persist** pour **Address**:

```tsx
import { AddressDatabase } from "@/types/address"

import prisma from "../prismaClient"

export class AddressPersist {
 static async getById(addressId: number) {
 const address = await prisma.address.findFirst({
 where: {
 id: addressId
 }
 })
 return address as AddressDatabase
 }

 static async listByUserId(userId: number) {
 const addresses = await prisma.address.findMany({
 where: {
 id: userId
 }
 })
 return (addresses as AddressDatabase[]) ?? []
 }

 static async insert(newAddress: AddressDatabase) {
 const address = await prisma.address.create({
 data: newAddress
 })
 return address as AddressDatabase
 }

 static async update(
 addressId: number,
 updatedAddress: Partial<AddressDatabase>
 ) {
 const address = await prisma.address.update({
 where: {
 id: addressId
 },
 data: updatedAddress
 })
 return address as AddressDatabase
 }

 static async delete(addressId: number) {
 await prisma.address.delete({
 where: {
 id: addressId
 }
 })
 return true
 }
}

```
La classe Persist est la couche d'accès à l'**ORM**, dans mon cas, j'utilise **Prisma**.

---

Enfin voici mon type **Database**, il s'agit du type que j'utilise comme input sur tous les points d'entrées nécessitants une _serialization_, pour aller vers la base, ou pour un appel **API**. 

```tsx
export type AddressDatabase = {
 id?: number
 user_id: number
 street: string
 street_2?: string
 address_info?: string
 zip_code: string
 default_address: boolean
 city: string
 country: string
 created_at?: Date
 updated_at?: Date
}
```

Le champs **id** n'est pas par défaut car cela me permet d'utiliser ce type pour mes formulaires **react-hook-form** par la suite.

---

Bon, vous l'aurez compris, il s'agit d'une organisation parmis tant d'autres et ce modèle est perfectible. Mais je suis satisfait de l'organisation et de l'effet "no brainer" qu'il apporte à mon code car cette structure me permet de savoir instinctivement: 
- où sont les choses
- qui doit faire quoi
- qu'est-ce que j'ai le droit de faire depuis un composant

Par ailleurs, afin de délimiter les choses et éviter les erreurs, j'ai ajouté une règle eslint dans mon fichier **.estlintrc.json**.

```json
{
 "extends": "next/core-web-vitals",
 "rules": {
 "import/no-restricted-paths": [
 "error",
 {
 "zones": [
 {
 "target": "./src/frontend",
 "from": "./src/backend"
 }
 ]
 }
 ]
 }
}
```

De cette manière je ne risque pas d'importer du code destiné au backend sur mes composants front.

![eslint error interception ><](https://bo.dev-freelance.fr/uploads/Capture_d_ecran_2024_06_09_a_23_24_14_e7407092c9.png)

C'est davantage de temps de cerveau disponible pour réfléchir à comment répondre aux problématiques métiers car je ne me pose plus ces questions.

Ces règles délimitent énormément l'impact d'un bloc sur l'autre, cela me permet de repérer et régler un bug plus facilement. Par exemple, si l'écriture en cascade sur différentes tables ne fonctionne pas pour un **Service**, cela ne signifie pas que l'écriture seule ne fonctionne pas pour la couche **Persist**. 

Ainsi, je sais qu'il appartient à la logique du **Service** d'apporter les vérifications nécessaires et les champs obligatoires à chaque appel de méthode de la couche **Persist**. 

De toute façon, à plus haut niveau **Typescript** fait déjà bien son travail de garde fou sur les déclarations.

Voilà, c'était très dense, j'espère que vous avez pu en sortir quelque chose de ce contenu qui demande beaucoup de travail et qui m'a demandé énormément de pratique pour vous le fournir en garantissant son fonctionnement et ses promesses d'organisation.

large_next-ts-org.jpeg

medium_next-ts-org.jpeg

small_next-ts-org.jpeg

thumbnail_next-ts-org.jpeg

next-ts-org.jpeg

Adoptez des pratiques et méthodologies adaptées à vos projets de développement Typescript pour une organisation efficace et des outils vraiment utiles à vos besoins.

Découvrez tous nos articles - page 1 sur 11