Software Craftsmanship

Software Craftsmanship

Le backlog est vivant, il bouge avec des feedbacks (épisode 1 – synopsis et glossaire)

Charlotte a décidé de créer avec l'aide de ses enfants une application qui facilite l'apprentissage du Japonais. Elle découvre que les activités de conception et de construction s'appuient mutuellement l'une sur l'autre à travers de nombreux allers et retours, mais aussi qu'elle doit abandonner l'idée qu'une expression de besoin définitive, figée, existe pour cette application.

Lire la suite
Software Craftsmanship

Défense et illustration des test isolés – #2

Qu’est-ce que le code legacy ? "Le code sans test est du mauvais code. Peu importe qu’il soit bien écrit; peu importe à quel point il est élégant, orienté-objet ou encapsulé. Avec des tests, nous pouvons changer le comportement de notre code rapidement et de manière fiable. Sans eux, nous ne pouvons pas réellement savoir si l’état du code s’améliore ou empire.” “En ce qui me concerne, le code legacy est simplement du code sans tests.” Michael Feathers, Working Effectively with Legacy Code "Ce code…

Lire la suite
Software Craftsmanship

Défense et illustration des tests isolés – #1

"There is hardly anything in the world that someone cannot make a little worse and sell a little cheaper, and the people who consider price alone are that person’s lawful prey. It’s unwise to pay too much, but it’s worse to pay too little. When you pay too much, you lose a little money — that is all. When you pay too little, you sometimes lose everything, because the thing you bought was incapable of doing the thing it was bought to do. The common…

Lire la suite
Software Craftsmanship

Amener son projet de machine learning jusqu’en production avec Wheel et Docker

Cet article propose d'explorer setuptools, Wheel et Docker afin de packager une application de Machine Learning pour détecter des muffins 🍪 ou des chihuhuas 🐶 dans une image, avec code a l'appui. Si packager du code de Machine Learning en Python est pour vous synonyme de demander à vos utilisateurs de cloner votre repository git sur leur machine, cet article devrait vous intéresser.

Lire la suite
Software Craftsmanship

Les statuts, ça pue (part. 3) : Les statuts, ça se lit

Nous avons souvent dans nos modélisations, nos schémas, nos user stories, nos bases de données et nos APIs un petit champ nommé status, parce que l'anglais ça fait classe. Et bien je vous le dis tout de bon, ce petit champ qui stocke le statut de votre ressource, il sent mauvais et augure bien des périls, en particulier si vous pouvez le modifier. Il peut être révélateur d'une perte de richesse fonctionnelle de notre solution ainsi que de défauts de cohérences ou de résilience de la conception…

Lire la suite
Software Craftsmanship

Pourquoi faire simple quand on peut faire compliqué ? – Extrait d’une discussion chez OCTO

Introduction Cet article n’est pas un article comme les autres, c’est un extrait brut de discussion que nous avons sur notre mailing-list “tech” interne, un bout de la culture OCTO. tech : L’objectif de cette mailing-list est d’échanger entre OCTO sur des sujets techniques, on y retrouve des demandes d’aide sur un sujet ou une architecture technique, des REX (retour d’expérience) sur des technologies ou des missions, des échanges d’opinions ou de convictions, des partages de savoir, et beaucoup de débats. l’objectif de l’article : En écrivant…

Lire la suite
Software Craftsmanship

Et si Vim avait raison ?

Cet article a pour objectif de vous partager une prise de conscience, agrémentée d’un maximum d’exemples concrets, qui je l’espère vous permettra de devenir un.e meilleur.e programmeur.euse. La réalisation que je cherche à transmettre étant le fruit d’un contexte, je vais vous exposer les différentes étapes qui m’y ont mené. Je vais commencer ce voyage en parlant de Vim et il sera à la base de beaucoup d’exemples, mais vous verrez que les enseignements que j’en retire sont bien plus généraux !   Dans le…

Lire la suite
Software Craftsmanship

Un test peut en cacher un autre – Tests bout en bout et autres

Introduction L’article d’introduction débute en listant certaines différences de visions que je peux avoir avec d'autres développeurs concernant l'architecture applicative ou encore la rédaction des tests. À travers elles, j’évoque les difficultés qu’ils peuvent rencontrer à identifier précisément quoi tester et comment. Nous avons pu voir dans les autres articles de la série différents types de tests. Certains nous aidant à vérifier les règles métier comme les tests unitaires : Un test peut en cacher un autre - tests unitaires - partie 1 Un test…

Lire la suite
Software Craftsmanship

Un test peut en cacher un autre – Tests d’acceptation

Introduction L’article d’introduction débute en listant certaines différences de visions que je peux avoir avec d'autres développeurs concernant l'architecture applicative ou encore la rédaction des tests. À travers elles, j’évoque les difficultés qu’ils peuvent rencontrer à identifier précisément quoi tester et comment. Deux phrases extraites de l’article de Ian Cooper avaient retenu l’attention : “Le code issu d’un refactoring ne requiert pas de faire de nouveaux tests dessus !” “Je vous recommande d’utiliser ports/adaptateurs et d’écrire les tests en outside-in depuis le use case.” Nous…

Lire la suite
Software Craftsmanship

Application / Domain / Infrastructure : des mots de la Layered Hexagonal Clean Architecture ?

Depuis quelques années, quand je découvre un projet je vois régulièrement des répertoires qui s'appellent : - Application - Domain - Infrastructure D'où viennent ces mots ? Quel intérêt à les utiliser ou ne pas les utiliser aujourd'hui ? Je me suis documenté sur le sujet et je vous propose un voyage dans le temps pour y voir un peu plus clair.

Lire la suite