https://d33wubrfki0l68.cloudfront.net/dd6430acd81da282db1c26612a48362f89b9f94e/33d97/images/avatar.jpg

Mon voyage vers l'artisanat du code en amélioration continue.

Et si on arrêtait les revues de code ?

Qu-Quoi ?! On arrêterait de contrôler la qualité ? « Hérétique, au bûcher ! » s’exclameraient certains paladins de la relecture de code. Et si, au lieu de contrôler la qualité en fin de chaîne, on co-créait cette qualité tout au long de la conception ? Oui, je fais allusion au pair programming. Mais avant d’en parler, plongeons-nous dans une histoire. Une histoire que j’ai déjà vécu et que vous avez probablement aussi vécu.

Clean Architecture - Et si on passait à côté ?

Je vois de plus en plus la Clean Architecture comme le SCRUM. Quelque chose qui est souvent mal appliqué et mal compris. Quelque chose dont on oublie ou met de côté la philosophie, l’essence même. Quelque chose qu’on utilise parce que c’est à la mode. J’observe un nombre grandissant de discussions autour de la Clean Architecture. C’est davantage présent dans les projets, dans les souhaits, dans les échanges, dans les publications.

Mob-Programming - Assigner des rôles et les faire tourner

Plus tôt dans le mois, on a eu un loupé sur un Mob-Programming : une faible dynamique plombait le début. Le format trop libre freinait le groupe. On a rattrapé le coup en faisant tourner des binômes. J’ai pris conscience de l’intérêt d’assigner des rôles et de les faire tourner au sein du groupe pour maximiser les bénéfices du Mob-Programming. C’était lors d’un beCom début octobre - un événement à benext qui regroupe toute une communauté sur l’après-midi.

Le récit de mes aventures se déplace

Je me suis toujours dit que la plateforme Medium serait mon MVP de blog. J’ai pu me lancer dans l’écriture, apprendre, essayer. Aujourd’hui, je franchis une nouvelle étape avec la création de mon propre blog. Le début de nouvelles aventures. Medium était un bon moyen de commencer à écrire sans me soucier du support. Je me connais, j’aurais probablement passé beaucoup (trop) de temps à comparer des solutions, les tester, comprendre les rouages, personnaliser, etc.

Soyez flemmard, écrivez des scripts

Avoir la flemme, ça a aussi du bon. Et quand on est développeur, on peut s’en servir. On a une arme redoutable : la capacité de créer des programmes. On peut facilement automatiser une tâche. C’était mon cas récemment. Je devais mettre à jour un référentiel dans l’application. On m’a expliqué la procédure habituelle (récupérer un gros fichier de données puis faire une multitude de modifications manuelles), et ça ne me donnait pas terriblement envie.

Pair Programming ritualisé

Au printemps, alors que les arbres commençaient à fleurir, j’ai eu l’idée de ritualiser un créneau de pair programming. J’aime beaucoup cette pratique. À mon sens, le pair programming apporte beaucoup de bonnes choses. Peu importe le niveau des personnes, ou même leur écart de niveau, ce qui en émerge est très intéressant. Les discussions, le code collectif, l’exploration, l’apprentissage, etc. C’est quelque chose que j’utilise régulièrement avec mon binôme. Sur la demande de l’un ou de l’autre.

Profiter de chaque occasion pour améliorer le code legacy

Vivre avec une grande codebase legacy n’est pas agréable. Les changements sont longs, les bugs se cumulent, la compréhension se perd. Cependant, rien ne nous oblige à subir ces inconvénients éternellement. On peut agir, à tout moment, et dès maintenant. Il n’y a pas besoin de se lancer dans un grand chantier pour cela, ni de prévoir un plan pour aller sur la Lune. On peut faire du refactoring par petites étapes et le faire régulièrement.

Comprendre du code legacy grâce au refactoring

Je travaille actuellement sur un vieux projet vieux comportant un legacy douloureux. Je suis souvent confronté à du code que je ne comprends pas et sur lequel je ne peux pas obtenir d’aide : les autres développeurs n’en savent pas plus que moi, et les Product Owner ont perdu la connaissance fonctionnelle. C’est un phénomène commun. Le code legacy s’entoure d’une perte de connaissance technique et métier. L’équipe ne comprends plus ce qui se passe dans le code, et ne sait plus trop ce que ça doit faire fonctionnellement.

Automatically run tests when a change occurs

I would like to talk to you about unit tests and how you can automatically run them as soon as you modify code. I regularly use the Test-Driven Development approach when I write code for a project or when doing a code kata. Sometimes I write a little bit too much before running tests again, and when tests turn red, I’m telling myself “Oh! But since when was I wrong?”.

Playgrounds: Speed up your tests feedback in Swift

Playgrounds was released in September, 2016. It’s a powerful environment integrated in Xcode to code in real-time in Swift. Using Playgrounds is a great way to learn, experiment, and quickly prototype. This is particularly interesting when comparing its speed with an iOS or macOS project. Compiling such a project takes tens of seconds or even several minutes. Running tests is therefore also slowed down. Test-Driven Development is about getting feedback quickly.