J’aime considérer les principes (& co) comme des guides. Ils me donnent des indications sur ce que je fais pour prendre de la hauteur. Ça m’aide à réfléchir et à me questionner. Suis-je dans une bonne direction ? Pourquoi ce principe semble m’alerter ici ? Qu’est-ce que ça va m’apporter ? De quoi ai-je besoin ? En me posant des questions, je m’assure de prendre en compte mon contexte et de m’y adapter. Je cherche aussi à bien comprendre le principe, pour qu’il me guide au mieux. Peut-être que ça ne fait pas sens de l’appliquer ici.

Un exemple avec le principe DRY (Don’t Repeat Yourself). Je viens d’écrire du code qui ressemble à un autre morceau de code ailleurs dans le projet. Le voyant DRY s’allume et me dit d’éviter la duplication. En prenant du recul, je peux me demander si c’est réellement de la duplication. Est-ce qu’ils sont dans le même domaine métier ? Est-ce qu’ils ont les mêmes raisons de changer ? À quel point est-ce identique ? Ou même, est-ce trop tôt ? Même si le principe peut m’indiquer un comportement à adopter, je prends d’abord soin de réfléchir et d’analyser mon contexte.

À l’opposé, une approche plus dogmatique des principes. On arrête de réfléchir, on ne se pose pas (trop) de questions. On applique bêtement ce que le principe nous dit. En même temps il n’y a pas à réfléchir, si le principe le dit, c’est forcément vrai. Alors on le fait. On commence même à avoir une vision binaire : je respecte ou je ne respecte pas. D’ailleurs, si je ne respecte pas, c’est évidemment mal.

En reprenant l’exemple du principe DRY, j’aurais sûrement supprimé la duplication tout de suite. Sans questionnement. Deux bouts de code qui se ressemblent ? Oula, vite ! Qu’on me supprime cette duplication ! Pourtant, il s’agissait de règles métiers de deux domaines différents. Peu de temps après, j’aurais cassé le comportement d’un des deux domaines en modifiant ce bout de code non dupliqué. Espérons qu’un test unitaire soit passé au rouge et que ce ne soit pas les retours alarmants de la prod qui auront mis en avant le problème.

Continuons de réfléchir, de creuser les principes en profondeur et de prendre en compte notre contexte. N’appliquons pas bêtement et évitons les vérités absolues.

Ma réponse est NON (sans surprise, comme la plupart des articles qui commencent avec une grande question fermée). Un développeur doit être autonome et décider de lui-même pour ce genre de pratiques. Il n’a pas à demander l’autorisation à un manager, ni un chef, ni un PO, ni un SM, ni même à un tech lead ou un autre développeur.

Encore moins se voir interdire (anecdote récente lors d’un entretien technique, un développeur m’a indiqué que son client lui interdisait d’écrire des tests parce que ça prenait du temps). Au contraire, il faut promouvoir et pousser ces pratiques aux développeurs et aux équipes.

Ça fait partie du job

L’écriture de tests, le TDD, le Refactoring, le Pair Programming, et j’en passe, ce sont des pratiques répandues dans l’industrie. Elles sont reconnues et proviennent de mouvements comme le Software Craftsmanship, l’eXtreme programming, ou le Domain Driven Design. Ce n’est pas le n-ième nouveau super framework à la mode.

On parle ici de pratiques qui améliorent la qualité du code et du produit, qui facilite le changement, qui permettent de mieux collaborer, de mieux retranscrire le métier. Elles font partie intégrante du métier de développeur.

Un développeur n’est pas un exécutant. Il n’est pas là juste pour pisser du code. Il a un (grand) rôle à jouer pour concevoir un produit de qualité. Il existe de nombreux ouvrages sur ces pratiques et également sur la posture de développeur. Pour en citer un, Sandro Mancuso en parle très bien dans son livre The Software Craftsman.

Just do it

Je donnerais comme conseil aux développeurs de faire, de passer à l’action, d’utiliser ces pratiques. Sans attendre une permission officielle, sans aller chercher une approbation quelconque. Faites-le, tout simplement.

Il y a un proverbe qui dit Il vaut mieux demander pardon que demander la permission. Je l’aime bien, et je trouve qu’il a du sens dans cette situation. Vous êtes développeur et vous hésitez ? Lancez-vous, essayez, montrez par l’exemple. Probablement, quelque chose de bon en sortira et on ne viendra pas vous taper sur les doigts. Ce n’est pas parfait ? Vous deviendrez meilleur en continuant d’essayer et de vous améliorer.

Rappelons que le développeur a l’expertise. Il sait comment travailler, il connaît sa boîte à outils. Mon propos n’est pas d’enfermer le développeur dans sa vision - il doit rester ouvert, comme tout le monde - mais de lui faire confiance et de lui donner de l’autonomie.

Ce qui n’empêche pas de le challenger. Et quand on touche à ses limites, à sa zone où il ne maîtrise pas, on se penchera plutôt sur comment former, comment apprendre, comment expérimenter, plutôt que d’empêcher.

Former les équipes

Ça fait partie du job, d’utiliser ces pratiques, ça fait également partie du job de se former. Elles ne tomberont pas soudainement du ciel. Avis aux développeurs qui doivent faire l’effort autant qu’aux managers qui doivent investir ;)

On se forme, on forme les équipes, on expérimente, on s’améliore en continue. Le retour sur l’investissement est positif, on ira plus vite, on délivrera mieux. On veut démarrer un cercle vertueux (on apprend, on améliore le code, on change plus facilement, on livre plus vite, on satisfait davantage l’utilisateur) plutôt que vicieux (on empêche, on n’apprend pas, le code se détériore, les évolutions deviennent difficiles, on cumule des problèmes, on met du temps à livrer à l’utilisateur).

Il y a un tas de moyens pour apprendre. Quelques idées : inviter des personnes à faire un BBL, l’intervention de coachs, faire des katas seul ou en groupe, du mob-programming sur le projet, assister à des conférences, lire des livres, etc.

Casser les idées reçues

Et s’il y a du blocage, des interdictions, des permissions à demander pour utiliser ces pratiques ? J’essaierais de comprendre pourquoi, de challenger, de rappeler que ça fait partie du job, et de casser certaines idées reçues.

En rappelant la vision, la philosophie de certaines pratiques. Le refactoring, ce n’est pas un chantier de 3 mois en tunnel. Ce sont des petites étapes, ce sont des améliorations que l’on fait au quotidien, qui facilitent le changement, qui améliorent la qualité.

L’écriture de tests et le TDD, ce n’est pas plus long. C’est une aide pour le développeur, un guide pour bien retranscrire le métier, le comportement. On obtient en plus de la sérénité quand il faut effectuer des changements. On entre dans des situations où l’on ira plus vite.

Le Pair-Programming, ce n’est pas juste deux ressources humaines qui se mettent sur un poste pour travailler sur un seul problème à la fois. C’est une collaboration poussée, c’est un feedback rapide, c’est une transmission de connaissances, d’informations, c’est de l’amélioration en continue. Là aussi on entre dans des situations où l’on ira plus vite.

On améliore la qualité, on gagne du temps, on gagne de l’argent. Trois arguments que l’on peut aligner en fonction de l’interlocuteur. On pourrait citer en touche finale Accelerate, un livre qui montre, via une étude sur plusieurs années incluant de très nombreuses entreprises, qu’il y a une corrélation entre la performance technique et la performance business.

