Selon la définition de la qualité logicielle qu’en donne Wikipédia

Une appréciation globale de la qualité tient autant compte des facteurs extérieurs, directement observables par l’utilisateur, que des facteurs intérieurs, observables par les ingénieurs lors des revues de code ou des travaux de maintenance.

J’ai fait le choix dans cet article de ne parler brièvement que des seconds. La qualité d’un logiciel et plus précisément QGIS ne se limite donc pas à ce qui est décrit ici. Il y aurait encore beaucoup à dire sur:

• La prise en compte des retours utilisateurs,
• le processus de rédaction de la documentation,
• la gestion de la traduction,
• l’interopérabilité via l’implémentation des standards,
• l’extensibilité permise par une API toujours plus riche,
• la réversibilité et la résilience du modèle open source…

Ce sont des sujets qui nous tiennent à coeur, mais qui mériteraient chacun leur propre article.

Je me concentrerai ici sur la problématique suivante : QGIS est un logiciel libre et permet à quiconque doté des compétences nécessaires de modifier le logiciel. Mais comment s’assurer alors que les multiples propositions de modifications du logiciel contribuent bien à son amélioration et ne portent pas préjudice à sa maintenance future?

L’auto-discipline

Les développeurs contribuant au code de QGIS n’appartiennent pas tous à la même organisation. Ils ne vivent pas tous dans le même pays, n’ont pas forcément la même culture et ne partagent pas forcément les mêmes intérêts ou ambitions pour le logiciel. Ils partagent cependant la conscience de modifier un bien commun et l’envie d’en prendre soin.

Cette conscience transcende la conscience professionnelle, le développeur n’a pas seulement une responsabilité vis à vis de son employeur, mais aussi envers l’ensemble de la communauté d’utilisateurs et de contributeurs du logiciel.

Cette auto-discipline est le fondement de la qualité des contributions d’un logiciel comme QGIS.

Cependant, l’erreur est humaine et il est indispensable de procéder à des vérifications lors de chaque proposition de modification.

Les vérifications automatiques

À chaque proposition de modification (appelées Pull Request ou Merge Request ), la plateforme GitHub de QGIS lance automatiquement un ensemble de vérifications automatiques.

Exemple de proposition de modification

Résultat des vérifications automatiques sur une proposition de modification

La première de ces vérifications est de construire QGIS sur les différents systèmes sur lesquels il est distribué (Linux, Windows, MacOS) en intégrant la modification proposée. Il est inconcevable d’intégrer une modification qui empêcherait de construire l’application sur l’un de ces systèmes.

Les tests

La première problématique posée par une proposition de modification est la suivante « Comment être sur que ce qui va être introduit ne casse pas ce qui existe déjà ? ».

Pour valider cette assertion, on s’appuie sur des tests automatiques. Il s’agit d’un ensemble de micro-programmes que l’on nomme tests, dont le seul but est de valider qu’une partie de l’application se comporte comme attendue. Par exemple, il existe un test qui valide que lorsque l’utilisateur ajoute une entrée dans une couche de donnée, alors cette entrée est ensuite bien présente dans la couche de donnée. Si une modification venait à casser ce comportement, alors le test échouerait et la proposition serait refusée (ou plus vraisemblablement corrigée).

Cela permet notamment d’éviter les régressions (on les appelle très souvent tests de non régression) et aussi de qualifier le comportement attendu.

Il y a approximativement 1,3 Millions de lignes de code pour l’application QGIS et 420K de lignes de codes de tests, soit un rapport de 1 à 3. La présence de tests est obligatoire pour l’ajout de fonctionnalité, par conséquent la quantité de code tests augmente avec la quantité de code applicatif.

 

En bleu le nombre de lignes de code dans QGIS, en rouge le nombre de lignes de tests

On compte à l’heure actuelle dans QGIS plus de 900 groupes de tests automatiques qui s’exécutent pour la plupart en moins de 2 secondes, pour un temps d’exécution total d’environ 30 minutes.

