Discussion :

[Florian Bellmann]

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.

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 ?

Quel est votre avis sur le sujet ?

Voir aussi :

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

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

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

[weberan]

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.

[JPLAROCHE]

Bonjour, on pourrait rajouter , penser à la maintenance, d'où utiliser la méthode de la théorie des ensembles, tout communique, mais reste indépendant, ce qui permet de granuler et de répondre en ne retouchant pas tout (je ne supporte pas les programmes à 30 000 lignes.)
Cela va de pair avec une base de donnée en avale qui soit cohérent et reflète l'entreprise, (rien de mieux qu'un costume sur mesure pour la partie spécifique de l'entreprise).
ps: il va de soi que les grands principes de gestion tels que le stock sera respecté par exemple.
Ne pas avoir N langages pour concevoir l'application (peut-être cela nécessite une investigation dans une étude approfondie et même remettre son métier en question).
Tout cela demande une bonne connaissance de l'entreprise, Ce n'est pas à l'entreprise de s'adapter à l'informatique, mais bien l'informatique qui se doit d'être au service de l'entreprise, il va de soi que l'entreprise doit se donner les moyens pour réaliser ses ambitions.
J'en viens à vendre un service de qualité, je rappellerai une phrase d'un patron que j'avais," je me paye un service informatique ce n'est pas pour avoir Microsoft avec ses bugs récursif donc tolérance ZÉRO. année 2000 vista"
et c'est possible, la maintenance hors démarrage ne devrait être que pour les évolutions. C'est ce que j'ai vécu, d'ailleurs, j'avais fait un article suite à un article très très intéressant "comment bien coder" .https://www.developpez.net/forums/d1928398/general-developpement/langages-programmation/apprendre-23-principes-ecrire-code-lisible/

Mais c'est très bien de redire encore et encore le bien fondé de la cohérence fonctionnel et structurel de la programmation d'un projet.

[weberan]

Bonjour, on pourrait rajouter , penser à la maintenance, d'où utiliser la méthode de la théorie des ensembles, tout communique, mais reste indépendant, ce qui permet de granuler et de répondre en ne retouchant pas tout (je ne supporte pas les programmes à 30 000 lignes.)
Cela va de pair avec une base de donnée en avale qui soit cohérent et reflète l'entreprise, (rien de mieux qu'un costume sur mesure pour la partie spécifique de l'entreprise).
ps: il va de soi que les grands principes de gestion tels que le stock sera respecté par exemple.
Ne pas avoir N langages pour concevoir l'application (peut-être cela nécessite une investigation dans une étude approfondie et même remettre son métier en question).
Tout cela demande une bonne connaissance de l'entreprise, Ce n'est pas à l'entreprise de s'adapter à l'informatique, mais bien l'informatique qui se doit d'être au service de l'entreprise, il va de soi que l'entreprise doit se donner les moyens pour réaliser ses ambitions.
J'en viens à vendre un service de qualité, je rappellerai une phrase d'un patron que j'avais," je me paye un service informatique ce n'est pas pour avoir Microsoft avec ses bugs récursif donc tolérance ZÉRO. année 2000 vista"
et c'est possible, la maintenance hors démarrage ne devrait être que pour les évolutions. C'est ce que j'ai vécu, d'ailleurs, j'avais fait un article suite à un article très très intéressant "comment bien coder" .https://www.developpez.net/forums/d1928398/general-developpement/langages-programmation/apprendre-23-principes-ecrire-code-lisible/

Mais c'est très bien de redire encore et encore le bien fondé de la cohérence fonctionnel et structurel de la programmation d'un projet.

Je pensais aussi à la maintenance mais plus à la maintenance corrective qu'à la maintenance évolutive. Quand une application dysfonctionne, il est très important de pouvoir identifier pourquoi. Si le programme a bien été conçu par rapport à cet aspect, il donne des informations pertinentes pour identifier la ou les raisons du dysfonctionnement. Trop souvent, j'ai dû modifier le code écrit par d'autres (ajout de "traces") puis essayer de remettre le programme dans les conditions du dysfonctionnement pour pouvoir enfin en capter les informations nécessaires pour en comprendre la raison.

