J’ai le plaisir de vous annoncer que j’ai obtenu une nouvelle certification : OCI Certified Developer Professional de Oracle ! Première certification de l'année 2026 ! Ravis de débuter cette nouvelle année avec cette certification qui enrichit mon expertise cloud. #Oracle #OracleCloudDeveloper #OCIDeveloperProfessional

🚧 Pourquoi la plupart des développeurs écrivent mal leurs tests unitaires (et comment y remédier) Dans le cadre du TDD ou non, beaucoup de développeurs adoptent une approche courante mais problématique : Considérer une "classe" comme l'unité d'isolation. Selon Uncle Bob (Robert C. Martin), cette pratique découle d'une méprise. On crée souvent une correspondance un-à-un entre les classes de production et de test, en écrivant une méthode de test par méthode de production et en mockant toutes les dépendances, même celles qui n'ont pas de sens à mocker. Logique au départ, cette méthode vise à tester chaque élément du système. Pourtant, elle pose problème. Le couplage structurel est le principal écueil. Lorsque les tests sont liés à la structure interne du code (classes, méthodes), un refactoring comme « modifier une signature de méthode » « déplacer une méthode » ou « diviser une classe » casse les tests. Cela double l'effort : Refactoriser le code est nécessaire, mais réparer les tests devient une perte de temps. Résultat ? Un code difficile à maintenir, des modifications futures coûteuses, et une livraison plus lente, comme le souligne Uncle Bob. L'alternative, prônée par Kent Beck, est de voir le "comportement" comme l'unité d'isolation. Couplons les tests au comportement observable (via l'interface publique) plutôt qu'à la structure interne. Prenons l'exemple d'une classe `OrderProcessor` qui utilise internement `PriceCalculator` et `TaxCalculator`. Testons `OrderProcessor` (ex. méthode `processOrder()`) sans mocker les classes internes, sauf pour les dépendances externes (I/O, non-déterminisme). #Disclaimer : D'ailleurs quand on fait vraiment du TDD, on ne connait nos classes internes qu'au moment du REFACTORING ...Cela rend les tests robustes face aux refactorings, réduisant les coûts d'entretien et accélérant la livraison. En pratique, une seule classe de test (`OrderProcessorTest`) suffit pour la classe publique, préservant la couverture de code. Comme le dit Kent Beck : "Les tests doivent être couplés au comportement du code et découplés de sa structure." --- J'ai fait du TDD en Live devant 1 Développeur récemment et depuis il commence à utiliser cette approche qui semble efficace et participe à une meilleure maintenabilité. Halloween TDD Mode 🎃 #TDD #TestUnitaires #Refactoring

👑Masterclass Kafka (Partie 1) : Je démystifie Kafka en 10 min top chrono Je m'excuse par avance nos 2 Génies "Bob" et "Mike" ne font pas partie de la Masterclass 😂 Avant de passer à l'intégration, il y a certains concepts que vous devriez maitriser avant. Ces concepts sont la base de la compréhension de Kafka. Voici les concepts en question : 1. Producteur (Producer) 2. Consommateur (Consumer) 3. Topic 4. Partition 5. Broker 6. Offset 7. Réplication 8. Leader et répliques (followers) 9. Groupe de consommateurs (Consumer Group) 10. Zookeeper J'explique de manière simple ces concepts dans le carrousel, Si après ce post Kafka est toujours un mystère pour vous, Je QUITTE LinkedIn 😂😂😂 Beaucoup ici m'ont demandé de faire un post sur Kafka, merci d'abord pour votre confiance et vos encouragements 🙏 . Ce post est fait pour vous 😁 Si vous êtes satisfait de cette partie 1 de la MASTERCLASS, Mettez "awaiting part 2" en commentaire

Ravi de partager avec vous l'obtention de mon attestation de formation : TDD, DDD et Clean Architecture dans le monde Java, délivrée par WealCome ! Un pas de plus vers une conception logicielle de haute qualité. WealCome

Le créateur de Claude Code a dévoilé l'intégralité de son workflow de travail et honnêtement, c'est incroyable et j'ai appris énormément de choses. Que tu sois Débutant ou Expert, c'est un GAME CHANGER Voici un aperçu de son workflow : 1. Ouvrez 5 terminaux et demandez à Claude de travailler simultanément sur 5 parties différentes de votre application Donc si vous voulez travailler sur 3 parties différentes, ouvrer 3 terminaux. Tout dépend de votre besoin 2. Utiliser 5-10 Agents Claude Ici çà dépend des tâches à effectuer Vous pouvez interagir avec ses agents via votre mobile sur Claude.ai à la salle de sport par exemple 3. Utilisez Opus 4.5 pour tout Car beaucoup pense utiliser Sonnet pour économiser en Token mais avec Opus, vous obtiendrez bien plus vite des meilleurs résultats avec moins de Tokens. 4. Maintenez le fichier CLAUDE.MD cohérent Il faut des règles cohérentes dans ce fichier car ce sont les règles qui sont envoyées à Claude à chaque prompt que vous faites. Ce qui permet à Claude de fonctionner mieux si vous avez les bonnes règles. C'est même la règle fondamentale de son workflow 🫡 5. Démarrez en Mode Planification et effectuez des allers-retours C'est probablement l'étape la plus importante 🔥😲 Effectuez des allers-retours pour avoir le meilleur Plan possible, fine-tuning Claude by Claude. En gros se servir de Claude pour finaliser le plan. Consacrer énormément de temps à cette étape car elle vous fera gagner énormément de temps sur le long terme. 6. Utilisez les commandes slash pour les tâches courantes C'est l'une des features les moins utilisées, bien les utiliser vous fait gagner un temps précieux. Donc créez vos commandes slash personnalisées pour vos activités régulières Par exemple créer un slash personnalisée pour les commits en utilisant un format bien défini 7. A la fin d'une session, il faut demander à Claude de vérifier le bon fonctionnement Donc demandez à Claude de vérifier que le travail a été bien fait et qu'il respecte les bonnes pratiques de sécurité, etc... Le Process complet est disponible sur X via le lien en commentaire Share and Grow 🙌🏼 #Reinvent #ClaudeWorkflow