Actualité

Réduire sa dette technique simplement

L'été est toujours un moment propice pour gérer tout ce que nous avons dû laisser un peu de côté pendant l'année ! Parmi les sujets qui reviennent chaque année, la dette technique est l'un de nos préférés.

July 19, 2021 ● 9mn ● #qualite#dette-technique#amelioration-continue
Dette technique : programme spécial vacances !
Retourner sur la liste

L'été est toujours un moment propice pour gérer tout ce que nous avons dû laisser un peu de côté pendant l'année ! Parmi les sujets qui reviennent chaque année, la dette technique est l'un de nos préférés.

Alors cette année, nous nous sommes inspirés des coachs sportifs et vous avons préparé un programme spécial dette technique pour l'été !

Qu'est-ce que la dette technique ?

La dette technique est un concept simple à comprendre.

Lorsque nous développons des projets, nous nous basons sur différentes briques : frameworks, modules open-source, PHP, Mysql et même nos propres librairies maison.

Ces briques sont améliorées en permanence pour être de plus en plus performante et offrir plus de fonctionnalité. En cours de route, il arrive même que certaines soient abandonnées et remplacer par d'autres.

En parallèle de tout cela, notre écosystème évolue : ordinateurs ou smartphones plus puissants, 3G, 4G, 5G, les navigateurs intègrent de plus en plus de fonctionnalités...

La dette technique d'un projet représente le temps (et donc l'argent) qu'il faudrait pour mettre votre projet à jour.

En résumé : plus vous attendez pour mettre votre code à jour et plus le temps nécessaire sera important donc plus vous avez de dette technique.

Comment réduire la dette technique ?

1 / Connaître sa dette technique

Avant de se lancer dans un combat, il faut d'abord connaître son adversaire !

Nous ne vous le dirons jamais assez, un bon développeur affûte ses compétences tous les jours. Vous devez faire de la veille et plus particulièrement sur les outils que vous utilisez au quotidien !

Grâce à cela vous aurez une bonne vision des étapes à franchir et pourrez les planifier plus simplement dans vos sprints.

Souvent, nous passons plus de temps à repousser un sujet qu'à le traiter réellement.

2 / Mettre toutes les chances de son côté dès le départ

Il existe des techniques simples pour minimiser votre dette technique en réduisant le temps nécessaire pour mettre à jour vos projets.

1. Moins de code = moins de travail

Garder les choses simples, si vous avez besoin d'une fonctionnalité l'année prochaine et bien attendez l'année prochaine pour la coder !

Avant d'installer une nouvelle librairie, vérifier son utilité et la quantité de code inutile que vous introduisez sur un projet.

La complexité inutile coûte cher à votre entreprise !

2. Utilisez des outils de validation de code

De nos jours, il existe d'excellentes librairies comme PHP_CodeSniffer ou PHPStan qui se feront un plaisir d'analyser la moindre ligne de votre code.

Ces outils utilisent des règles de validation que vous pourrez même personnaliser et vous remonteront une liste de problèmes qui auront facilement pu vous échapper lors de vos développements.

Par exemple une erreur de syntaxe, des variables non utilisées ou mal instanciée.

Ces outils sont extrêmement simples à mettre en place et leurs retours vous seront toujours utiles !

PHPStan

3. Faire des tests automatisés

Non seulement ils vous permettront de développer plus rapidement au quotidien mais ils vous économiseront un temps colossal lors de vos montées de version.

Imaginez un monde où vous seriez serein à chaque composer update !

PHPUnit

4. Automatiser les validations pour qu'elles soient simplement obligatoires

L'être humain est par nature fainéant !

Si vous ne lui laissez aucune possibilité de ne pas le faire, vous aurez plus de chance que ça soit fait.

Chez SmartBooster, tous ces outils sont automatisées grace à notre intégration continue sous gitlab et si un problème est détecté alors il nous est impossible de déployer !

Gitlal pipeline de déploiement automatisée

5. Laisser un code simple à comprendre pour vous et pour les autres

Vous devez produire un code clair, dont les variables et méthodes sont correctement nommées avec des commentaires utiles !

Et si vous ne le faites pas pour les autres, faites le pour vous-même ! En effet, git est un outil merveilleux qui nous donne la possibilité de savoir qui a codé quoi donc vous pourrez avoir des questions sur un bout de code que vous avez écrit il y a plusieurs mois ou même années.

Code incompréhensible

Pensez à ce moment où vous ne voudrez pas avoir à expliquer que vous faites du code incompréhensible ;-)

Notre conseil : Si vous vous apercevez qu'un bout de code n'est pas clair quand vous devez intervenir dessus, améliorer les commentaires. Vous pouvez faire un commit et une MR simplement pour de l'ajout de documentation, ce n'est jamais du temps de perdu !

3 / Préférer les petits pas à la méthode Kaizen

Il sera toujours plus simple de gérer de petits changements souvent plutôt que d'attendre des années avant de vous mettre à la tâche.

Allouez-vous un temps à chaque fin de cycle pour traiter cette dette !

Ce n'est pas du temps de perdu, même si vos dépendances sont à jour, vous pourrez toujours trouver des logs vous remontant des erreurs à traiter.

Etape par étapes

Notre programme spécial été contre la dette technique

Suivant vote contexte et la taille de votre projet, nous ne vous promettons pas de résoudre toute votre dette en 2 mois mais nous vous proposons de mettre en place de bonnes bases pour réduire votre dette technique.

Bien sûr comme dans tout programme d'amélioration, l'idée est de le tenir sur le long terme.

