DEV Community: Nicolas Verinaud

🇫🇷 Introduction à TDD en Swift (Partie 3) - Une bonne documentation

Nicolas Verinaud — Mon, 10 Feb 2020 00:00:00 +0000

Cet article fait partie de la série "Introduction à TDD en Swift"

Introduction à TDD en Swift (Partie 1) - 7 étapes essentielles
Introduction à TDD en Swift (Partie 2) - Vive le typage et la généralisation
Introduction à TDD en Swift (Partie 3) - Une bonne documentation

Dans le précédent article de cette série tu as appris les bienfaits de la pratique de TDD :

les tests sont fiables et nous permettent de ne rien casser,
les tests nous poussent à raisoner plus profondément, à avoir un code plus robuste,
les tests sont plus importants que le code de production.

Nous allons continuer aujourd’hui le kata FizzBuzz en implémentant plusieurs nouveaux tests en TDD.

Au programme :

pourquoi une suite de tests doit constituer la meilleure documentation possible,
je vais déroger au cycle RED-GREEN-REFACTOR (crime crime ! 😂),
tu vas avoir un petit aperçu du property-based testing (wat?),
et enfin on va utiliser le résultat d’un test pour écrire un test (waaaat?).

Alors, prêt(e) ?

🇫🇷 Introduction à TDD en Swift (Partie 2) - Vive le typage et la généralisation

Nicolas Verinaud — Tue, 17 Dec 2019 00:00:00 +0000

Cet article fait partie de la série "Introduction à TDD en Swift"

Introduction à TDD en Swift (Partie 1) - 7 étapes essentielles
Introduction à TDD en Swift (Partie 2) - Vive le typage et la généralisation
Introduction à TDD en Swift (Partie 3) - Une bonne documentation

Dans le précédent article de cette série tu as appris les bases de TDD en faisant un cycle complet de 7 étapes.

Nous allons continuer aujourd’hui le kata FizzBuzz en implémentant plusieurs nouveaux tests en TDD.

Cela te permettra de mieux comprendre la profondeur et l’intérêt de cette pratique qui a changée ma manière de travailler.

Au programme :

trois techniques de refactoring pour améliorer la qualité du code,
l’utilisation du système de type pour éviter l’écriture d’un test,
des propriétés intéressantes du TDD, au-delà des tests en eux-même,
du fun comme jamais ! (Ok ça c’est peut-être un peu exagéré ! 😂)

Alors, prêt(e) ?

🇫🇷 Introduction à TDD en Swift (Partie 1) - 7 étapes essentielles

Nicolas Verinaud — Wed, 11 Dec 2019 00:00:00 +0000

Cet article fait partie de la série "Introduction à TDD en Swift"

Introduction à TDD en Swift (Partie 1) - 7 étapes essentielles
Introduction à TDD en Swift (Partie 2) - Vive le typage et la généralisation
Introduction à TDD en Swift (Partie 3) - Une bonne documentation

Dans l’article précédent, je te parlais de l’importance des tests pour faire émerger l’architecture.

J’évoquais aussi le fait que TDD permet d’être plus productif en combattant l’idée reçue “Écrire des tests revient à écrire plus de code, donc c’est plus lent”.

Tu m’as convaincu que TDD était LA pratique à apprendre. Mais comment je fais concrètement ?

Je vais te le montrer à travers ce tutoriel justement !

Nous allons entrer dans le vif du sujet avec une approche par l’exemple comme l’a fait Kent Beck (le papa de TDD) le 8 novembre 2002 (17 ans déjà !) lorsqu’il a publié son livre “Test-Driven Development by Example”.

Languages, libraries & frameworks to avoid in 2020

Nicolas Verinaud — Tue, 20 Aug 2019 15:09:31 +0000

What a catchy title, and you clicked on it ! 😜

I'm gonna be brief : avoid learning any languages, libraries & frameworks next year.

Instead, I suggest you to focus on one thing : doing your job, as a programmer, really well.

That is :

be more disciplined, computer science is a science and it needs care ; careless programmers create mess, bugs and make their company loose money & opportunities,
seek for deep knowledge beyond the next React / Angular / Vue / [insert hype here] version, for example go learn why you probably do not need kafka or event sourcing or microservices,
pick your already-known-so-boring-day-to-day language and learn how to not create bugs with it everytime you touch your favorite codebase ; learn how to design using the powerful features of it ; read books about writing code that are easy to read & understand instead of Vue documentation,
learn how your business works, you are creating software for real people, be empathetic with them.

That's it, brief I said. 😉

🇫🇷 Construire une architecture émergente