J’ai la conviction que ça ne prend pas forcément plus de temps de travailler en TDD. On est sensiblement sur la même longueur, parfois même plus rapide parce que ça nous guide. On est très loin du laïus “c’est une perte de temps”, surtout lorsque l’on regarde sur différents horizons de temps.

Il n’y a d’ailleurs pas que le temps qui entre en jeu, d’autres bénéfices gravitent autour de l’écriture des tests et de la pratique du TDD. Pour étayer mes affirmations, j’ai envie d’en parler à travers plusieurs prismes.

J’ai une mauvaise utilisation du TDD

Pour le premier prisme, je prends un développeur qui pratique le TDD mais qui l’utilise mal, qui ne le maîtrise pas. Je commence par ce postulat parce que c’est sûrement là qu’il y a le plus de confusion et de mécompréhension. Les personnes qui ne maîtrisent pas l’art de tester et du TDD se forgent un avis sur la base d’une expérience incomplète.

Qu’est-ce que c’est, ne pas maîtriser ? Penser que ça se résume à écrire un test en premier, que c’est purement de la technique (versus métier), ou que ça se limite à suivre le Red-Green-Refactor, par exemple.

En adoptant une mauvaise pratique, on va se mettre des bâtons dans les roues. On va vouloir tout mocker, on va tester l’implémentation, on ne va pas faire de petites étapes, etc. Résultat, on va trouver ça plus long. On va peut-être préférer ne pas faire de TDD, finalement. C’est plus long et il y a un tas de trucs chiants à faire, pourquoi s’emmerder.

Dans ce contexte, la méthode est mal comprise et mal appliquée. C’est probablement plus long de pratiquer le TDD, oui. Mais peut-on juger la méthode dans ces conditions ? J’y répondrais par une autre question. Est-ce qu’une voiture est lente parce qu’on roule avec le frein à main ? Ou parce qu’on ne sait pas comment passer les vitesses ? Non.

=> Oui, une mauvaise application du TDD peut demander davantage de temps. Non, dans ce contexte, c’est inexact de déduire qu’une bonne pratique du TDD prend du temps.

J’apprends le TDD

Dans ce second prisme, j’introduis une nuance : un développeur qui s’exerce à pratiquer le TDD mais qui ne le maîtrise pas encore parce qu’il est en phase d’apprentissage. La différence avec le premier prisme ? Il a conscience de la bonne pratique du TDD et il s’améliore pour y arriver. Il ne va pas mal faire tout en supposant qu’il maîtrise la méthode.

Disons les choses. Le TDD, c’est difficile. Ça demande du temps pour le maîtriser. Ça demande de s’entraîner, de répéter, de s’améliorer. Mais pour autant, c’est la phase d’apprentissage qui requiert du temps. Ce n’est pas l’application de la méthode elle-même. Encore une fois, juge-t-on la vitesse d’une voiture avec un pilote qui apprend à passer les vitesses ? Non.

Ok. Et durant cet apprentissage alors, à quel point ça prends du temps de faire du TDD ? Ça dépend. Ça dépend du contexte, ça dépend du niveau de compétence que l’on a acquis à cet instant.

Il y a des situations où l’on ne sera pas encore à l’aise, on devra ralentir pour bien faire, on prendra davantage de temps sur le moment. À l’inverse, il y a des situations où l’on sera guidé par le TDD et où l’on obtiendra plus rapidement un bon résultat. On va commencer à bénéficier des effets positifs (j’en parlerais après).

=> Oui, l’apprentissage du TDD demande du temps. Non, on ne peut pas dire que la pratique elle-même, une fois maîtrisée, prend du temps.

J’écris mes tests après

Je me mets maintenant dans le prisme d’un développeur qui écrit ses tests après coup. Que se passe-t-il si je me mets à faire du TDD ? On pourrait se dire que l’on va prendre davantage de temps, on écrit déjà des tests, pourquoi se compliquer la vie à s’ajouter une méthode ?

Eh bien, dans ce contexte, pratiquer le TDD sera probablement plus efficace et plus rapide. Le TDD va guider l’écriture de l’implémentation. On obtiendra une meilleure conception, on avancera par petites étapes et on sera guidé par le comportement métier. Ce sera une aide pour écrire de meilleurs tests et un meilleur code.

De fait, on s’évitera les pièges d’écrire du code non-testable, d’en faire trop, ou de ne pas correctement retranscrire le métier, comme on pourrait le faire en écrivant les tests a posteriori.

En écrivant les tests après, on subit l’implémentation. Et plus on attend pour tester, plus on subit. Il y aura davantage de changements à effectuer, le coût va augmenter. Le refactoring sera d’ailleurs difficile ; les tests ne sont pas écrits, on n’a pas encore notre filet de sécurité en place.

=> Non, ce n’est pas plus long de pratiquer le TDD lorsque l’on écrit déjà des tests a posteriori. C’est un gain de temps, et en plus, un gain de qualité.

Je ne teste pas

Je termine avec un dernier prisme qui n’en ait pas moins intéressant : celui du développeur qui ne teste pas. Alors là, réflexe, on va se dire que c’est bien plus long. Non seulement, il faut écrire du code supplémentaire (les tests), et en plus, il faut se coltiner une discipline stricte. On va perdre du temps, non ? Je propose de regarder sous deux horizons de temps.

Court terme

À court terme, sur l’instant, le TDD va nous guider. C’est une de ses principales forces. Il nous guide pour concevoir le code de production, l’implémentation. Il nous guide pour retranscrire le métier. Il nous offre une boucle de feedback extrêmement rapide pour créer et améliorer.

On prends le temps de bien faire et de réfléchir, mais pour autant, ce n’est pas forcément plus long. Parce qu’on se concentre sur l’essentiel en progressant par petites étapes, parce qu’on est guidé pour coder l’implémentation, parce qu’on a un feedback rapide contrairement aux tests manuels.

La pratique du TDD ne va pas seulement nous faire écrire des tests avant de coder, elle va nous aider à coder, à concevoir. Au final, on ralentit tout en gagnant du temps, pour mieux faire. On passe sensiblement le même temps à développer notre fonctionnalité.

Dans certains contextes, on est plus rapide, parce qu’on se serait perdu en chemin sans le TDD, parce qu’on aurait fait trop compliqué ou parce qu’il y a beaucoup de logique. On perd vite du temps à explorer sans test et sans guide. Dans quelques autres contextes, ça peut être plus long de pratiquer le TDD, mais c’est sans compter les effets obtenus à plus long terme.

Moyen et Long terme

À moyen et long terme, on va obtenir de nouveaux bénéfices grâce à la pratique du TDD. Les tests vont couvrir notre code et vont faciliter le refactoring et réduire les régressions. On va gagner du temps.

La facilité de faire du refactoring va aider à améliorer continuellement le système. On va le maintenir et le faire évoluer plus facilement. On va le changer facilement. On va gagner du temps.

On aura du code et des tests qui reflètent mieux le métier et les cas d’utilisations. On va mieux comprendre notre système. On va mieux échanger avec les autres. On va gagner du temps.

Bref

Au final, en regardant à travers ces différents prismes, on peut observer que les situations où un développeur trouve que c’est plus long de pratiquer le TDD est peut-être à décorréler de la méthode elle-même. Souvent parce qu’elle n’est pas encore maîtrisée.

