Kevin Murphy partage sa méthode pour lire et évaluer les demandes de pull request (PR). Il explique quand il préfère les examiner (au début ou à la fin de la journée, entre les réunions, etc.), ce qu'il cherche (le but de la PR, son état d'avancement), pourquoi il les examine (demande explicite, expertise, désir d'apprendre) et comment il adapte son approche en fonction de l'auteur. Son objectif est d'aider à faire avancer le travail vers la production, de partager des connaissances et de stimuler la réflexion.
La Specification Driven Development (SDD) est une approche de développement logiciel qui replace la spécification détaillée des exigences avant l’écriture du code comme artefact central du projet : cette spécification, souvent en texte structuré (ex. Markdown), décrit le comportement attendu du système et sert de source de vérité pour guider conception, implémentation et tests, contrastant avec les méthodes où les tests ou documents techniques viennent après le code ; historiquement issue d’une évolution des pratiques (TDD → BDD), elle vise à réduire les erreurs, ambiguïtés et malentendus entre parties prenantes en clarifiant l’intention dès le départ et en maintenant la documentation vivante et accessible dans le même dépôt que le code.
L'article présente une méthode innovante pour améliorer l'utilisation de l'IA dans le développement de logiciels. L'auteur introduit le concept de "Design Log", un dossier versionné dans le dépôt Git contenant des documents markdown qui capturent les décisions de conception à un moment précis. Cette approche permet de résoudre le problème de la "Context Wall", où l'IA commence à faire des suggestions conflictuelles à mesure que le codebase grandit. L'article illustre cette méthodologie avec un exemple concret de l'ajout de "Server Actions" dans le Jay Framework, montrant comment l'IA peut devenir un partenaire architectural en suivant des règles de projet strictes. La méthode permet de passer d'une idée à une mise en production en seulement 48 heures, en favorisant une collaboration socratique et une implémentation traçable.
Cet article met en lumière les lacunes des études de cas souvent utilisées pour démontrer l'impact de la performance web sur les revenus. Il souligne que ces études, bien que populaires, sont souvent biaisées, incomplètes ou mal contextualisées, ce qui nuit à la crédibilité de l'industrie. Il prend comme exemples l'étude d'Amazon sur la perte de revenus de 1% pour 100ms de retard (données obsolètes, manque de contexte) et l'étude de Rossignol (variables confondantes). L'auteur encourage à être critique face à ces études et à privilégier des données solides et contextuelles pour convaincre les parties prenantes.
L'article explore la méthode Spec-Driven Development (SDD), qui consiste à générer des spécifications détaillées en Markdown avant de coder, guidant ainsi les agents de codage. Bien que prometteuse pour structurer le développement avec l'IA, cette approche, inspirée du modèle Waterfall, présente des inconvénients majeurs : production excessive de texte, bureaucratie systématique, et sentiment de fausse sécurité. L'auteur suggère qu'une approche plus itérative et naturelle pourrait mieux convenir au développement moderne. Plusieurs outils comme Spec-Kit, Kiro, et Tessl sont mentionnés, mais leurs limites sont également discutées.
L'article introduit le Core Model, une méthodologie pratique qui révolutionne le développement numérique traditionnel en commençant par une hypothèse sur les besoins des utilisateurs plutôt que par des solutions préconçues. En posant six questions clés dans le bon ordre, cette approche aligne les équipes pluridisciplinaires autour des tâches des utilisateurs et des objectifs commerciaux, créant ainsi une clarté qui transcende les limites organisationnelles. Le processus commence par une préparation en amont pour identifier les priorités et former des hypothèses initiales, suivies d'un atelier collaboratif où des paires de participants travaillent ensemble pour valider et affiner ces hypothèses. Les six éléments du Core Model — groupe cible, tâches des utilisateurs, objectifs commerciaux, chemins d'accès, chemins de progression et contenu principal — créent un cadre structuré qui guide les équipes vers des solutions efficaces. L'article souligne l'importance de travailler en paires interdisciplinaires pour favoriser l'innovation et la qualité, et conclut en expliquant comment cette méthodologie peut être mise en œuvre pour améliorer la collaboration et obtenir de meilleurs résultats dans les projets numériques.
Tout est dans le titre
L'auteur décrit une méthodologie (décrite dans le livre "Team topologies") pour répartir les équipes de développement en fonction de la complexité des domaines (au sens DDD), des relations entre domaines, etc. de manière à réguler la charge cognitive.
L'auteur expose une méthodologie d'écriture de tests JavaScript inspirée des hooks de React. Très intéressant
Tout est dans le titre
L'auteur décrit un biais statistique connu : l'oubli de la fréquence de base... et montre les conséquences graves que cela peut avoir.
SEM = Scalable + Extensible + Maintenable
BIO - Block Element Modifier + Inverted Triangle CSS + Object Oriented CSS
ça en fait des acronymes :)
Un tour d'horizon de différentes méthodologies d'organisation des CSS (BEM, SMACSS, etc.)
Tout est dans le titre
UI methodologies like Atomic Design bring logic and structure to individual screens. Now it’s time to extend that...
3 méthodologies CSS comparées : BEM, SMACSS et Enduring CSS
Tout est dans le titre (via la-grange.net)
Tout est dans le titre (via https://www.smashingmagazine.com/2016/09/web-development-reading-list-152/ )
Conclusion de cet article très intéressant : ne pas appliquer une méthodologie sans réfléchir, vérifier d'abord si elle convient au projet / à l'entreprise / etc.
Je cite : "La méthodologie 12 facteurs peut être appliquée à des applications écrites dans tout langage de programmation, et qui utilisent tout type de services externes (base de données, file, cache mémoire, etc.)"