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.

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.

One of the things I really like with the Swift language is that Apple designed it for safety. Features like optionals or the different operators for downcasting prevent us from causing runtime crashes in our apps. In fact, we are now dealing with compile-time errors, and it changes everything. It is less prone to mistakes because the Swift compiler will stop us before. We can neither ship an application which cannot be built, nor run it in debug.

They are all different, but they all look alike. We all have our rules, our preferences. Even beliefs. Sometimes, you can talk with people who have the same principles. Sometimes, they can have thoughts that diverge from yours, completely. Discussing different points of view is often interesting. You can learn a lot, and it opens your minds to new ideas. So, do not close the door to constructive debates.

Récit d’une après-midi d’échanges entre développeurs organisée en Forum Ouvert, mêlant de l’apprentissage, de l’intervision, et des actions. Quelqu’un adorant dessiner au tableau pour résoudre une problématique :) À benext, les développeurs sont en projet dans les locaux de différents clients, mais ce n’est pas pour autant qu’on ne se voit pas. Nous nous retrouvons au siège de benext, le vaisseau (en référence à la passion pour Star Wars qui anime le fondateur), dès que nous pouvons.