Dès lors qu’on a une bonne pratique du TDD, des bénéfices apparaissent immédiatement, à court terme. La force que le TDD propose pour guider et donner du feedback rapide est assez puissante pour être d’une grande aide pour le développeur tout en ne faisant pas perdre de temps.

Ces effets s’accentuent à plus long terme, et d’autres viennent s’ajouter. On y voit un cercle vertueux d’amélioration continue. Ce n’est plus juste une question de temps, on y gagne sur plusieurs niveaux.

Avant d’entrer dans les détails, je vous propose de sortir un stylo et une feuille afin de vous poser la question suivante : qu’est-ce que le refactoring ? Faites couler l’encre, gravez votre définition dans les fibres du papier.

Définitions et fondamentaux

Le refactoring demande de la discipline et de l’apprentissage. Il existe des méthodologies, des principes et de multiples techniques. Ah bon, ce n’est pas juste tout refaire ? Non. On voit trop souvent ces fameux « chantiers » qui durent des mois, effectués en silo, sans visibilité et qui ont un résultat peu satisfaisant. Ils auront souvent duré bien plus longtemps que prévu, ou comporteront des régressions, ou seront abandonnés avant la fin. J’en ai vu et j’en vois malheureusement encore. J’en ai également fait, mais depuis, j’ai appris et je continue d’apprendre.

Aujourd’hui, j’ai envie de parler de ce qu’est le refactoring, de ses grands principes. Avant de se lancer dans ces grands chantiers, comprenons de quoi on parle. Je vais m’appuyer sur les définitions de Martin Fowler. Si vous ne le connaissez pas, c’est un des grands noms quand on parle de refactoring. Je vous recommande son site et ses livres.

noun: a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

verb: to restructure software by applying a series of refactorings without changing its observable behavior.

Je vois plusieurs fondamentaux dans ces définitions. C’est bien plus que « tout ré-écrire » ou même que « ré-écrire pour améliorer » (déjà plus précis, mais encore trop simpliste).

Faire du refactoring, c’est conserver le même comportement. Ne pas casser l’existant. Si on change le comportement, ce n’est plus du refactoring. On sépare le refactoring des évolutions et corrections de bugs. Dans le cycle du TDD, il y a une étape dédiée pour le refactoring ; ce n’est pas pendant qu’on écrit le test ni pendant qu’on fait émerger une solution. Lorsque l’on fait du refactoring sur la machine à café, on veut qu’elle continue à faire du café lorsque l’on a terminé. On ne veut pas qu’elle fasse un thé, ni un tiramisu. Et on veut encore moins qu’elle soit en panne.

Faire du refactoring, c’est avancer par petites étapes. On enchaîne une série d’améliorations, on évite de vouloir tout changer d’un coup. Ce sont des petites étapes que l’on peut partager régulièrement. C’est à dire les rendre disponibles aux autres, les committer, les rapatrier sur la branche principale. Ainsi, on peut s’arrêter à tout moment. Si soudainement on doit faire quelque chose de plus prioritaire ou partir en vacances, le projet est toujours dans un bon état et nos petites améliorations seront en plus intégrées. Dans l’hypothèse où les développeurs tirent leurs super-pouvoirs du café, si pendant un mois la machine est en chantier, donc inutilisable, ça posera des problèmes.

Faire du refactoring dans le but d’améliorer la compréhension et de diminuer le coût du changement. On peut vouloir rendre le code plus lisible, avec une intention plus claire, un métier mieux projeté. L’amélioration continue est importante. On peut vouloir également rendre le changement plus facile, donc moins couteux. Ré-écrire uniquement pour le plaisir du développeur d’intégrer le dernier framework X-2000 est peut-être une moins bonne raison. Notre machine à café a besoin d’un refactoring, car elle ne prend en charge qu’un seul type de dosette très précis.

Je pense qu’il est important de prendre conscience de ces fondamentaux et d’être dans cet état d’esprit afin d’améliorer son approche du refactoring. Bien sûr, il reste du chemin ensuite, ce n’est que le début du voyage, mais c’est une étape essentielle.

Aller plus loin

Pour continuer d’approfondir le refactoring, on peut regarder du côté de la détection de code smells, de l’apprentissage des techniques de refactoring, de méthodes pour structurer un refactoring, ou encore de l’art de tester du code legacy (casser des dépendances, introduire des tests, …). Oui, la liste est grande, ce n’est pas si simple. Et oui, il ne faut pas oublier les tests pour s’ajouter un filet de sécurité.

Quelques ressources autour du refactoring :

• Martin Fowler. Une figure incontournable avec son le site refactoring.com et son livre Refactoring Improving the Design of Existing Code.
• Michael Feathers. Une seconde figure incontournable, plus axée sur le code legacy avec son livre Working Effectively with Legacy Code.
• Le site refactoring.guru listant techniques de refactoring et code smells.
• Divers katas pour s’exercer comme le Gilded Rose, Tennis Game, Trivia, etc.
• Ici même, avec le temps, via le tag #refactoring.

Seconde édition

Vous avez toujours le bout de papier avec votre première définition ? Reprenez-le. Je vous propose d’écrire une nouvelle fois ce que représente le refactoring pour vous pour terminer. Au dos de la feuille ou sans relire les définitions a minima.

Amusez-vous à comparer les trois définitions maintenant. Et si le cœur vous en dit, partagez-moi vos écrits :)

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. Je dirais même que beaucoup ont vécu, d’un côté de la revue ou de l’autre.

Cette histoire vous est-elle familière ? À quel point la vivez-vous ? Vous en êtes-vous déjà rendu compte ? La review est-elle douloureuse pour vous ou votre équipe ? Prenez le temps de vous poser des questions.

Ce que l’on peut observer

Une grande partie du travail est refait. Perceval ayant créé quelque chose qui ne convient pas, du code est jeté. C’est du temps en partie perdu. De plus, la durée de la tâche s’allonge : qui dit suppression dit ré-écriture. Perceval a dû reprendre son travail avec une autre manière de faire. Les chances d’avoir des conflits à résoudre pour merge augmentent, leurs complexités aussi.

Perceval a passé beaucoup de temps tout seul et n’a eu le premier feedback que très tardivement - une fois qu’il pensait avoir terminé, ce qui augmente le coût de re-travail. Arthur a également mis du temps à faire la revue car il y avait beaucoup de code à lire.

Les discussions sont à l’écrit, et en décalées. La revue est ouverte, plus tard des commentaires sont ajoutés, plus tard des retours sont effectués, et ainsi de suite. Le temps d’attente peut être long. La tâche met plus de temps à être terminée.

À chaque aller-retour, il y a un changement de contexte. La personne (auteur ou lecteur) doit arrêter ce qu’elle était en train de faire, doit se plonger dans la revue, puis se remettre sur son ancienne tâche avec la nécessité de se re-plonger dans ce qu’elle faisait. Ce temps n’est pas négligeable.

Et que ressent Perceval ? Quand il apprend qu’il doit tout refaire. Quand il lit les commentaires d’Arthur, sujet à interprétation, pouvant être pris personnellement.

Ce que l’on peut faire