On constate par ailleurs que certaines parties du code de QGIS – les plus récentes – sont mieux couvertes par les tests que d’autres plus anciennes. Les développeurs s’efforcent au fur et à mesure d’améliorer cette situation pour résorber la dette technique.

Les vérifications de forme

De manière analogue à l’utilisation d’un correcteur orthographique lors de la rédaction d’un document, on procède à un ensemble de vérifications de forme sur le code source. On vérifie par exemple que la proposition de modification ne contient pas de mots mal orthographiés ni de mots « bannis », que la documentation de l’API a bien été rédigée ou encore que le code modifié respecte certaines règles de forme du langage de programmation.

Nous avons eu l’occasion récémment d’ajouter une vérification basé sur l’outil clang-tidy. Ce dernier s’appui sur le compilateur Clang. Il est capable de détecter des erreurs de programmation en procédent à une analyse statique du code.

Clang-tidy est par exemple capable de détecter les « narrowing conversions ».

Exemple de détection de « narrowing conversions »

Dans l’exemple ci-dessus, Clang-tidy détecte qu’il y a eu « narrowing conversion » et que la valeur du port utilisé dans la configuration du proxy réseau « peut » être altérée. En l’occurence, ce problème a bien été reporté sur la plateforme d’anomalies de QGIS et a dû être corrigé.

A l’époque, clang-tidy n’était pas en place. Son utilisation aurait permis d’éviter cette anomalie et toutes les étapes qui ont menées à sa correction (description exhaustive de l’anomalie, multiples échanges pour permettre sa reproduction, investigation, correction, revue de la modification), soit une quantité conséquente de temps humain qui aurait ainsi pu être évité.

La revue par les pairs

Une proposition de modification qui validerait l’ensemble des vérifications automatiques décrites ci-dessus ne serait pas forcément intégrée dans le code de QGIS de façon automatique. De fait, son code est peut-etre mal conçu ou la modification mal pensée. La pertinence de la fonctionnalité est peut être douteuse, ou fait doublon avec une autre. L’intégration de la modification entrainerait donc potentiellement un fardeau pour les personnes responsables de la maintenance corrective ou évolutive du logicielle.

Il est donc indispensable d’inclure une revue humaine dans le processus d’acceptation d’une modification.

Il s’agit plus d’une relecture de fond de la proposition que de forme. Pour ces dernières, on priviligie les vérifications automatiques décrites précédemment en vue d’alléger le processus de revue.

Par conséquent, la relecture humaine prends du temps, et cet effort est grandissant avec la quantité de modifications proposées dans le code de QGIS. La question de son financement se pose, et des discussions sont en cours. L’association QGIS.org dédie notamment une partie conséquente de son budget pour financer les revues de code.

Plus de 100 propositions de modification ont été revues et intégrées sur le mois de décembre 2023. Plus de 30 personnes différentes ont contribué. Plus de 2000 fichiers ont été modifiés.

Par conséquent l’attente d’une relecture peut parfois être longue. C’est aussi souvent le moment où s’exprime les désaccords. C’est donc une phase qui peut s’avérer frustrante pour les contributeurs, mais c’est un moment important et riche de la vie communautaire d’un projet libre.

A suivre !

En tant que développeur cœur QGIS, et en tant que société pure player OpenSource, nous pensons qu’il est fondamental de nous impliquer dans chacune des étapes du processus de contribution.

Nous nous investissons dans le processus de relecture, l’amélioration des vérifications automatiques, et dans le processus qualité de QGIS de façon générale. Et nous continuerons à nous investir dans ces problématiques afin de contribuer à faire de QGIS un logiciel pérenne et stable.

Si vous souhaitez contribuer ou simplement en savoir plus sur QGIS, n’hésitez pas à nous contacter à infos+qgis@oslandia.com et consulter notre proposition de support à QGIS.