En ce qui concerne la maintenance évolutive, je ne suis pas particulièrement adepte de la division intensive entre modules très peu couplés ou entre applications différentes car je préfère la simplicité (et l'efficacité). Il en va de même avec l'organisation de la répartition du travail humain au sein d'une entreprise, si on divise très fortement les tâches générales et si on fait intervenir de nombreux acteurs spécialisés et interchangeables, on obtient une organisation complexe et généralement très peu efficace. Les codeurs affectés à la maintenance comprennent généralement le code dans lequel ils doivent intervenir mais pas toujours l'organisation qu'on a mis en oeuvre initialement pour leur faciliter leur travail car cette organisation est soit mal documentée, soit trop complexe. J'ai plusieurs fois vu du code résultant de l'intervention de programmeurs de maintenance qui court-circuitait l'organisation de la conception initiale.

De plus, souvent on conçoit une architecture permettant de changer des éléments que dans les faits on ne changera jamais.

Mais quelque soit le choix en terme d'architecture de la solution, je suis entièrement d'accord avec vous, Monsieur Laroche, sur l'importance d'une bonne documentation (fonctionnelle et technique).

Encore bonjour à tous,

André

PS:: Je viens de lire rapidement "https://programmation.developpez.com/tutoriels/23-principes-ecrire-code-lisible/" dont parle Monsieur Laroche et je trouve cet article très pertinent. Le sujet "Les pièges cachés de l’abstraction" m'a semble particulièrement intéressant car il est, à mon sens, trop peu abordé dans le métier.

[mach1974]

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

[JPLAROCHE]

Je pensais aussi à la maintenance mais plus à la maintenance corrective qu'à la maintenance évolutive. Quand une application dysfonctionne, il est très important de pouvoir identifier pourquoi. Si le programme a bien été conçu par rapport à cet aspect, il donne des informations pertinentes pour identifier la ou les raisons du dysfonctionnement. Trop souvent, j'ai dû modifier le code écrit par d'autres (ajout de "traces") puis essayer de remettre le programme dans les conditions du dysfonctionnement pour pouvoir enfin en capter les informations nécessaires pour en comprendre la raison.

En ce qui concerne la maintenance évolutive, je ne suis pas particulièrement adepte de la division intensive entre modules très peu couplés ou entre applications différentes car je préfère la simplicité (et l'efficacité). Il en va de même avec l'organisation de la répartition du travail humain au sein d'une entreprise, si on divise très fortement les tâches générales et si on fait intervenir de nombreux acteurs spécialisés et interchangeables, on obtient une organisation complexe et généralement très peu efficace. Les codeurs affectés à la maintenance comprennent généralement le code dans lequel ils doivent intervenir mais pas toujours l'organisation qu'on a mis en oeuvre initialement pour leur faciliter leur travail car cette organisation est soit mal documentée, soit trop complexe. J'ai plusieurs fois vu du code résultant de l'intervention de programmeurs de maintenance qui court-circuitait l'organisation de la conception initiale.

De plus, souvent on conçoit une architecture permettant de changer des éléments que dans les faits on ne changera jamais.

Mais quelque soit le choix en terme d'architecture de la solution, je suis entièrement d'accord avec vous, Monsieur Laroche, sur l'importance d'une bonne documentation (fonctionnelle et technique).

Encore bonjour à tous,

André

PS:: Je viens de lire rapidement "https://programmation.developpez.com/tutoriels/23-principes-ecrire-code-lisible/" dont parle Monsieur Laroche et je trouve cet article très pertinent. Le sujet "Les pièges cachés de l’abstraction" m'a semble particulièrement intéressant car il est, à mon sens, trop peu abordé dans le métier.

Moi non plus, je ne suis pas pour la division comme en java, mais pour des modules qui répondent et résolve un problème de a-z ... La programmation modulaire n'est pas soit une solution si l'on envisage pas la relation et le partage de l'open space de l'environnement… mais là, j'en dis trop peu, c'est un vaste sujet.

ps , ce n'était pas une critique, mais un point important que je voulais signaler.

@bientôt

[escartefigue]

Ce que je constate chez tous les clients chez lesquels j'interviens, c'est que l'essentiel des problèmes de qualité vient des bases de données mal construites.

Les tables obèses sont la source de nombreuses redondances, de pléthores d'index et d'accès concurrents très dégradés, les modèles mal pensés sont la source de requêtes très complexes, difficiles à maintenir et contre-performantes.

Pourquoi ce constat généralisé ?
Parce que les décideurs se foutent royalement de ce qui se passe dans la soute, on trouve des budgets pour ce qui est visible et donc facile à vendre, essentiellement les IHM, accessoirement les états, mais les fondations de la maison, à savoir la BDD, ça ne les intéresse pas, ce n'est pas vendeur. Du coup, les équipes de dev passent leur temps à colmater les fissures causées par ces fondations instables.

Je ne compte plus le nombre de questions posées ici sur developpez concernant des requêtes alambiquées et qui bouffent toute la CPU dont la seule raison d'être est justement un modèle de données mal conçu.

[walfrat]

Pour le coup, je peux dire que j'ai fais partie des peu d'ingénieurs informatique qui ont eu le droit à connaître la démarche de l'assurance qualité à travers des cours sur le sujet et un projet a mi temps pendant un an certifié ISO 9001:2009 (à l'époque :p).
Malheureusement, à part pleurer encore un peu plus fort sur le monde de l'entreprise ça ne m'a pas encore vraiment servi

Ce que je constate chez tous les clients chez lesquels j'interviens, c'est que l'essentiel des problèmes de qualité vient des bases de données mal construites.

Les tables obèses sont la source de nombreuses redondances, de pléthores d'index et d'accès concurrents très dégradés, les modèles mal pensés sont la source de requêtes très complexes, difficiles à maintenir et contre-performantes.

Pourquoi ce constat généralisé ?
Parce que les décideurs se foutent royalement de ce qui se passe dans la soute, on trouve des budgets pour ce qui est visible et donc facile à vendre, essentiellement les IHM, accessoirement les états, mais les fondations de la maison, à savoir la BDD, ça ne les intéresse pas, ce n'est pas vendeur. Du coup, les équipes de dev passent leur temps à colmater les fissures causées par ces fondations instables.

Il y a aussi un certain nombre de dev que ça n'intéresse pas de faire des fondations solides, ou même des fondations tout court (y compris sur la partie IHM!), et non je ne pense pas au méga framework fait maison.

[tatayo]

Bonjour,
Ceci me rappelle vaguement une discussion que j'avais lancée il y a "quelques" temps, concernant la modélisation de la base de données.

J'ai eu finalement gain de cause, et certains réticents commencent à admettre (difficilement, et à demi-mot) que sur ce point j'avais raison, et qu'en cas de besoin, une vue permet de "simplifier" l'accès aux données, que ce soit à la mai pour leur fameuse maintenance ou dans les applications internes.

Mais j'ai tout de même dû insister lourdement pour ça, et ce n'était pas gagné du tout.

Tatayo.