Don't Repeat Yourself… but un peu quand-même
Mieux vaut un peu de duplication assumée qu'une abstraction prématurée qui mélange des règles métier qui n'ont rien à faire ensemble.
Articles étiquetés « Artisanat/craft »
LLMs : vous voilà manager, que ça vous plaise ou non
Coder avec un LLM, c'est comme manager une équipe : il faut doser la délégation et progresser par petits pas.
Bug, erreur ou cas nominal : quelle intention métier ?
Quand faut-il lancer une exception, retourner une erreur ou modéliser l'absence ? La réponse se trouve dans l'intention métier.
Design tokens : la grammaire de votre Design System
Avant les composants, les tokens. Comment structurer un Design System cohérent grâce à une architecture de tokens bien pensée.
Architecture hexagonale : faut-il encore un ORM ?
Un ORM vous propose de bâtir le domaine sur des entités qu'il expose, directement mappées à la base de données. Le contraire de l'Architecture Hexagonale.
Et si votre modèle TypeScript empêchait les états incohérents ?
TypeScript n'est souvent utilisé qu'en surface. C'est vrai en particulier pour les Union Types, qui permettent d'empêcher des états incohérents.
Vous utilisez mal les exceptions
Les exceptions ne sont pas faites pour gérer les erreurs prévisibles. Découvrez le type Result, alternative au try/catch.
Tester le hasard : un cas d’école du Property-Based Testing
Le PBT teste qu'un invariant métier est toujours vérifié quels que soient les paramètres et la valeur de retour de la fonction objet du test.
Whatever Works
Un appel au pragmatisme en matière de développement logiciel : éviter le dogme, observer ce qui fonctionne et laisser la place au doute.
La qualité logicielle, c'est aller vite, longtemps
Aller vite est facile. Maintenir ce rythme pendant des années est plus difficile et signe la vraie qualité logicielle.
Bugs : le développeur, un coupable trop facile
Incriminer les développeurs est facile. Mais les bugs naissent aussi de la conception, de l'organisation et de la culture.
Domain-Driven Design : pourquoi le modèle universel n'existe pas
Un modèle n’est jamais une représentation fidèle de la réalité, mais une abstraction conçue pour un objectif précis. Un modèle n’existe que par son usage.
Heures et malheurs de l'optimisation
Un exemple d'optimisation d'algorithme (le jeu du gratte-ciel), et les enseignements que l'on peut en tirer. La loi de Pareto s'applique pleinement.
L'Architecture hexagonale : développer en partant du domaine
L'Architecture hexagonale, formalisée par Alistair Cockburn, vise à isoler le domaine. Elle repose sur l'inversion et l'injection des dépendances.
Command Query Responsibility Segregation
Le CQRS repose sur l'idée de distinguer les modèles d'écriture et de lecture, quand les opérations sont fortement asymétriques. À utiliser avec parcimonie.
100% code coverage : la course à l'échalote
Cet indicateur n'est pas très utile si l'on ne sait pas ce qu'on met derrière… Elle reste cependant interprétable essentiellement quand elle est faible !
50 shades of tests
Tous les tests ne rentrent pas dans une seule pyramide de tests. Il faut envisager plusieurs aspects : finalité, granularité et modalité d'assertion.
Une architecture qui laisse des portes ouvertes
« The job of an architect is to build a structure that allows decisions to be delayed as long as possible » : 5 exemples illustrant le propos d'Uncle Bob.
Tests end-to-end : comment démarrer du bon pied
Les tests end-to-end doivent être utilisés avec parcimonie, car ils sont coûteux à écrire (Page Model) et coûteux à exécuter. Voici comment procéder.
Produit : quand on s'attache à son bébé
On s'occupe d'un produit, on le fait grandir, on prend soin de lui jour après jour comme on prend soin d'un bébé. On s'y attache, et c'est très bien.
Architecture Decision Record
L'ADR permet de rationaliser les décisions d'architecture d'une équipe et d'éviter qu'elles ne soient sans cesse remises en question.
Don't write code that guesses the future
Évitez de sur-anticiper : ne posez pas les bases de fonctionnalités futures, elles restent hypothétiques. Écrivez plutôt du code qui pourra évoluer.
« User » n'est pas un Bounded Context — et pourtant, l'utilisateur compte
On ne s'adresse pas à tous les utilisateurs de la même manière. À chaque persona son langage, et donc son contexte, et son BFF (Backend For Frontend).
Votre code est-il universalisable ?
L'écologie et la qualité logicielle ont en commun l'Universalisabilité kantienne : mon action ne peut être bonne que si tout le monde peut faire comme moi.
You build it, You run it
Cette phrase, mantra du DevOps, est marquée au coin du bon sens. Pourtant, l'organisation s'oppose parfois à sa mise en œuvre. CEO, préparez le terrain.
Refactoring : éviter l'effet tunnel
Tant que tout n'est pas fait, c'est comme si rien n'était fait. Pour éviter l'effet tunnel d'un refactoring : le pattern Strangler Fig, qui fait coexister l'ancien et le nouveau.
Modular Monolith is the new Microservices
Vous n'avez probablement pas besoin de ces microservices, si difficiles à déployer. Le monolithe, à condition qu'il soit modulaire, est fait pour vous.
Walking Skeleton
Le Walking Skeleton a pour vocation de poser des fondations saines pour aller au MVP en minimisant la dette technique. Une étape que l'on gagne à formaliser.
L’Example Mapping, la pratique agile la plus sous-estimée
Une erreur serait de croire que la conception fonctionnelle est l'apanage du PM : on réfléchit mieux à plusieurs et sur base d'exemples concrets.
Le Trunk-Based Development, une solution radicale au « merge hell »
Le Trunk-Based Development, tout droit issu de l'Extreme Programming, est une excellente alternative à GitFlow, mais étudiez bien les prérequis.
Bounded contexts 101
2 erreurs courantes du découpage en Bounded Contexts : le découpage en couches techniques et le découpage par entités. Pensez verbes d'action !
Un objet n'est pas ce que vous croyez
Construire un objet, c'est partir du comportement. La donnée qu'il encapsule s'en déduit et constitue un détail d'implémentation.
Bug or feature?
Dans un système legacy dont beaucoup de systèmes dépendent, corriger un bug n'est pas toujours recommandé. Mieux vaut l'isoler et le maintenir.
Je ne vous vendrai pas de formation « Clean Code »
Clean Code est un livre de référence : une lecture linéaire, de A à Z, n'aurait que peu de sens. Il faut lire, expérimenter et y revenir fréquemment.
Librairie vs. framework
Vous appelez une librairie, mais c'est le framework qui vous appelle. La différence, c'est l'inversion de contrôle.
Coaching is language agnostic
Travailler la qualité logicielle, c'est travailler les architectures, paradigmes et méthodologies, en particulier le clean code. Le langage importe peu.
Le Test-Driven Development, un outil parmi d'autres
S'il est un outil merveilleux, le TDD ne se prête pas à tous les développements, au risque de tomber dans la loi de l'instrument.
Refactoring : pallier l'effet tunnel grâce à la méthode Mikado
La méthode Mikado consiste à cartographier les dépendances du refactoring, puis à refactorer en partant des feuilles de l'arbre ainsi établi.
Emulation de typage nominal en TypeScript
Le typage structurel est limitatif lorsqu'on veut faire de la programmation défensive. Heureusement, il est possible d'émuler un typage nominal (branding).
Vous faites erreur…
Il faut distinguer les erreurs de développement, que l'on traite avec des exceptions, des erreurs de saisie utilisateur.
Portrait de développeur : Clément Cornen
Portrait de Clément Cornen, développeur et avant tout ami. Nos valeurs sont très proches, dans le développement comme dans la vie.
3 métaphores du code informatique
Le code est immatériel. Alors, pour le rendre plus intelligible, on a recours à des métaphores du monde concret, en particulier le patrimoine immobilier.
Architecture hexagonale : de deux maux il faut choisir le moindre
L'Architecture Hexagonale vise à isoler l'application et le domaine de l'infrastructure. Le prix à payer, c'est que l'infrastructure connaît le domaine.
DDD stratégique vs. DDD tactique
Travaillez d'abord la modularité du système à grande échelle (DDD stratégique). Les patterns tactiques ont leur importance, mais ils viennent après.
TDD is dead. Long live testing.
Une contre-argumentation point à point à l'article phare de David Heinemeier Hansson, détracteur du Test-Driven Development.
DevOps : le grand malentendu
À mesure qu'elle s'est popularisée, l'approche DevOps s'est éloignée de l'esprit originel, allant parfois jusqu'au contresens. Mettons les pendules à l'heure.
Parce que la forme est contraignante, l'idée jaillit plus intense
Les kata de code sont le lieu parfait pour expérimenter de nouvelles façons de travailler, en posant des contraintes. Exemple : coder à l'aide du seul clavier.
Event-Driven Architecture ou Event Sourcing ?
EDA : une modalité de communication favorisant le découplage des contextes ; ES : un modèle d'écriture dédié à la traçabilité au sein d'un contexte.
5 questions à Antoine Sauvage, CTO d'Ovrsea
La parole est donnée à l'un de mes clients, Ovrsea. Antoine, CTO, explique comment est venue l'idée de faire accompagner ses équipes et ce que ça a changé.
Danger zone
En se popularisant, l'Agilité a été dévoyée, devenant synonyme de micro-management et de pratiques absurdes. Pourtant, on a plus que jamais besoin d'Agilité.
JavaScript : quand le compilateur, c’est vous
Je mets au défi quiconque de me prouver qu'il est plus efficace de se passer de typage statique pour construire une application JavaScript.
Vos premiers pas dans l'artisanat logiciel
Le Clean Code est un bon point d'entrée, suivi par le TDD et la Programmation Fonctionnelle. Attendre un peu pour le DDD et le refactoring !
Refactoring : la technique du Golden Master
La méthode du Golden Master vise à éviter les régressions lors d'un refactoring et repose sur la création préalable d'une trace de logs fonctionnels.
Les architectures restent, les technos s'envolent
Les technologies sont éphémères : investissez dans la maîtrise des architectures, paradigmes et méthodologies, qui vous accompagneront toute votre vie.
I love Kubernetes
Les technologies sont belles, elles fascinent, mais elles ne sont pas une fin en soi. L'informatique est là pour résoudre des problèmes de manière pragmatique.
Tout ce que vous avez toujours voulu savoir sur le refactoring
Le refactoring va avec 2 défis : éviter les régressions et pallier l'effet tunnel. Pour vous aider : Golden Master, Méthode Mikado et pattern Strangler Fig.
Le mur de la dette
La dette technique est dangereuse parce qu'elle s'accumule en silence, jusqu'au jour où l'entreprise frappe le mur. CEO, prenez les devants.
Pourquoi le logiciel coûte-t-il cher ?
Écrire du code n'est pas si compliqué, c'est le faire évoluer qui l'est. Lisibilité, testabilité, modularité : les 3 piliers de l'artisanat logiciel.