Viser la qualité du code plutôt que la quantité

Il y a peu de temps, j’étais sous pression pour repeindre la maison tout en livrant simultanément plusieurs projets de code de travail hautement prioritaires. Il était impossible de faire les deux de la bonne manière en temps opportun, alors j’ai commencé à chercher une entreprise qui pourrait couvrir le travail de peinture pour moi et j’en ai trouvé une nommée « Qualité sur quantité ». C’était une start-up locale qui était plus intéressée à fournir un service et un travail de qualité à quelques clients plutôt que de maximiser les clients au détriment de la qualité. Alors, qu’est-ce que cela a à voir exactement avec les logiciels embarqués ?

J’ai remarqué que la majorité des entreprises que je rencontre qui développent un produit embarqué semblent être plus intéressées par la quantité que par la qualité. Les équipes piratent furieusement leur code produit en ajoutant autant de fonctionnalités que possible dans des délais incroyablement courts. De nombreuses entreprises prétendront que la qualité est importante pour elles, mais un examen rapide du comportement de leurs produits, sans parler de leurs méthodologies de cycle de vie de développement logiciel, donne une image très différente. Une entreprise axée sur des logiciels embarqués de qualité aura plusieurs ingrédients clés qui peuvent être trouvés dans leurs processus de cycle de vie de développement de logiciels.

Premièrement, ils ont en fait un processus de cycle de vie de développement logiciel qui n’est pas seulement défini mais respecté et régulièrement mis à jour pour répondre à leurs besoins. Ces processus ne doivent pas nécessairement être des processus bureaucratiques à toute épreuve, mais simplement définis et suivis des meilleures pratiques.

Ensuite, les tests doivent être intégrés aux comportements quotidiens des développeurs. Le test n’est pas quelque chose qui se fait uniquement lors de l’intégration juste avant que le produit ne soit mis sur le marché ou ne soit démontré à un client. Les développeurs doivent créer des tests unitaires, des tests de modules et des tests d’intégration pouvant être effectués sur un serveur d’intégration continue. Il y a plusieurs années, c’était certainement quelque chose qui était difficile pour les gens embarqués, mais aujourd’hui, il y a de moins en moins d’excuses pour ne pas avoir ces outils mis en place. (Croyez-moi, j’ai essayé d’en trouver autant que possible, et ils ne tiennent tout simplement pas la route).

Enfin, les revues de code devraient également faire partie intégrante du développement. Il a été démontré d’innombrables fois que la meilleure façon de supprimer les bogues du code est d’effectuer des revues de code régulières. Les revues de code détectent certainement les problèmes de styles de codage, les conditions manquantes, etc., mais j’ai découvert que le vrai pouvoir d’une revue de code est de vérifier les exigences et que le code fait ce qu’il est censé faire. Le simple fait de parler de ce que fait le code et de la façon dont il le fait peut souvent révéler des oublis ou soulever des questions sur ce qui est fait. En fait, même en tant que consultant indépendant, lorsque j’écris du code, je demanderai à un collègue de réviser mon code ou je planifierai des visites guidées avec mon client.

Ce à quoi je veux en venir, c’est que les développeurs de logiciels embarqués, les concepteurs de produits embarqués ou même les dirigeants d’entreprises de systèmes embarqués doivent cesser de se concentrer sur la quantité et commencer à se concentrer sur la qualité. Je pense que c’est souvent un terme impropre qu’un logiciel de qualité est plus cher à développer. J’ai vu à maintes reprises que les équipes qui se concentrent sur l’écriture de moins de lignes de code de qualité par rapport à un grand nombre de lignes de code semblent le faire en moins de temps et à moindre coût. Malheureusement, je n’ai pas fouillé dans la littérature scientifique et les études pour déterminer si c’est un fait, et ce n’est peut-être pas le cas pour tout le monde, mais pour moi personnellement et pour de nombreuses équipes avec lesquelles j’interagis, la déclaration semble vraie.

Alors, est-ce que vous, votre équipe ou votre entreprise vous concentrez sur la fourniture de produits de qualité à vos clients, ou faites-vous simplement autant que possible dans les plus brefs délais ? Si c’est ce dernier, qu’allez-vous commencer à faire pour maîtriser votre développement logiciel ?