Nicolas Verinaud — Mon, 08 Jul 2019 00:00:00 +0000

Dans l’article précédent, je te parlais de ce qu’est une architecture logicielle et de la nécessité de la faire émerger.

Pour y arriver, il faut manipuler son code comme de la pâte à modeler ; car avoir une conception qui tape dans le mille du premier coup est proche de l’impossible.

Et puis de toute façon, c’est un fait, le besoin change !

Pour répondre à ces nouveaux besoins, il faut modifier le code.

Qui dit le modifier dit potentiellement introduire des bugs, casser des choses.

Et là, forcément, la peur te gagne. Comment limiter ce risque ? Comment éviter de casser, de créer des bugs ?

Je ne vais pas te le cacher, il n’y a pas 36 solutions, il faut… tester !

Dans cet article, je vais parler de plusieurs stratégies pour à la fois prévenir l’apparition de bugs mais aussi permettre de faire émerger une architecture saine et évolutive.

Pour ne plus avoir peur de casser des choses en modifiant le code.

L’objectif est toujours d’avoir la conception la plus optimale possible pour répondre au besoin présent ; sans sur-ingénierie (pas de code “au cas où”) et sans sous-ingénierie (pas de duplication partout).

Une conception aux petits oignons pour apporter de la valeur MAINTENANT.

Voici la liste des stratégies que je vais développer :

tester manuellement,
laisser le compilateur tester pour moi,
automatiser mes tests (tu apprendras aussi pourquoi TDD rend plus efficace et permet de gagner du temps !).

Lire la suite sur l'Académie Ryfacto...

Embed a form on dev.to ?

Nicolas Verinaud — Fri, 21 Jun 2019 07:07:47 +0000

Is it possible to embed a form on dev.to ?

I tried to use the

tag but it did not work. 😞

I'd really like to embed my newsletter signup form on post I create here. 🙂

🇫🇷 La seule architecture qui compte

Nicolas Verinaud — Sun, 16 Jun 2019 00:00:00 +0000

Ah, l’architecture d’une app iOS.

Vaste sujet qui me préoccupe depuis que j’ai commencé à créer des apps iOS en 2010 (sortie du premier iPad, de l’iPhone 4 et d’iOS 4 !).

À chaque nouvelle app se pose cette question fatidique : quelle archi mettre en place ?

Après tout, c’est un choix important, non ? Une fois l’architecture choisie, impossible de revenir en arrière, n’est-ce pas ?

Mais dites-moi, c’est quoi une architecture ?

Architecture : définition

Prenons la définition du Larousse :

Organisation des divers éléments constitutifs d’un système informatique, en vue d’optimiser la conception de l’ensemble pour un usage déterminé.

Il y a la notion d’ organisation ; il s’agit là d’organiser son code, ses modules, ses frameworks.

L’objectif est d’ optimiser la conception de l’ensemble ; il faut prendre du recul sur tout son code afin de l’optimiser.

Dans le but de répondre à un usage déterminé ; cette notion d’usage, je l’interprète d’un point de vue fonctionnel.

Maintenant que nous sommes d’accord sur la définition ; quelles sont les caractéristiques d’une bonne architecture ?

Une bonne architecture

Je vais reprendre chacune des notions et tenter de déterminer les caractéristiques que je juge en adéquation avec la définition.

Pour rappel, il s’agit de limiter la réflexion au code d’une app iOS. (Même si, en réalité, cette réflexion est applicable à tous logiciels.)

Organisation

Comment déterminer que le code de mon app iOS est bien organisé?

Primo, je trouve rapidement ce que je cherche.

Ex: je dois modifier l’écran de connexion, il doit bien exister un LoginViewController ou quelque chose comme ça.

Deuxio, je ne me perds pas en cours de route.

Contre-Ex: le LoginViewController fait quoi exactement ? Dans viewDidLoad : il configure des singletons (wtf?), modifie des contraintes (wtf??), fait un appel serveur (wtf???) ; il appelle des méthodes sur une super classe pour…je suis perdu je ne comprends plus rien !

Tertio, les dépendances ne partent pas dans tous les sens.

Contre-Ex: LoginViewController dépend de ClientAPI qui dépend de Configuration qui dépend de ClientAPI, wtf?

Optimiser la conception de l’ensemble

Comment déterminer que la conception est optimisée ?

Primo, je comprends facilement ce que le code fait.

Ex: LoginViewController a une méthode onLoginButtonTapped() qui appelle behavior.login().