On communique davantage. On donne du feedback tôt et régulièrement. On collabore. Perceval et Arthur peuvent échanger dès le début de la tâche, pendant, et même à la fin lors de la revue. Ils peuvent la faire ensemble sur le même poste. Et soyons fous, ils peuvent se mettre au pair programming. Ça y est, on y vient.

Qu’en pensez-vous ? Remémorez-vous la première histoire.

En travaillant de paire, le feedback est immédiat et continu. Arthur accompagne en temps réel Perceval. Il n’y a plus d’aller-retour ou d’échanges à l’écrit, ni d’attente, ni de changement de contexte. Il n’y a même plus besoin de faire de code review, chaque retour a été pris en compte sur le moment et le résultat est de meilleure qualité. Avec le pair programming, la revue de code est poussée à son extrême : le binôme en fait tout le long, à chaque instant.

Les échanges sont plus humains et plus riches. Chacun apprend, partage. Chacun challenge et améliore le code écrit. Chacun comprend le code et la fonctionnalité - la propriété est collective. Les bénéfices du pair programming sont multiples. Alors pourquoi attendre ? Une heure, une journée, une fonctionnalité de bout-en-bout, … Lancez-vous. À votre rythme, mais lancez-vous.

Testez, observez ce qui change, prenez du feedback. Apprenez à faire du pair programming, acceptez au début de ne pas savoir faire, améliorez-vous. Et appréciez :)

Post-scriptum du prêtre : toute ressemblance avec des personnes existantes ou ayant existé dans la légende arthurienne ne saurait être que fortuite. Ou pas. Je suis en manque de film Kaamelott.

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. Pourtant, je pense qu’une (trop grande) partie des personnes passe à côté de concepts essentiels et ne se pose pas les bonnes questions. Malgré la bonne intention, ça peut être dangereux. J’aimerais amorcer une prise de recul et ouvrir des questions.

Et si on prenait du recul ?

Je vois des discussions qui tournent seulement autour du pattern, du diagramme de classe. “Le Presenter fait ceci et cela. Il parle à celui-ci ou à celui-là.” Quand je demande ce qu’est la Clean Architecture, on me répond souvent en me récitant un diagramme de classe. Pas un mot sur l’abstraction, l’entrée/sortie, l’inversion de contrôle, … Et encore moins sur l’isolation du métier.

J’ai également assisté à des entretiens et des échanges avec des développeurs qui s’acharnent avec des suites de questions pour savoir si Machin va plutôt dans le Router ou Interactor ou Presenter, si c’est pas à Bidule de faire ça, et le rôle de Truc là-dedans, … Plutôt que de parler de l’esprit de la Clean Architecture, ils ne parlent que des classes.

Certaines équipes utilisent la Clean Architecture comme cadre pour empêcher les développeurs d’en sortir, en suivant un modèle à la lettre. Faire sans comprendre, sans réfléchir ne mène pas très loin. À quel point cela vaut le coup, de rendre des choses difficiles, d’ajouter de la complexité pour empêcher des développeurs de sortir des rails ? Il y a peut-être d’autres choix à explorer.

Dans tout ça, on oublie le pourquoi. On se concentre trop sur le comment. Pourquoi on l’utilise ? “C’est pour découper. C’est pour pouvoir tester.” me dit-on souvent, sans trop détailler. Oui, mais pourquoi ça devient “plus découpé”, “plus testable” ? Quels concepts y a-t-il derrière ? Pourquoi fait-on cela ?

Et si on se recentrait sur le métier ?

Le métier est la partie la plus importante du produit. Sans métier, le produit n’existerait pas, l’équipe ne le fabriquerait pas. C’est le cœur du programme et de l’entreprise. Certaines règles vont au-delà du programme. La répartition des places dans un train par exemple. Cette règle peut être présente dans plusieurs programmes différents et existe même en dehors de tout ça, dans le monde réel.

Ces règles ne dépendent pas d’un choix technique ou d’un framework, elles ne sont pas affectées par un changement technique. On change de base de données ? Pas de problème. On n’a pas encore choisi la base de données ? Pas de problème non plus. On change de framework ? Aucun souci.

Les règles devraient pouvoir changer aisément, le monde évolue constamment. On devrait les trouver et les comprendre facilement puisque c’est le cœur du programme. C’est pour toutes ces raisons qu’il est important d’apporter une grande attention sur cette brique. De la protéger de l’extérieur. De la rendre compréhensible, lisible. De la tester.

Le schéma de Clean Architecture représenté par les 4 cercles va d’ailleurs dans ce sens. On retrouve les règles métiers et les règles applicatives au centre. Et uniquement ça. Pas de framework, pas de base de données, pas d’interface graphique. Les frontières protègent les cercles à l’intérieur de l’extérieur. C’est aussi l’esprit de l’architecture hexagonale et du DDD (Domain-Driven Design).

Le métier est au centre parce qu’il est très important. Parce qu’on veut le protéger. Parce qu’on veut en prendre soin. Le reste, c’est du détail. Du détail d’implémentation.

Et si on se penchait sur les principes ?

La programmation orientée-objet a son rôle à jouer, bien plus que ce que l’on apprend souvent à l’école (vous savez, ce fameux héritage pour classifier des animaux). Certains concepts qui gravitent autour de la POO se cachent derrière la Clean Architecture et sa séparation des couches.

L’abstraction par exemple. Avec l’abstraction, on cache les détails de l’implémentation. On veut utiliser quelque chose sans savoir comment ça fonctionne derrière. On s’enlève cette complexité. Je veux enregistrer un favori sans savoir de quelle manière il sera stocké.

L’inversion de contrôle et l’injection de dépendances sont un autre exemple. Ces concepts sont présents pour renforcer les frontières, pour protéger les cercles. On veut que les cercles discutent entre eux, mais sans qu’un cercle intérieur n’ait connaissance d’un cercle extérieur. On découple. Un Use Case peut interagir avec une base de données sans que ce code ne soit à l’intérieur du cercle, de son module. Cette brique est indépendante. Ainsi, les changements autour de la base de données ne vont pas affecter le Use Case. Et c’est tout de même le Use Case qui est aux commandes, qui utilise la base de données.

On parle de modularité en programmation orientée objet. D’autres concepts sont également là. Je vous conseille de prendre le temps de les découvrir et de les comprendre. De voir comment tout cela s’articule, et d’aller au-delà de la Clean Architecture. S’ils ne vous intéressent pas, alors prenez encore plus de temps pour creuser le sujet. Mais n’en restez pas à l’application d’un pattern.

Et si on explorait plus loin ?

La Clean Architecture apporte de bonnes choses, mais ce n’est pas une silver bullet pour autant. La solution miracle n’existe pas. C’est une solution parmi d’autres. Il faut la comprendre, savoir ses forces et faiblesses, connaître ses principes, l’approfondir.

Il faut également explorer ce qu’il y a autour. L’architecture hexagonale est une approche similaire par exemple. Elle accorde beaucoup d’importance au métier, le place au centre et le protège avec un système de ports et d’adapters. Une approche simple qui se marie très bien avec le Domain-Driven Design (un tas de choses à voir là-dedans, je recommande pleinement de s’y plonger). Le Functionnal Core, Imperative Shell me semble être un autre moyen intéressant.

Et il faut garder en tête les différents principes de programmation. Ils sont toujours là, peu importe le choix de l’architecture. Ils vous accompagneront pendant longtemps.

