Software Craftsmanship

Software Craftsmanship

Crafters et crafteuses, premiers allié․e․s des femmes ?

Le « Software Crafts·wo·manship » est un état d’esprit mettant l’accent sur les bonnes pratiques de développement. Le but de cet article est d’apporter mon point de vue en tant que développeuse et crafteuse. Pour revenir aux fondamentaux de ce qu’est le craft, cet article vous procurera d’avantages d’explications. Alors que la vision du développement logiciel des années 90 se concentre sur la production industrielle réduisant les développeur·se·s à de simples producteurs de ligne de code, le mouvement « Software Crafts·wo·manship » ou « Software Craft » apparaît à la fin…

Lire la suite
Bonne pratique

Retour aux fondamentaux du craft : trois exemples

Il y a quelques années, j’avais déjà 20 ans d’expérience en développement, et j’avais vu énormément de sujets. Je savais bien qu’il y avait aussi de très nombreux sujets sur lesquels je ne connaissais rien, et j’en avais de plus en plus conscience. Mais quelque chose de plus me trottait dans la tête : et si j’avais aussi besoin de réviser les bases ? Est-ce que j'avais besoin de revoir les choses que je connaissais déjà ?

Lire la suite
Brèves de consultants

Nous sommes allés à SoCraTes 2022 – 6e édition

Nous sommes quelques Octos a avoir eu la chance de participer à la 6e édition de SoCraTes France (https://twitter.com/SoCraTes_FR/status/1505625869519396864). Pour poser le contexte, qu’est-ce que SoCraTes ? SoCraTes (pour Software Craft and Testing) c’est un temps (3 jours et … 3 nuits) où une soixantaine de personnes se retrouvent dans un endroit sympathique pour échanger, partager, et coder. Le format est simple : c’est un Open Space où tout le monde est libre de proposer des sujets en début de chaque journée, un agenda s’organise…

Lire la suite
Bonne pratique

Deux techniques de base pour le code Legacy

Cet article présente Sprout Method et Wrap Method, deux techniques très utiles quand : on travaille sur du code non testé (une des définitions possibles de “code legacy”)on souhaite y ajouter une fonctionnalité couverte par des tests (la “reason to change”). Ces deux techniques sont les premières techniques présentées par le livre “Working Effectively with Legacy Code”, de Michael Feathers (WEWLC). Elles permettent d’ajouter du code testé dans du code difficile à tester, et ce sont aussi de bonnes premières étapes vers un meilleur design. …

Lire la suite
Bonne pratique

Mise en production d’un projet de Machine Learning

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
Archi & techno

Due diligence technique – sécuriser son investissement dans des startups IT – Part I/II

Ou comment investir puis valoriser son portefeuille de startups Introduction Les effets directs ou indirects de la pandémie, bouleversent de nombreuses entreprises et en particulier les startups. Le gouvernement a d’ailleurs débloqué 4 milliards d’euros pour leur venir en aide. Pour la BPI, une des questions sera de savoir sur lesquelles porter les efforts.  De ces bouleversements faits de fragilités, de changements de cap voire d’accélérations font naître des opportunités d’investissement ou de rachat. En particulier pour les entreprises ou les investisseurs dont les liquidités…

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
Software Craftsmanship

Un test peut en cacher un autre – Tests d’intégration – P1

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 ces articles autour des tests unitaires :  Un test peut en cacher un autre — Tests unitaires — P1 Un test peut en cacher un autre — Tests unitaires — P2 Que ces tests sont exclusivement centrés sur…

Lire la suite