Introduction

Dans le développement de logiciels, nous entendons souvent parler du « triangle de fer » de la gestion de projet : qualité, temps et budget. Comme si elles résolvaient un casse-tête complexe, les équipes de développement ont du mal à trouver le bon équilibre entre ces trois facteurs critiques. Au milieu de ce défi, il n’est pas rare de trouver des propriétaires de produits qui ignorent béatement la qualité de leur base de code, acceptant naïvement les mauvaises pratiques comme un moyen de couper les coins ronds et de respecter les délais. Ce blogue vise à démêler comment les contraintes de qualité, de temps et de budget sont inévitables et comment compromettre la qualité du code conduit souvent à un cercle vicieux de mauvaises pratiques.

Le triangle de fer : un aperçu

Le Triangle de fer comprend trois facteurs essentiels qui dictent l’issue d’un projet de développement de logiciels :

1. Qualité : Cela concerne la qualité de la construction de la base de code, en intégrant des facteurs tels que la maintenabilité, l’évolutivité et la lisibilité.
2. Temps : Il s’agit du délai dans lequel le projet ou la fonctionnalité doit être livré.
3. Budget : Cela implique les contraintes financières, qui peuvent inclure le coût de développement, de test et de déploiement.

L’interdépendance

L’amélioration d’une facette du Triangle de fer se fait souvent au détriment des deux autres. Par exemple, pour accélérer le développement (Temps), vous devrez peut-être embaucher plus de développeurs (Budget), mais cela peut diluer la qualité du code (Qualité) si elle n’est pas gérée correctement[^1^].

Le coût caché de la mauvaise qualité

Dans un environnement de développement au rythme rapide, il peut sembler tentant de sacrifier la qualité pour une livraison plus rapide. Cependant, une mauvaise qualité du code a des répercussions à long terme :

• Dette technique : Le coût de la maintenance d’une base de code augmente de façon exponentielle à mesure que sa qualité se détériore[^2^].
• Inefficacité : Les équipes passent plus de temps à déboguer et moins de temps à développer de nouvelles fonctionnalités.
• Évolutivité réduite : Le code mal écrit n’est souvent pas évolutif, nécessitant des réécritures complètes lors de l’adaptation aux nouvelles exigences.

Les dangers des propriétaires de produits non informés

Un propriétaire de produit qui ne comprend pas l’importance de la qualité du code est une responsabilité. Lorsque les propriétaires de produits acceptent un code de mauvaise qualité, ils font le choix de :

1. Permettre les mauvaises pratiques : En acceptant la mauvaise qualité, les propriétaires de produits l’approuvent sans le savoir, ce qui en fait une pratique standard.
2. Compromettre les projets futurs : Un mauvais code est comme une bombe à retardement qui peut perturber les futurs efforts de développement.
3. Gonfler les coûts : À mesure que la dette technique s’accumule, le coût de l’entretien augmente, dépassant souvent les coûts de développement initiaux[^3^].

Solutions pratiques : maintenir l’équilibre

Éduquer les intervenants

L’ignorance n’est pas le bonheur.
Éduquer les propriétaires de produits et les parties prenantes sur l’importance de la qualité du code et ses avantages à long terme.
Ils devraient faire partie de l’établissement de normes en matière de qualité du code. Après tout, c’est leur produit et leur budget qui le maintiennent.

Revues de code

Intégrer l’examen de code par les pairs comme pratique courante pour maintenir la qualité.

Le rôle de SonarQube dans le cycle de vie du développement logiciel (SDLC)

SonarQube est un outil d’analyse de code statique qui aide à maintenir la qualité du code.
Lorsqu’il est correctement configuré et réglé, il peut fournir la transparence qui manque souvent aux parties prenantes.

Voici comment faire :

1-Visibilité

SonarQube fournit des mesures telles que des odeurs de code, des bogues et des vulnérabilités, ce qui permet aux propriétaires de produits de comprendre plus facilement la qualité de leur base de code. Il a un joli tableau de bord avec un état assez explicite du code. Ainsi qu’un point de vue pour dire s’il y a amélioration ou dégradation.

2-Prise de décisions

Les métriques de SonarQube peuvent influencer les décisions de projet, guidant les équipes vers l’écriture de code plus propre et la refactorisation si nécessaire.

Responsabilisation

SonarQube crée un sentiment de responsabilité parmi les développeurs, les encourageant à écrire un code plus propre et plus efficace.

3-Automatiser

• Utilisez les pipelines CI/CD pour automatiser les tests et le déploiement, en veillant à ce que seul le code de qualité soit expédié.
• Assurez-vous que vos builds sont déclenchés lorsque des pull requests se produisent et que la révision du code a également lieu à ce moment-là.
• Mettez un outil d’analyse de code statique dans la boucle, pour  qualifier objectivement le code.

Conclusion

Le Triangle de fer de la qualité, du temps et du budget reste un défi, mais c’est celui qui peut être mieux navigué avec les bons outils et la sensibilisation. SonarQube peut agir comme la boussole de navigation, fournissant la visibilité et les informations nécessaires pour maintenir l’équilibre fragile. En intégrant des outils comme SonarQube dans votre SDLC, non seulement vous appliquez de meilleures pratiques, mais vous permettez également une prise de décision éclairée, permettant un projet plus équilibré et plus réussi.

Références

• [^1^]: McConnell, S. (2006). Software Estimation: Demystifying the Black Art. Microsoft Press.
• [^2^]: Fowler, M., & Highsmith, J. (2001). Le design est-il mort?. Programmation extrême explorée.
• [^3^]: Cunningham, W. (1992). Le système de gestion de portefeuille WyCash. OOPSLA’92 Addendum to the Proceedings.

Remerciements : Merci à Manon Warembourg | LinkedIn