Cherchez à comprendre et approfondissez, n’appliquez pas sans réfléchir. Soyez ouvert et explorateur, ne restez pas enfermé dans une vision unique. Et appréciez :)

Dans cet article, je vous propose d’explorer 5 principes qui pourront vous guider et vous challenger pour l’écriture de vos tests unitaires. Ces principes sont connus sous l’acronyme FIRST, signifiant avoir des tests :

• Fast 🚅
• Independent 📦
• Repeatable ♻️
• Self-validating ✅
• Timely ⏱

En s’inspirant de ces bonnes pratiques, la qualité de vos tests s’améliorera et la qualité du projet et du code de production suivra. Pour mieux comprendre ces principes, faisons le tour de chacun d’eux en explorant leurs raisons d’être, les possibles problèmes en cause et des pistes de solutions.

F : Fast 🚅

Exécuter un test doit être rapide, et surtout, lancer l’ensemble des tests doit être rapide. Cela inclut le temps des setup et teardown, et même de la compilation. Un test unitaire rapide mais avec une longue compilation ou un long setup est un test long. Si vous hésitez pour lancer vos tests après une modification, c’est que vos tests sont probablement trop longs.

Lorsque les tests sont longs, les workflow de développement et de déploiement sont ralentis. Par ailleurs, un des bénéfices des tests unitaires est d’obtenir un feedback rapide. Pour conserver cet aspect, il faut que les tests soient rapides.

C’est encore plus important lorsque vous utilisez un outil qui exécute automatiquement les tests unitaires impactés par vos modifications. C’est le cas en C# par exemple, avec Visual Studio et le Live Unit Testing.

Mais alors, qu’est-ce qu’un test long ? Prenons 150ms. Ça n’a l’air de rien, mais si chaque test prend 150ms, le cumul peut devenir bien plus long. Sur un projet ayant 2000 tests, et cela peut vite augmenter si l’équipe en ajoute régulièrement, on arrive à un total de 5 minutes ! Cumulé sur une journée, c’est énorme et c’est sans compter le temps de compilation ou de setup.

Un temps aussi grand va créer un point de douleur qui va démotiver le développeur, ce qui aura pour conséquence de diminuer la fréquence à laquelle il lance les tests. Dans le pire des cas, il pourrait même ne plus du tout lancer les tests.

Pour avoir un feedback rapide, il est nécessaire de lancer très souvent les tests pendant que l’on développe. En perdant le feedback rapide, on perd aussi du temps. On obtient bien plus tard l’information que quelque chose a cassé. De nombreuses modifications ont pu être ajoutées et il faut identifier laquelle est responsable de l’erreur.

Causes

Les dépendances lourdes comme les accès à une base de données, les appels réseaux, ou les lectures de fichiers sont souvent les responsables d’un test long. Ces opérations durent des centaines de millisecondes, voire plusieurs secondes.

Parfois, les traitements asynchrones ralentissent les tests par le traitement lourd qu’ils peuvent faire, et possiblement aussi par la manière dont les tests gèrent l’asynchronisme (le test étant bloqué tant qu’une réponse n’est pas arrivée). Le multithreading peut poser le même problème.

Solutions

L’injection de dépendance, ou le principe d’inversion de contrôle, est un moyen efficace de s’abstraire des dépendances. Les implémentations réelles sont remplacées par des simulacres, comme des Test Double, qui permettent de simuler des comportements.

En créant une classe qui agira à la place d’un service effectuant une requête HTTP, par exemple, on obtient la flexibilité d’avoir la valeur que l’on souhaite immédiatement. Retourner des objets prédéfinis dans une fonction est une instruction instantanée contrairement à un appel réseau.

class TimeoutArticlesProvider: ArticlesProvider {
        
    func fetchAllArticles(completion: ((Result<String, ApiError>) -> Void)) {
        completion(.failure(.timeout))
    }
}

I : Independent 📦

Un test ne doit pas dépendre d’un autre test. Le résultat d’un test ne doit pas non plus affecter un autre test. Cela peut causer des faux positifs ou cacher un problème. On perdrait du temps à parcourir plusieurs tests pour découvrir l’origine d’une erreur.

On devrait pouvoir lancer les tests dans n’importe quel ordre. De même, on devrait pouvoir lancer n’importe quel sous-ensemble de tests : un seul, une suite de plusieurs tests, ou tous. Si ce n’est pas le cas, c’est une indication que certains tests dépendent les uns des autres.

Tendre vers des tests indépendants permet de focaliser chaque test sur un comportement précis, ce qui donne davantage de sens au mot unitaire. Un test ne devrait avoir qu’une seule raison d’échouer. Cela permet d’identifier rapidement la cause d’une erreur, on comprend tout de suite pourquoi le test a échoué. On évite ainsi une longue session de debug.

On veut donc se rendre indépendant d’une base de données par exemple, pour éviter que l’écriture dans un test A affecte le résultat d’un test B. Ce peut être la même chose pour des singletons, des fichiers. Eventuellement, on va vouloir devenir indépendant de choses lourdes comme les appels réseaux, notamment pour respecter les principes Fast et Repeatable.

Attention à ne pas tomber dans l’extrême. On ne veut pas que le SUT (System Under Test) soit isolé de tout. Non. On veut seulement rendre le test indépendant. Le SUT peut être une classe comme un ensemble de classes, un module. Tout mocker posera des problèmes et rendra le test fragile.

Causes

Compter sur un enchaînement de plusieurs tests afin d’effectuer des actions prérequises à l’exécution d’un autre test va créer un lien de dépendance. De même que partager un état avec d’autres tests. On peut par exemple retrouver ces états dans des propriétés de la classe de test, dans des singletons, dans des bases de données, dans la lecture et l’écriture de fichiers… Bref, tout ce qui est partagé.

Solutions

Ici aussi l’injection de dépendance aidera à remplacer les dépendances gênantes pour le test. A celà, on peut ajouter le modèle Arrange-Act-Assert afin de structurer l’écriture d’un test en trois grandes parties en plus d’apporter de la rigueur et de la cohérence entre les tests.

• Arrange : on prépare toutes les données requises pour le test, ainsi que l’état dans lequel le test doit se trouver. On s’abstrait des autres tests et de l’environnement, ainsi que des dépendances en créant les Test Double nécessaires.
• Act : la méthode testée est appelée. Les données requises ont été initialisées dans l’étape précédente, et les dépendances injectées.
• Assert : on vérifie que le résultat est bien celui qu’on attend grâce aux différentes méthodes Assert du framework de test. Un test doit tendre à n’avoir qu’un seul assert pour n’avoir qu’une seule raison d’échouer. Dans certains cas, on peut avoir plusieurs assert lorsqu’ils se regroupent sous une même logique.

class HelloServiceTests: XCTestCase {
    
    func testMakeMessage() {
        // Arrange
        let now = 1587301244
        let dateProvider = FakeDateProvider(now: now)
        let service = HelloService(dateProvider: dateProvider)
        
        // Act
        let message = service.makeMessage()
        
        // Assert
        XCTAssertEqual(message, "1587301244 - Hello.")
    }
}

Un autre moyen de donner de l’indépendance aux tests est d’utiliser les méthodes de setup et de teardown. Ces méthodes sont respectivement appelées avant et après l’exécution de chaque test. Le teardown est très utile pour effectuer un nettoyage après chaque test, par exemple.

