Skello Tech Team
Published in

Skello Tech Team

Vers un Skello toujours plus SOLID

Cet article n’a pas vocation à expliquer ce que sont les principes SOLID, il s’agit surtout de présenter comment ceux-ci sont implémentés dans nos projets chez Skello.

Les principes SOLID sont incontournables lorsqu’il s’agit de construire une application qui soit maintenable et évolutive.
Petit rappel illustré sur les principes SOLID, en Anglais

La mise en place des principes SOLID

Pour que l’ensemble des développeurs puissent contribuer à l’évolution du code, en respectant les standards de qualité Skello, nous devons tout d’abord nous former sur ces principes (s’ils ne sont pas déjà acquis). Pour cela, nous avons mis en place un workshop dont le support de présentation reste accessible aux développeurs, afin de faire un rappel sur les tenants et aboutissants du SOLID et sensibiliser chacun sur leur importance.

Ensuite, pour assurer la qualité et l’homogénéité de l’application et accompagner la montée en compétences des développeurs, nous accordons une attention très particulière à la code review chez Skello.

Composer avec la dette technique

Malgré toute l’attention portée à la qualité du code, il est pratiquement obligatoire d’avoir de la dette technique dans une application aussi importante que Skello.

Cela pose le problème d’appliquer les principes SOLID dans des parties de la codebase qui ne les respectent pas forcément à la base.

Deux cas de figure se présentent alors:

  • On décide de privilégier la rapidité d’exécution et on reprend l’architecture en place: cette solution est déconseillée car même si elle est plus rapide à réaliser, elle ne va faire qu’augmenter la dette technique et donc les coûts futurs pour retravailler cette partie de l’application.
  • On choisit de réécrire la partie de code concernée. Cela peut avoir un coût de développement très variable puisqu’il peut s’agir d’un simple workflow comme d’une partie importante de l’application. L’ampleur de la réécriture est donc à apprécier au cas par cas.
    A noter que dans le cas où l’on ne reprend qu’une partie de l’ensemble concerné par la dette technique, il faut faire attention à la façon dont le nouveau code va s’intégrer avec l’ancien, pour éviter un effet de “patchwork”.

Toujours plus de code

La mise en place des principes SOLID ne fait pas qu’augmenter la qualité du code, elle en augmente également la quantité !

En effet, une architecture SOLID est plus complexe que celle d’une application sommaire: on veut isoler les responsabilités, utiliser des interfaces, avoir une hiérarchie cohérente dans nos objets et déporter la gestion des dépendances entre objets de notre code au plus haut niveau de l’application.

Cela va donc nécessiter une certaine réflexion quant à l’architecture de l’application, mais cela implique aussi d’écrire davantage de code: par exemple, si l’on manipule des shifts dans notre application, nous pourrions être tenté de créer une seule classe Shift afin de tout gérer: le modèle en lui-même, l’entité enregistrée en base de données et des outils permettant de passer de l’un à l’autre.

Méthode classe foure-tout

Cependant, si l’on respecte les principes SOLID, cela peut nous conduire à créer de multiples classes pour gérer nos shifts dans différents contextes: par exemple, un découpage en modèle, entité, transformeurs. Comme c’est préconisé dans des standards d’architecture logicielle de type n-tiers.

La classe entité: lien avec la base de données
La classe modèle: utilisée pour la logique métier
Un exemple de transformer

A cela s’ajoutent les tests unitaires, dont l’écriture sera grandement facilité avec une architecture SOLID, qui garantissent le bon fonctionnement du code et évitent les régressions lors de son évolution.

Un exemple très basique de tests unitaires

Qu’est ce qu’on y gagne au final ?

Comme nous venons de le voir, la mise en place des principes SOLID dans notre développement implique un coût de formation et augmente le volume du code.
Malgré cela, les gains liés au SOLID sont multiples, on peut citer entre autre :

  • Le fait d’avoir une architecture normée et un code homogène signifie que le code est globalement cohérent. Il est donc plus facile à comprendre et à prendre en main
  • Un découpage clair des objets implique que les workflows sont plus lisibles et les responsabilités faciles à identifier. Cela améliore sa maintenabilité
  • La séparation des responsabilités et l’injection de dépendances permet également d’éviter la “viscosité” entre les objets du code, qui gêne son évolution et rend le debug plus difficile

Au total, cela permet aux développeurs de Skello d’être beaucoup plus serein lorsqu’il s’agit de reprendre ou de maintenir la plateforme. Tout en s’assurant que l’ajout de nouvelles fonctionnalités pourra se faire de façon fluide pour assurer une évolution saine à notre produit

Thomas, Développeur Full Stack — Skello Tech Team

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store