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.

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.

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.

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.

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.

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 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.

É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.

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.

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.