Le nommage des tests a son importance et peut aider à rendre des tests indépendants. Chercher à mettre en valeur l’intention du test à travers son nom force à tester un comportement plus précis. Et par la même occasion, cela facilite la compréhension pour déterminer pourquoi le test a échoué.

Certains frameworks ou IDEs proposent d’exécuter les tests dans un ordre aléatoire. Activez cette option. Vous aurez rapidement une idée quels tests ont un problème, et cela vous empêchera peut-être d’ajouter un nouveau test dépendant.

R : Repeatable ♻️

Un test doit toujours produire le même résultat. Toujours. Peu importe le nombre de fois où il est exécuté, la date ou le lieu. Si un test ne réagit parfois pas de la même manière, on ne peut pas lui faire confiance.

Comment savoir si la raison d’un échec est “normale” ou réellement problématique ? À quel point les erreurs sont bien détectées ? En se posant sans cesse des questions sur les tests, on perd en sérénité, rendant alors les changements dans le code plus difficiles et plus hésitants.

Pour un état de départ donné et une action exécutée, on doit pouvoir prédire la réponse. Sans résultat déterministe, les sessions de debug seront plus compliquées lorsque des erreurs surviendront (et idéalement, on n’a pas besoin de debugguer). Certains problèmes pourraient être difficiles, voire impossibles à reproduire à l’identique.

Un test doit éviter de dépendre de sources de données non-prévisibles. Des sources changeantes, pouvant être indisponibles, des états extérieurs ou des environnements sont des dépendances empêchant d’obtenir continuellement le même résultat.

Causes

Les bases de données sont des sources de données changeantes. Elles pourraient être modifiées par d’autres tests ou d’autres lancements. Les APIs web peuvent également exposer des données différentes à chaque appel, en plus d’être potentiellement indisponible (serveur en maintenance) ou inaccessible (panne de réseau).

Tester du code utilisant ces types de dépendances donnera un résultat incertain. Les singletons, les configurations et les environnements peuvent aussi être responsables d’un test ayant une sortie non garantie. Plus souvent oubliés : l’utilisation des dates et des fonctions aléatoires.

Solutions

On veut toujours avoir le même résultat, donc on veut contrôler entièrement le test, donc on doit rendre contrôlable certaines dépendances. L’injection de dépendance permettra de s’abstraire des sources de données non-prévisibles en ayant le contrôle sur les réponses générées. Par exemple, on peut simuler une requête échouant suite à un timeout pour les besoins d’un test, et par ailleurs simuler un succès pour un autre test.

Cette même solution peut être utilisée pour gérer les dates et les fonctions aléatoires. Pour cela, on transforme l’accès à la date en le rendant indirect, via une interface, afin d’ajouter une abstraction qui permettra de remplacer la valeur réelle par un Test Double dans les tests.

protocol DateProvider {
    var now: Date { get }
}

class DeviceDateProvider: DateProvider {
    var now: Date {
        return Date()
    }
}

class HelloService {
    
    private let dateProvider: DateProvider
    
    init(dateProvider: DateProvider = DeviceDateProvider()) {
        self.dateProvider = dateProvider
    }
    
    func makeMessage() -> String {
        let now = Int(dateProvider.now.timeIntervalSince1970)
        return "\(now) - Hello."
    }
}

En complément, le modèle Arrange-Act-Assert apporte la structure pour définir la valeur des Test Double et l’état initial. On peut aussi s’appuyer sur les méthodes de teardown pour faire un nettoyage après chaque test.

S : Self-validating ✅

Chaque test doit être autonome pour déterminer si le résultat correspond aux attentes. Personne ne devrait intervenir. Sa sortie est simple : un test a réussi ou a échoué.

Il ne devrait pas y avoir besoin d’interprétation manuelle. Si on est amené à lire un fichier, à comparer des résultats, à chercher des informations, il y a un risque de faire une erreur humaine. C’est aussi plus long et rébarbatif, ce qui pourrait décourager les développeurs de lancer les tests.

Un test ne devrait pas non plus nécessiter d’action manuelle, ni avant le lancement, ni après. Il ne faut pas avoir à intervenir pour préparer un environnement ou nettoyer des artefacts, par exemple. Si un tel besoin est présent, il faut l’automatiser ou l’intégrer dans le test.

Solutions

Avec les outils actuels, les tests respectent globalement déjà ce principe. Il suffit d’ajouter une assertion dans un test pour qu’il puisse valider lui-même le résultat ; le framework et l’outillage s’occupe du reste. L’assertion la plus basique est une déclaration indiquant que quelque chose doit être vrai.

Les frameworks de tests proposent en général plusieurs méthodes d’assertion : assert true, assert not null, assert equal, assert throw exception, etc. Au moins l’une de ces instructions doit être présente dans un test.

L’interprétation du résultat des tests peut s’améliorer avec des solutions plus visuelles. Certains frameworks et IDE proposent des interfaces graphiques listant les tests et mettant en valeur les succès et les échecs.

En ce qui concerne l’automatisation pour éviter une intervention manuelle, là encore l’injection de dépendance et la structure Arrange-Act-Assert sont utiles. En préparant et simulant un environnement spécifique pour un test, par exemple.

T : Timely ⏱

Un test doit être écrit au bon moment. Idéalement, le test est écrit juste avant le code de production qui fera réussir le test. Ce mode opératoire apporte de réels bénéfices et fait la différence. De cette manière, on avance par plus petits bouts et on se concentre sur l’essentiel. Les tests, déjà écrits, nous aident et nous guident. On voit émerger le design du code.

À l’opposé, écrire les tests après le code de production comporte des risques. L’ajout de tests a posteriori est plus long et plus difficile. Cela nécessite un travail supplémentaire : il faut souvent adapter le code de production qui n’est pas testable. Ce travail est parfois conséquent et coûteux. Plus on éloigne l’écriture des tests, plus ce risque sera grand.

Outre la difficulté, la motivation peut baisser lorsqu’il s’agit d’écrire des tests lorsque l’on a terminé. Un sentiment de culpabilité peut également naître en pensant au temps supplémentaire à passer pour ajouter des tests et adapter le code de production alors que tout est déjà prêt.

Solutions

Commencer par écrire un test fait partie de l’approche Test-Driven Development (TDD). Le développement est guidé par les tests. On est guidé pour implémenter le comportement par petites étapes. Suivre cette pratique, c’est suivre un cycle précis : RED, GREEN, REFACTOR.

Pour faire simple, on écrit d’abord un test qui échoue ou ne compile pas : c’est rouge. On cherche ensuite à passer au vert en écrivant le minimum de code de production, en allant au plus simple. Puis on refactorise, on améliore le code de production et le code des tests. La boucle est bouclée, alors on recommence. On itère jusqu’à ce qu’on ait répondu au besoin et qu’on soit satisfait du code.

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.

Quarantine strategy ☣️

Most of the violations can be fixed without problem, but there are many. Then there are more complex issues. Some violations will need refactoring.

You will need time to handle every warning, and you have to take time. Do not go fast, do it well. As you may not fix everything at once, you will have to do it progressively. But how? How can we take time and live with so many warnings?

Our strategy will be to isolate infected files and exclude them, then to fix violations and files over time. This strategy also plans to visualize progress and prevent regressions.