Contre-Ex: LoginViewController a une méthode buttonTapped(_ sender: NSObject) qui teste si sender == button1 et qui fait plein de trucs sur 200 lignes avec un niveau d’imbrication au-delà de toute raison et problablement un appel API caché au milieu ?

Deuxio, je retrouve les termes métiers dans le code.

Ex: quand je parle avec les utilisateurs et utilisatrices, ils évoquent des Recettes et des Ingrédients ; dans le code j’ai bien les notions de Recipe et d’Ingredient.

Tertio, j’arrive à changer facilement le code.

Contre-Ex: je modifie le login pour améliorer l’expérience utilisateur, je livre, et j’ai 36 nouveaux bugs à des endroits improbables, whaaaat?

Un usage déterminé

Comment déterminer que la conception répond à un usage précis ?

Primo, il n’y a pas de code au cas où.

Contre-Ex: je dois afficher des informations textuelles dans la v1. Je crée un InformationsBuilder qui accepte une dépendance implémentant le protocole InformationsStrategy et je crée une classe TextualInformationsStrategy qui implémente ce protocole.

Autre contre-ex: je vais créer une DSL de configuration de style, au cas où je dois changer le thème de l’app un jour.

Deuxio, il n’y a vraiment pas de code au cas où !

Il m’est déjà arrivé de complexifier le code en essayant d’anticiper les besoins. C’est tentant et motivant de créer du code réutilisable. Mais dans 95% des cas c’est too much.

Mieux vaut dupliquer pour trouver la bonne abstraction que créer une mauvaise abstraction.

Je préfère dupliquer une ou deux fois, puis prendre du recul pour trouver comment factoriser le code, afin de créer des abstractions qui ont une réelle utilité et un véritable sens.

Une bonne conception

Une bonne architecture veut donc avant tout dire une bonne conception.

Une bonne conception respecte les critères que j’ai listés ci-dessus et que je rappelle ici :

je trouve rapidement ce que je cherche,
je ne me perds pas en cours de route,
les dépendances ne partent pas dans tous les sens,
je comprends facilement ce que le code fait,
je retrouve les termes métiers dans le code,
j’arrive à changer facilement le code,
il n’y a pas de code au cas où,
le code répond à un usage déterminé.

Je ne vais pas vous le cacher, avoir une architecture qui remplit tous ces critères est très difficile.

Il faut déjà réussir à bien comprendre le besoin, à déterminer précisément l’usage.

Il ne faut pas anticiper des demandes qui n’arriveront peut-être jamais.

Il faut rendre son code compréhensible par les autres humains qui vont le lire (et nous ne sommes pas tous égaux à ce niveau).

Il faut faire face aux particularités des frameworks et librairies qu’on utilise.

Autant vous dire qu’avoir juste du premier coup relève du miracle !

Faire émerger la conception

Mais si je n’arrive pas à avoir juste du premier coup…cela veut dire que je vais devoir changer ma conception en cours de route, la faire évoluer ?

Exactement ! C’est ce que j’appelle faire émerger la conception.

Oh ! Et du coup faire émerger la conception revient à créer…

Une architecture émergente !

Je pars de deux hypothèses pour justifier le fait de faire émerger l’architecture, plutôt que de la figer dans le marbre à l’avance.

Il est impossible d’imaginer la bonne conception du premier coup.
Le besoin change.

J’ai déjà détaillé le premier point ci-dessus, passons au second.

Le besoin change

Si seulement les utilisateurs, utilisatrices, clientes & clients arrêtaient de changer tout le temps d’avis ! Cela serait beaucoup plus simple ! Nous aurions un cahier des charges figé et des spécifications fonctionnelles figées. Il nous serait alors si simple de concevoir une app qui réponde exactement à ce qui est demandé. Nous pourrions prendre le temps de bien concevoir, de faire de beaux diagrammes. Puis nous livrerions une app bien conçue et nous passerions à la suivante.

Le rêve quoi !

Vraiment ?

Nous savons que ce n’est jamais le cas. Qui a déjà vécu cette situation, honnêtement ?

Le besoin change !

Pourquoi change-t-il ?

Car créer un logiciel est principalement un travail de communication, de compréhension et d’empathie.

Entre ce que l’utilisateur a en tête, ce qu’il explique, ce que la développeuse comprend et ce qu’elle exprime par code ; les risques de mauvaise interprétation sont légions ! (Ajoutez quelques intermédiaires entre les deux personnes et vous multiplierez ces risques. Coucou les Product Owner & Proxy Product Owner & Proxy Proxy Proxy…)

