/images/avatar.jpg

Je partage sur le dev mobile, la tech, le produit, sur moi. Ce sont mes récits et mes réflexions :)

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.

FIRST : 5 principes pour guider l’écriture des tests unitaires

Écrire du code propre est essentiel, et écrire des tests propres l’est tout autant, si ce n’est plus. Design émergent, aide pour retranscrire le métier, documentation, maintenabilité et évolution du code, les tests jouent de multiples rôles au sein d’un projet. C’est pourquoi il est important d’avoir des tests de qualité. Dans cet article, je vous propose d’explorer 5 principes qui pourront vous guider et vous challenger pour l’écriture de vos tests unitaires.

Comment faire émerger les bonnes pratiques dans une équipe de développeurs

Récemment, j’ai préparé et animé un atelier pour faire émerger des bonnes pratiques dans une expertise iOS. Celle-ci regroupe 9 développeurs dispersés dans plusieurs feature teams. Trois de ces équipes travaillent sur la même grande base de code de l’application, et la quatrième est isolée sur un SDK. Les bonnes pratiques font parti de ces sujets sensibles qui peuvent vite déclencher des débats philosophiques ou de forts désaccords. Plus le nombre de personne est élevé, plus cette probabilité augmente.

Fixing thousands of SwiftLint violations over time

What would happen if SwiftLint were added to a project with a lot of existing code? You could have many violations, and much more when SwiftLint is deeply configured. Having too many warnings can be discouraging, and there is also a bigger problem: too many warnings kill the warning. If you start to write code before resolving SwiftLint issues, you may miss some new important problems. So, let’s see how you can handle that.

Scénarisez votre rétrospective avec Kaamelott

Par les corbeaux d’Odin ! Tu découvriras comment scénariser ta rétrospective avec Kaamelott et comment contribuer à de nouveaux scénarios et univers avant la fin du soleil couchant, Arthur. ~ Un viking agile. Lors de mon passage à Radio France, j’ai été SCRUM Master de l’équipe France Musique. Je variais occasionnellement les rétrospectives afin d’adapter le format aux situations et à la vie de l’équipe, et également pour leur faire découvrir de nouvelles choses en cassant la routine.