Autocorrect is our magic wand

Before you start the quarantine, you can run the swiftlint autocorrect command. Only a handful of rules can be automatically corrected, but it is pretty efficient and it can save you a lot of time and effort.

Autocorrecting is the easiest part. It is automatic, and it is mainly dealing with spaces and indentations. Be sure to check changes after running the command.

Exclude infected files

More than a thousand of warnings on dozens of files. That’s what you can have. The goal of this step will be to fall to zero violation, as if there were nothing, but without fixing.

The idea of quarantine is to exclude all infected files from the analysis. An infected file is a file containing at least one violation. Only healthy files and new files will be linted.

In order to make the job easier, I wrote a script to list all infected files in a project. It will run SwiftLint, extract paths, and even format the output list.

#!/bin/bash

current_pwd=`pwd`
escaped_pwd=$(echo "$current_pwd" | sed 's/\//\\\//g')

# run swiftlint, grep to filter only lines with .swift, sed to extract paths, sort to group paths, sed to remove first slash, sed to add

Pods/SwiftLint/swiftlint | grep .swift: | sed 's/^\([^:]*\):.*/\1/' | sort -u | sed "s/$escaped_pwd//" | sed 's/^\///' | sed 's/\(.*\)/- \1/'

This script assumes that you did install SwiftLint in your project with cocoapods, and that you put the script in the root folder of your project. Feel free to change paths. The output of your terminal will look like that:

Loading configuration from '.swiftlint.yml'
Linting Swift files at paths
Linting 'ArticleListViewController.swift' (1/464)
Linting 'ArticleViewController.swift' (2/464)
...
Linting 'Widget.swift' (464/464)
Done linting! Found 336 violations, 30 serious in 464 files.
- MyApp/Article/ArticleListViewController.swift
- MyApp/Article/ArticleCell.swift
...
- MyWidget/Widget.swift