Ce n’est pas forcément le besoin réel qui change, c’est notre compréhension qui évolue ! Il nous arrive (souvent) de mal comprendre le besoin réel. Au fur et à mesure que nous créons et livrons le logiciel, nous apprenons des feedbacks ! Et nous devons refléter cette compréhension dans notre code.

Conclusion

Bonne architecture veut dire bonne conception.

Avoir une conception juste du premier coup est impossible car le besoin change, notre compréhension de celui-ci change.

Il faut donc être capable de faire évoluer cette conception, de la faire émerger.

Pour cela, nous devons nous assurer que nous ne cassons rien au passage.

Et pour ne rien casser…on fait comment ?

Je vous en parle dans le prochain article. 😉

Pour ne pas le manquer, inscrivez-vous à ma newsletter !

My new swift workflow or how to boost your swift productivity !

Nicolas Verinaud — Thu, 14 Feb 2019 22:06:29 +0000

Running tests manually each time I make a change in Xcode or AppCode drive me crazy (because of slowness & bugs in AppCode), so I decided to automate it.

The objective ? Having this kind of workflow (which I observed and enjoyed when I did some JavaScript) :

edit some source code,
watch the tests run automatically without me doing anything, giving me instant feedback on how well I am doing.

Here is how I enable this workflow for swift development (it can also be applied for other languages as long as you can run tests from the command line) :

Install node
Install nodemon
Run this command in your workspace (or project) folder (using your favorite terminal or the one embedded in AppCode, which I use because of me working in full screen).

nodemon -e swift,strings --exec "xcodebuild -workspace MyApp.xcworkspace -scheme \"MyApp\" -destination 'platform=iOS Simulator,name=iPhone XS,OS=12.1' test"

Just replace the workspace & scheme with yours, and you're done ! You can make a change to any swift or strings files and boom tests are run automatically !

Let me know how if it is helpful for you in the comment or on Twitter !

I originally wrote the full story (with drama) of me making this possible. I left it below for you to enjoy ! 😁

The Full Story Behind

It all started with a frustration.

I love the speed of Xcode for building & running tests.

But, woa, the refactoring capabilities, despite getting better, are wayyy behind what AppCode provides.

I love the refactoring capabilites of AppCode.

But, woa, building & running tests is so sloooow.

And it fails every once in a while, like, every hour with a "db lock blabla" error requiring me to clean, clean build folder, praying, crying, relunching the IDE, crossing fingers. Eventually productivity is back again.

Choose your pain !

A Great Ide(a)

So, yesterday I had an idea.

Wait wait, building your own IDE right ?

Exactly !

You know that this is a huge project, like a HUGE project !

Yeah, cool isn't it ?!

You do not have the time to do that.

What ? ...

Oh I guess you're right. Am I doomed ?

You're a developer, a developer is never doomed ! What about finding a viable solution in 1 hour ? Like a Startup Challenge !

Challenge accepted !

Wouldn't it be cool to use AppCode as the source code editor & Xcode to build & run the tests ?

That would be my MVP.

Switching back & forth between 2 IDEs manually ? You kiddin', right ?

Meh...painful isn't it ?

What about "build & run" from the command line using the integrated terminal of AppCode ?

Seems better !

So my solution is only a little man xcodebuild away !

*Digging into the manual*

TADA! Here is my command !

xcodebuild -workspace MyApp.xcworkspace -scheme "MyApp" -destination 'platform=iOS Simulator,name=iPhone XS,OS=12.1' test

Seriously ?

Yep ! My workflow is now :

Editing some source code
Running the command above
goto 1

Not bad, but I have another challenge !

I have some time left, tell me.

What about running this command automatically when you edit the source code ?

Hum...

I did this thing one day...nodeJS...
...with a watch running stuff when code changed...like hot reloading, running tests...

Cool story... But this is serious stuff, not this JavaScript hype thing.

I am serious !

Oh yes I am...

So it used an npm package called nodemon to watch for file changes.

*Searching for nodemon...digging into the documentation*

TADA! I can run this nodemon thing telling it to watch for swift & strings files & executing my custom command !

Prove it !

No problem, watch this !

nodemon -e swift,strings --exec "xcodebuild -workspace MyApp.xcworkspace -scheme \"MyApp\" -destination 'platform=iOS Simulator,name=iPhone XS,OS=12.1' test"

Oh please, you mean your workflow now is...

Editing source code
No step 2.

Lessons I learned

Frustration is a powerful call-to-action for me.
Learning unrelated stuff, like nodeJS in this case, can open new horizons & improve creativity.
Using the 1-hour timebox forced me to find a good enough solution which ended beyond my initial expectations !