0 / Faire le ménage

Comme nous l'avons dit plus haut : Moins de code = moins de travail.

C'est le moment de faire du ménage et n'hésitez pas à y aller franchement.

Un coach lifestyle vous dira :

Si tu n'as pas utilisé cet objet depuis un an alors tu n'en as pas vraiment besoin !

Alors vérifiez vos logs et vos données et questionnez votre chef de projet ou product owner avec des éléments factuels.

Voici un exemple tiré de l'un de nos projets :

  • DEV : Est-ce que la personnalisation du logo de l'entreprise au niveau de l'utilisateur est nécessaire ?
  • PO : Oui cela a été demandé par le client XX il y a 2 ans.
  • DEV : Dans la base de données, il n'y a que 6 personnes qui ont utilisé cette fonctionnalité. Dans la moitié des cas, elles ont mis le même logo que celui de l'entreprise. Pouvons nous supprimer cette fonctionnalité pour gagner du temps ?
  • PO : en effet, si cela n'est pas utile tu peux la supprimer.
Notre conseil :

Nous savons que jeter un code que vous avez passé du temps à faire peut sembler frustrant.
Mais vous êtes doué !
Pensez à tout ce que vous pouvez réaliser si vous vous laissez l'opportunité de vous concentrer sur l'essentiel.

en plus c'est un moyen simple d'augmenter le code coverage !

1 / Mettre en place des outils de validation de code

Commencez par les mettre en place avec un niveau de validation correspondant à votre projet.

Il vaut mieux être au niveau 1 sur 10 que de ne pas avoir de validation du tout !

Pour être efficace, ne bruler pas les étapes ! Programmer des campagnes d'amélioration niveau par niveau et ne faites que ça.

Il est important de ne pas mixer les modifications de syntaxe avec l'ajout de nouveau code car en cas d'erreurs vous aurez du mal à retrouver facilement l'origine.

Déployer étape par étape afin de vous assurer que tout est fonctionnel.

Si vous avez des idées de refactoring à cette étape c'est très bien. Noter les mais ne les faîtes pas tout de suite.

Questions fréquentes à cette étape :

  • J'ai un micro dev à faire en même temps, est-ce que je le fais dans ma MR ? -> NON
  • Est-ce que je dois arriver au niveau maximum d'un coup ? -> NON, il faut y aller progressivement
  • L'outil me demande un standard de code mais je n'en ai pas de défini -> Il suffit de prendre celui par défaut, vous en définirez un plus spécifique quand vous maîtriserez le sujet
  • C'est long, c'est dur, je ne suis pas payé pour cela -> Le développement est un métier formidable, ce type de personne n'est pas adapté au poste

2 / Travailler votre code coverage de manière intelligente

100% de code coverage n'est pas un objectif en soit sur un projet car il aboutit à des pertes de temps non nécessaire.

Ce qu'il faut viser, c'est du 95% de couverture sur votre logique métier. Ainsi en plus de corriger des bugs dont vous n'aviez pas conscience cela vous permettra de détecter des problématiques de mise à jour dans vos dépendances.

Nous vous conseillons de prioriser les sujets en faisant une cartographie de votre code et de programmer de la mise en place de tests bloc par bloc.

Notre conseil : miser sur les tests unitaires pour chaque boucle de calcul dans votre modèle puis tester vos requêtes sur votre base de données.

Mauvaise couverture de code

Au début voilà à quoi ressemblera votre rapport HTML

3 / Recommencer les étapes 1 et 2

Avant d'aller plus loin, il est nécessaire d'avoir un code testé au maximum et propre.

Suivant l'état de votre projet, il se peut que vous vous lanciez dans une longue traversée du désert et c'est une très bonne nouvelle !

Car après cela, cette expérience vous aura tellement marqué que vous ne ferez plus jamais l'erreur d'être passif face à votre dette technique.

De plus, vous aurez compris qu'il est plus judicieux de mettre en place des tests automatisés directement pendant les développements plutôt qu'à posteriori. Et cela changera complètement votre niveau en programmation.

4 / Mettez à jour vos dépendances étape par étape

Hormis si vous avez le luxe de pouvoir bloquer votre projet pendant plusieurs semaines, choisissez vos combats !

Mettez à jour étape par étape afin d'avoir le moins de problématique à gérer à chaque fois.

Bien sûr lorsque vous aurez suffisamment d'expérience dans le domaine vous pourrez aller plus vite.

Par exemple, chez SmartBooster si vous nous faites confiance pour migrer un projet Symfony 2 vers la dernière version du framework et bien nous suivrons les premières étapes mais nous partirons directement sur la dernière version de Symfony.

Au passage, nous étudierons ensemble votre projet pour savoir si la montée de version stricte est vraiment la meilleure approche pour votre projet.

Composer update symfony

Conclusion

La dette technique est un sujet important pour vos projets et vous devez la gérer de manière éclairée en vous tenant à jour de l'actualité de vos technologies. C'est ce que l'on appelle faire de la veille technologique !

Dans cet article, nous vous avons présenté une série d'étapes simples à suivre afin d'améliorer vos projets et réduire leur dette technique.

A minima, nous vous conseillons de les mettre dès maintenant sur les nouveaux. A défaut de changer le passé essayons au moins de mieux préparer l'avenir !

Nous espérons que ce programme spécial été vous aura été utile et nous sommes toujours preneurs de vos retours d'expériences pour améliorer nos pratiques.

D'ici là nous vous souhaitons un bel été et n'hésitez pas à nous contacter si vous avez des questions.