The first part is printed by SwiftLint. It is telling you which files are analyzed. The second part is the list of infected files with the relative path. This list is formatted. You will just have to copy and paste the result in the configuration file .swiftlint.yml under `excluded keyword. You may have to indent it.

excluded:
— Pods
- MyApp/Article/ArticleListViewController.swift
- MyApp/Article/ArticleCell.swift
...
- MyWidget/Widget.swift

From now on, the number of warnings is zero and we are preventing problems on healthy files. A warning will appear as soon as a code will violate a rule on these files. And that’s because SwiftLint is still integrated, enabled and fully configured with the rules you choose.

Only infected files at the quarantine creation are excluded. Their warnings are hidden and you will be able to handle them progressively. This step is performed only once, you may not have to exclude new files. We can imagine doing another quarantine if a change causes a lot of warnings (changing your rules or updating SwiftLint for example).

Treat infected files

Each time you have to edit an infected file, take the opportunity to correct few violations. Sometimes, you can also choose to pick a file and to treat all of its problems at once. Do not forget to remove a file from the excluded list when it becomes healthy.

Try to decide how you can take time to reduce warnings over time. Discuss about it with your team, with the other developers and also with your Product Owner or your manager. It can be for example two hours every Monday morning.

Visualize your progression

When you have hundreds or thousands of violations, it is helpful to know where you are and how numbers are evolving. It will also motivate your team to decrease the total of warnings.

You can create a second SwiftLint configuration file without excluded files in order to lint everything. Give it a different name, and specify it when running the swiftlint command: swiftlint --config .swiftlint-full.yml.

Your basic configuration is used to show you warnings through Xcode, without files in quarantine, and your CI or an other tool can execute SwiftLint with the second configuration in order to have a global vision. This way, you can make charts or have the current count to follow your progression.

In a dedicated article about SwiftLint, I wrote a part about the power of visualization. You can find how to easily have charts with Jenkins, or with a sheet of paper if you do not have any CI.

Forbid regression

While you are healing infected files, and even when the whole project is healthy, you should prevent new violations. Do not add new errors when you are writing code.

For that, set up your CI to fail a build if there is new lint errors. You may otherwise want to take a look at pre-commit git hooks, to forbid a commit containing violations, or at Danger to have automatic messages on your pull requests.

It is also helpful to use a second SwiftLint configuration here, linting infected files, to see hidden warnings. Remember that the quarantine disable analysis on infected file. So you need something to warn you if you are adding new violations inside these files.

Alternative ideas 🔀

Disabling rules

The principle of this quarantine strategy is to exclude from analysis each files containing at least one warning or error. Another possibility is to disable every of your rules in your configuration file.

This way, you will end up with zero violation. You can then re-enable a rule and fix corresponding warnings. One rule by one rule. It will give you the flexibility to correct problems progressively. The counterpart is that you will disable rules for every files, even healthy files or new ones.

Nested configurations

You can also profit nested configurations with SwiftLint. You can put different configurations in subfolders. Thanks to that, you can choose to specifically enable or disable rules in your project hierarchy.

We can even imagine combining both approaches: putting some files in quarantine, and disabling certain rules on specific subfolders.

Make your code consistent, and go further

If you want to know more about code consistency and how to unleash the power of SwitLint, you can read two of my previous articles:

• Make your code consistent
• Unleash the power of SwiftLint

And that’s all for now 👋

Thanks for reading. Feel free to make any feedback and to open discussion. Let’s finish with you. How are you using SwiftLint? Do you have any tips to share when you have too much warnings? What did you learn?

So, you can see me coming: why not consider doing the same control for our code style? Guess what, there is a tool doing exactly what we want: SwiftLint.

Hello, SwiftLint!

SwiftLint is a lint tool dedicated to Swift language. Lint means that the tool can analyze your source code and check it for programmatic and stylistic errors. It will help you make it consistent and better.

By running it, SwiftLint will flag every part of your code that does not respect the configured rules.

Today, SwiftLint is composed of *more than 150 rules of different categories. The project is open source, has a good community, many users, a lot of contributors, and regular releases.

What can you find ? Here are some examples. Stylistic rules that are about jumping lines, spaces, place of arguments, alignments, or a lot of other preferences. Smell code rules that are enforcing the compiler to detect bad things, complex code or optimized way. Also opt-in rules, that can be adopted depending on context.

There is a default configuration, but you can choose which rules you want to enable or disable. Moreover, particular rules have an advanced configuration like setting a trigger level, excluding a couple of strings, or choosing a severity. If you want to know more about installation and basic configuration, you can go to the GitHub page of the project.

https://github.com/realm/SwiftLint

How it works

As you can see, there are multiple ways to install SwiftLint. I recommend you to install it with Cocoapods, you will share the same version of the tool across your team machines, and updating on all machines will be easier. Otherwise, Homebrew is a good alternative.

SwiftLint is a command line tool, so you can execute it in any console. It can output several formats like JSON, XML, or Xcode. Yes, there is an Xcode format allowing you to integrate SwiftLint into Xcode. Useful to get real-time feedback. Other formats can be used by your CI.

You should add a build phase in Xcode with SwiftLint to analyze your code at each build. The benefit is that you will be alerted almost instantly when you do not respect a rule. Moreover, SwiftLint is well integrated with Xcode: reported problems look like compilation warnings and errors.

To configure SwiftLint, you can add a .swiftlint.yml file inside the root directory of your project. You can find the file structure here, and a listing of all rules here. You will be able to choose which rules you want to enable, and parameters for these rules. For example, setting a maximum function body length to 10.

SwiftLint is flexible, you can disable rules, folders or files through the configuration file, and you can even disable specific lines directly in your swift file! Simply by putting a comment like // swiftlint:disable:mode <rule name>. Here are some variants for disabling the current line, the next line, or until you re-enable the rule.

One more thing. You saw that SwiftLint can report you violations. Guess what, there is a command to automatically correct certain rules: swiftlint autocorrect. Only a handful of rules can be corrected by this command, but it is working great.

Now that you are used to SwiftLint, I can share some of my personal experiences with you and some ideas to go further. Feel free to use it.

Unleash the potential of SwiftLint 🚀

Guide SwiftLint to guide you

Debate about your code convention, read every SwiftLint rules and determine which ones you want to enable. You will take control of SwiftLint, and SwiftLint will control your code.

We saw that SwiftLint is about enforcing your code style and convention. A first step can be to create your code convention if you don’t have one, or to ensure it is still up-to-date with your team. You can find inspiration in existing ones like Swift.org API Design Guidelines or Raywenderlich Style Guide, and choose to use a little part or almost all of it. The most important is to make your rules explicit.

Then the important step is to fully configure SwiftLint. The default configuration is a good start, but if you want to match your convention, you will have to read all available rules. A lot of rules are not enabled by default.

For each SwiftLint rule, you should decide if you want to enable it or not, and configure it. This is an interesting part because you may discover new rules to make your code better.

Remember to get your whole team involved. The best is to do it together. Or at least get the approval of your team if you are doing it alone, and ask for feedback.

Mastering rules

A lot of rules exist, and you should check the complete list with details and examples to learn more about them. If you want to be up-to-date and see precisely what’s new, you can check the release page on GitHub. This is useful when you are updating SwiftLint to discover how rules changed and how it can impact your project.

You can also go deeper. SwiftLint is open source, so you can look how a rule is implemented if you want. I did it when I wanted to know more about how a rule works or which parameters have to be used to configure it. Sometimes, it was just curiosity :)

Visualize your progression

Visualization is something very powerful. If you are looking on agile culture, many elements are visible. Metrics, charts, stories, sketches, … All of these are easily accessible, sometimes physically, by everyone. Teams know where they are, and where they go.

We can do the same for SwiftLint. When you have a lot of warnings (typically when you are adding a strict configuration on an existing project), it helps and motivates to know where you are and how numbers are evolving. You can have a metric for the main branch, the number of current warnings, and a chart gathering warnings through time. Put this on a dashboard, always visible, and you will see a super team improving the project.

If you have Jenkins, there is a simple way to get a graphic by using a plugin. For example, I chose androidLint. I added this plugin and I created a python script to convert the output of SwiftLint into the corresponding format. Then, I added a step in the Jenkinsfile: for each commit, SwiftLint is executed, the output is converted, and the plugin is called. This way, you can have a graph for each branch. You can analyze your feature branch, short-term, and also develop and master branch, long-term.

You do not have a dashboard, a CI, or any tools? Let’s return to the future! Pick a pen, a sheet of paper and a post-it. We can write the current amount of warnings on the post-it and draw a chart on the sheet. Time on x-axis, and warnings on y-axis. Every day (or week or whenever you decide), put a new post-it with the updated number, and add a new point on the chart. Quick and efficient.

Limit regression

When you are putting effort to decrease the number of warnings, I think that you prefer to not add new violations. For that, you can add a safeguard.

You can set up your CI to fail a build if there is new lint errors. It can be done with the androidLint plugin on Jenkins for example, by configuring failedTotalHigh and failedTotalNormal arguments.

You may otherwise want to take a look at pre-commit git hooks, to forbid a commit containing violations, or at Danger to have automatic messages on your pull requests.

Nested configurations

Thanks to the YML file, you can configure every parts of SwiftLint for your project and your team. You are choosing which rules you want. And you can do more.

If you put an other configuration file deeper in the arborescence, it will be used instead of the main configuration at the root folder. Meaning, you can have specific rules for a specific folder including its children.

When linting a file, SwiftLint use the configuration in the current file folder, if any. Otherwise, it will recursively look in parent folders if there is one. If none, it will use the configuration file in the folder where the command was executed. And by default, SwiftLint uses its hardcoded default.

A possible use case is to have different rules for your unit tests target. You may want to have certain rules disabled or configured with different parameters. Be careful to not disable too many rules, your unit tests code is important and should be readable too.

Disabling a rule through code should be use sparingly

Do not abuse of disabling a rule inside a swift file with a comment. It can be tempting but it can hide another problem. Ask yourself why are you disabling the rule here.

Is it the first time I disable this rule? If not, you may need to reconsider this rule, or to configure it more accurately. Is it a real exception, or is it laziness ? You should have a good reason to disable it.

Let’s finish with you. How are you using SwiftLint? Do you have any tips to share? What did you learn?

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. Moreover, you can use these discussions to improve group cohesion and build a shared vision.

Write readable and consistent code

Sometimes, I see myself as a writer. Not as a code writer, but as a story writer. I try to tell a story with my code in order to make it easier to understand. I do my best to make it as readable as possible, and to make it consistent. I think that a well-written story is a story that reads well. The sentence may seem funny, but as a writer, you will be read.

Your code can be read by a coworker during a code review, or when adding a new feature. It can also be read by you, later. Oh, I just said coworker. Your code may be a part of someone else’s code, or even several people. Different people writing the same story? Will it be easy to read? It can be, and one of the way is to make it consistent.

By having consistent code, you can focus on the functionality and not on the style.

You will not be distracted by a different syntax of a coworker or an old code. Furthermore, it will be easier for a new member to join your team. The story reads as if it was written by only one author.

Writing consistent code can be more than just having the same style. It can also be sharing good practices. Consider for example force unwrapping, function body length, or the preference to use first(where:) or filter{}.first. All this works, but, depending on your thought, they can be improved. If the same way is adopted by the team and used everywhere, it will be easier to write, and to read.

About that, if you want to share some rules, it can be interesting to put it down in a code convention.

Make your code convention

A code convention can be helpful for a team to ensure the code quality and the readability by listing various rules, good practices and code style. Making things explicit will reduce doubt, misunderstanding, and lack of knowledge. Collaboration will be easier.

If your team follows the same convention, it will make your project more consistent. It can help you to write code, and to review others’ code. For a new developer joining your team, this is a quick way to learn your practices.

When doing a code review, you can focus on important changes and structure. You will avoid having to debate again about the use or not use of whatever thing. You already did it, and the team agreed at the end. You will discuss and put effort into new things. But this is not a problem if there is any violation, it can happen, and there will be less with time.

While we are on this subject, some people can felt hurt during code review. They can take it personally. It can be helpful to refer to your code convention when you are discussing about their code. You are not attacking the person. You are underlining a piece of code that does not respect a code convention. Your team convention. And you are helping this person to improve that.

The code convention concerns the whole team. You should write it together to get everyone involved. Discuss, listen, and be open.

This code convention may not be the best, nor yours, but it will be the one for your team.

This convention will be adapted to your context, your project and your team. Build the convention together, and make it live with time. You may not need to be exhaustive immediately, and you may want to change it later, don’t be stuck.