4 pièce(s) jointe(s)
On ne vous apprend jamais à créer des logiciels de qualité
On ne vous apprend jamais à créer des logiciels de qualité, un article de Florian Bellmann, responsable de l'ingénierie et développeur senior full-stack chez Motius GmbH.
Avez-vous déjà participé à un projet logiciel pour lequel il manquait des mesures d'assurance qualité essentielles ? Vous n'êtes pas le seul. Cela arrive à un nombre incroyable d'entreprises et de projets. Même s'ils savent qu'il existe ce qu'on appelle l'assurance qualité et que nous devrions le faire, tous les efforts aboutissent généralement au grand sprint d'assurance qualité juste avant la sortie du logiciel. Des moments stressants qui font que le logiciel fonctionne à peine. Tout ce chaos se répète bien sûr lors du cycle de publication suivant. Aucune amélioration.
Ce que l'université vous apprend
Le fait est que si vous étudiez l'informatique, vous n'apprenez pas à garantir des normes de qualité dans les logiciels. La majeure partie du temps est consacrée à l'algorithmique, au fonctionnement d'un ordinateur, à l'histoire de certains langages et concepts, etc. En outre, du moins dans mes études, il y avait un semestre sur les approches de gestion de projet et scrum. Tout cela est très bien, mais l'AQ (assurance qualité) est complètement absente. Il est dommage de négliger l'AQ car plus de 90 % des étudiants travaillent dans un contexte d'entreprise après avoir obtenu leur diplôme. Il sera nécessaire de livrer des logiciels sans bogues dans les temps.
Comment les entreprises livrent-elles à peine à temps ?
Je l'ai vu un nombre incalculable de fois. Les normes et mesures d'assurance qualité sont les premières à être éliminées du projet pour des raisons budgétaires. Elles sont souvent prévues à la fin du projet, mais si le développement prend plus de temps (ce qui est souvent le cas) ou si le champ d'application s'élargit (ce qui arrive toujours), il n'y a plus assez de temps pour l'AQ. Nous nous retrouvons avec un minimum absolu de tests non structurés et nous livrons un château de cartes numérique aux murs fragiles.
Dans certaines entreprises ou équipes, certaines normes d'assurance qualité sont en place. C'est souvent un membre expérimenté de l'équipe qui les applique au reste du groupe. Il est fort probable qu'ils aient appris à leurs dépens que sans l'AQ, tout devient beaucoup plus difficile en cours de route. Malheureusement, il ne suffit pas d'avoir des normes en place. Il arrive souvent que les équipes se contentent d'écrire des tests pour satisfaire aux exigences de la gestion de projet.
Comment sortir de la roue de hamster ?
Il m'a fallu des années pour acquérir l'expérience et la confiance nécessaires pour dénoncer les mesures d'assurance qualité manquantes dans les projets. Se disputer avec les responsables, vivre la période de pointe autour des versions, s'occuper des systèmes de production défaillants et rechercher les contrôles manquants. Ce n'est pas une partie de plaisir. Les situations sont similaires pour d'autres améliorations de la base de code ou du projet qui ne sont pas directement visibles par les responsables, comme les refactorings par exemple. Mais pour l'assurance qualité, cela a toujours été particulièrement difficile parce que si nous n'avons pas mis en œuvre de mesures, nous n'avons jamais appris à le faire correctement.
Citation:
Lorsque le test unitaire est réussi mais que le test d'intégration ne l'est pas.
Ce n'est qu'en parlant et en soulevant la question à plusieurs reprises que l'on peut faire les premiers pas pour sortir de la roue du hamster.
Parler d'argent
À un moment donné, je me suis rendu compte que je n'utilisais pas non plus les bons arguments. Expliquer que le logiciel sera "plus stable" ou "rendra la maintenance beaucoup plus facile" n'est pas palpable pour quelqu'un qui ne travaille pas lui-même dans la base de code. Nous devons parler d'argent. En tant que développeurs, nous devons parler du coût de l'absence d'assurance qualité. C'est le langage des entreprises et des managers en général. Aujourd'hui, j'essaie toujours d'encadrer les mesures d'AQ avec des exemples tels que : "Si nous ne le faisons pas maintenant, les efforts de développement (et donc les coûts) augmenteront de 15 % dans 4 mois" ou "Nous devons mettre en œuvre des tests unitaires pour toutes les fonctionnalités ou nos phases de stabilisation de la version prendront de plus en plus de temps à chaque fois. Directement lié à toutes les fonctionnalités que nous construisons, parce que nous devons tester manuellement tous les effets secondaires à chaque fois. Cela nous fera faire moins de progrès à chaque version".
D'après mon expérience, ce changement permet de mieux faire comprendre le problème. En fin de compte, vos efforts dans ce domaine amélioreront la vie de tout le monde. Mais tout le monde ne le sait pas encore.
Dose minimale efficace
Pour être réaliste, il est important de ne pas surinventer les mesures d'assurance qualité avec un investissement initial important. Nous ne devons pas bloquer l'avancement du projet dans son ensemble et nous n'obtiendrons pas non plus l'adhésion nécessaire de toutes les parties prenantes avec cette approche. Je suggère de toujours rechercher les parties les plus vitales de l'application. Normalement, il y a un cas d'utilisation, une fonctionnalité ou quelque chose autour de laquelle toute l'application est construite. Il s'agit d'une fonctionnalité essentielle qui doit fonctionner correctement pour que le logiciel soit utile au client. Tester cela. Trouver des mesures et des moyens pour s'assurer que cela fonctionne toujours comme prévu.
J'aime bien l'expression "dose minimale efficace" (DME). Il s'agit de la plus petite dose qui produira le résultat souhaité. En AQ, il peut s'agir d'un plan de test manuel, de tests automatisés en cours de réalisation ou de quelque chose de différent. C'est le bon point de départ. Si les fonctionnalités de base sont assurées, vous pouvez progressivement accroître la stabilité. Par exemple, pour toutes les nouvelles fonctionnalités, vous ajoutez un test unitaire. En outre, pensez aux sources d'information que vous ne pouvez pas contrôler. Comme les API externes ou les entrées des utilisateurs. Trouvez des moyens de les valider également, car il s'agit d'endroits plus évidents où votre logiciel peut tomber en panne à cause d'une mauvaise utilisation. Itérer et incrémenter. Également sur l'assurance qualité.
Ce à quoi je fais attention
Pour chaque nouveau projet que je démarre ou que je rejoins, je recherche un concept d'assurance qualité. Aussi petit soit-il, l'équipe doit y avoir réfléchi.
- Qu'allons-nous livrer ?
- Que devons-nous vérifier pour nous assurer qu'il fonctionne ?
- Comment procédons-nous ?
- Quelles sont les mesures auxquelles nous renonçons délibérément et pourquoi ?
Le fait de disposer d'un document écrit à ce sujet et éventuellement d'un plan de test constitue une base solide sur laquelle le logiciel peut progresser. Cela montre que l'équipe a réfléchi à la manière de procéder. Encore une fois, il s'agit de penser en termes de DME. En outre, je suggère de revoir régulièrement les approches choisies. Par exemple, une fois par trimestre.
Lorsque j'écris du nouveau code, je n'utilise pas le TDD, mais je recommande fortement d'écrire des tests au fur et à mesure que vous écrivez le logiciel. C'est le bon moment pour écrire les tests. Si vous écrivez les tests au fur et à mesure que vous implémentez la fonctionnalité, vous avez l'avantage que votre code doit être structuré d'une manière qui est réellement testable. L'écriture de tests pour un logiciel existant révèle souvent qu'un code donné est beaucoup trop interdépendant ou que les principes de responsabilité unique ont été violés. Grâce aux tests, vous montrez que vous avez compris le comportement souhaité et que vous vous êtes assuré que tout fonctionne comme prévu. Il s'agit même d'une forme de documentation du code.
Lorsque vous vous exprimez, les personnes qui vous entourent se rendent compte que le projet vous tient à cœur. Le fait de soulever la question de la qualité et de suggérer des solutions possibles élargit même votre champ d'action en tant que développeur. Cela peut être bénéfique pour vous personnellement et pour le projet. La qualité de vie des développeurs et des gestionnaires augmentera. Cela se remarquera certainement.
Ce n'est qu'avec des mesures d'AQ qu'un projet peut se développer à un rythme sain.
Changer les projets pour le meilleur
Utilisez-vous déjà des mesures d'AQ dans votre projet ou tout est-il très fragile ? Voulez-vous élargir vos compétences de développeur et devenir quelqu'un de connu pour écrire des logiciels de qualité ?
Commencez modestement. Pensez aux DME dans votre projet. Assumez la responsabilité et soyez la voix de votre équipe pour améliorer les choses. Tout le monde n'a pas besoin d'être un ambassadeur de l'assurance qualité, mais vous pouvez enseigner aux personnes qui vous entourent les approches nécessaires en montrant l'exemple. Suscitez la discussion.
Faites-le, c'est tout.
À la vôtre,
Flo
Source : "You are never taught how to build quality software", un article de Florian Bellmann
Et vous ?
:fleche: Quel est votre avis sur le sujet ?
Voir aussi :
:fleche: Est-il possible de mesurer la productivité des développeurs ? Oui, selon McKinsey, qui suggère une approche adaptée au contexte et aux objectifs
:fleche: 10 vérités difficiles à avaler que l'on ne vous dira pas sur le métier d'ingénieur logiciel, par Mensur Durakovic, ingénieur logiciel
:fleche: Gagnez du temps sur les révisions de code et la planification de projet avec l'analyse statique, par Kateryna Shlyakhovetska, Group Product Manager chez Jetbrains
Point de vue complémentaire
J'aimerais, en complément de ce point de vue bien intéressant, présenter l'intérêt de mieux coder spontanément sans attendre que des tests viennent mettre en évidence les lacunes.
Selon moi, un bon code doit, au-delà des scénarios "nominaux", traiter au maximum les cas d'exception. On peut aisément arriver à ce que la partie du code ainsi dédié aux cas particuliers soit majoritaire. Le "bon programmeur" devrait y être attentif dès qu'il commence sa programmation. L'équipe de projet devrait définir des règles générales relatives au traitement des cas particuliers : jusqu'où continuer les traitements quand tout va mal (autrement dit, dans quelles conditions faut-il arrêter les traitements et comment), quelles traces laisser des anomalies (les "logs"), que faire remonter au code d'appel, quand signaler les problèmes aux utilisateurs et comment, ... ?
Il convient en outre de commencer à traiter ces cas particulier au niveau le plus bas. La complexité vient souvent du nombre de combinaisons possible. C'est pourquoi il faut traiter les problèmes d'abord au niveau le plus bas, là où le nombre de combinaisons est relativement réduit. Pour être un peu plus concret, voici quelques cas que je considère comme devant être traités : anomalie des valeurs des arguments transmis à une fonction ou une méthode (contrôle à faire au minimum à la réception, c'est à dire dans les premières lignes de code de la fonction ou la méthode), anomalie dans l'état d'un objet, valeur inattendue reçue en réponse à un appel de fonction ou de méthode, saturation ou indisponibilité des ressources nécessaires, attente anormalement longue du résultat d'un traitement ou d'une action.
Je pense que tous les intervenants dans la réalisation d'un programme ne sont pas suffisamment sensibilisés à ces aspects. Les "décideurs" n'ont pas conscience de l'existence de cette problématique et ne sont pas prêts à y consacrer suffisamment de ressources, les analystes ne se préoccupent pas (ou se préoccupent peu) de l'étude des cas particuliers. Les développeurs néglige de traiter les cas d'anomalie auxquels leur code peut être soumis.
Les tests de qualité sont nécessaires mais ne vont jamais couvrir tous les cas particuliers. Il me semble nécessaire de développer une discipline personnelle dans notre façon de coder, d'aller au delà de ce qu'on nous demande pour spontanément réaliser du code de qualité.
Bonjour à tous, et bonne année,
André
PS: J'espère que vous excuserez les imprécisions dans mon propos écrit un peu trop rapidement et que vous voudrez bien y voir et en retenir l'esprit.
on a évolué depuis que le Monsieur a fait ses études
il y a les coding DOJO, l'approche du Test driven development, où on raffine le code pour justement l'améliorer. Des tests de nature différentes sont enseignés à l'école comme la différence entre les tests unitaires, deux à deux , les tests bouchonnées , l'automatisation des tests de non régressions, l'utilisation de COQ ou de langage formelle pour souscrire aux standards médicaux, de l'aéronautiques etc....
Comment faire des applications temps réels....
On se demande où ces gens ont travaillés :mouarf:
