PascalLeMerrer/craft-letter
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Fix typos in newsletter #5

Browse source
This commit is contained in:
Pascal Le Merrer 2026-01-04 18:30:18 +01:00
parent cc5fb290ec
commit a5f9c7c2a1
1 changed files with 2 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

5
content/newsletter/craft-letter-5.md
View file

@ -48,7 +48,7 @@ Par exemple, le requêtage des éléments des pages HTML se base essentiellement
## Podcast Code Garage ## Podcast Code Garage
Le [podcast Code Garage](https://code-garage.com/podcast?tab=classic) 🇫🇷 est celui du site du même nom, qui propose des cours en ligne. Le [podcast Code Garage](https://code-garage.com/podcast?tab=classic) 🇫🇷 est celui du site du même nom, qui propose des cours en ligne.
Dans des épisodes dont la plupart sont courts (moins de quinze minutes en général), Nicolas Brondin-Bernard explique les bases d'une techno, ou son historique. Dans des épisodes dont la plupart sont courts (moins de quinze minutes en général), Nicolas Brondin-Bernard explique les bases d'une techno, ou son historique.
Quelques épisodes plus longs sont consacrés à des interviews. Quelques épisodes plus longs sont consacrés à des interviews.
@ -61,8 +61,7 @@ Plus de 150 épisodes sont disponibles à ce jour.
## Le coût caché des buzzwords dans la tech ## Le coût caché des buzzwords dans la tech
Jernej Klancic raconte quelques anecdotes dans lesquelles [l'adoption irréfléchie d'une techno ou d'un principe qui faisait le buzz](https://engineering.leanix.net/blog/trade-offs/) 🇬🇧 lui a jouée de mauvais tours. Jernej Klancic raconte quelques anecdotes dans lesquelles [l'adoption irréfléchie d'une techno ou d'un principe qui faisait le buzz](https://engineering.leanix.net/blog/trade-offs/) 🇬🇧 lui a jouée de mauvais tours. Il a établi une liste de questions à se poser avant de prendre une décision de ce type.
Il a établi une liste de questions à se poser avant de prendre une décision de ce type.
J'ajoute ma propre recommandation : quand ces décisions impactent l'architecture du logiciel que vous développez, je vous invite à les tracer dans un [Architecture Decision Record](https://github.com/joelparkerhenderson/architecture-decision-record?tab=readme-ov-file#what-is-an-architecture-decision-record) (ADR) 🇬🇧, en explicitant les avantages et inconvénients de la techno choisie. C'est un document simple, idéalement au format markdown, qui est suivi sous Git, à côté du code. Dans ce document vous décrivez un problème à résoudre, les solutions que vous avez envisagées, celle que vous avez retenue et pourquoi. Vous notez aussi les conséquences de ce choix, qu'elles soient positives ou négatives. Pourquoi faire ça ? D'une part cela oblige à se poser un minimum de questions lors d'un choix d'architecture, et cela permet de partager ses réflexions avec le reste de l'équipe. D'autre part, cela permet de garder une trace, qui pourra s'avérer utile à l'avenir : quand dans quelques années, quelqu'un se demandera pourquoi telle techno a été choisie, il en trouvera les raisons dans un ADR ; et pourra ainsi juger s'il est pertinent ou pas de remettre en cause ce choix. J'ajoute ma propre recommandation : quand ces décisions impactent l'architecture du logiciel que vous développez, je vous invite à les tracer dans un [Architecture Decision Record](https://github.com/joelparkerhenderson/architecture-decision-record?tab=readme-ov-file#what-is-an-architecture-decision-record) (ADR) 🇬🇧, en explicitant les avantages et inconvénients de la techno choisie. C'est un document simple, idéalement au format markdown, qui est suivi sous Git, à côté du code. Dans ce document vous décrivez un problème à résoudre, les solutions que vous avez envisagées, celle que vous avez retenue et pourquoi. Vous notez aussi les conséquences de ce choix, qu'elles soient positives ou négatives. Pourquoi faire ça ? D'une part cela oblige à se poser un minimum de questions lors d'un choix d'architecture, et cela permet de partager ses réflexions avec le reste de l'équipe. D'autre part, cela permet de garder une trace, qui pourra s'avérer utile à l'avenir : quand dans quelques années, quelqu'un se demandera pourquoi telle techno a été choisie, il en trouvera les raisons dans un ADR ; et pourra ainsi juger s'il est pertinent ou pas de remettre en cause ce choix.