3 résolutions d’ingénierie

Je constate souvent que les équipes de développement passent la plupart de leur temps à se démener pour respecter les délais et développer les fonctionnalités du produit. En général, j’ai constaté que dans tous les secteurs et entreprises de tailles très différentes, il existe encore plusieurs résolutions du nouvel an qui profiteraient à la plupart des équipes. Vous trouverez ci-dessous ma liste des trois principales résolutions pour les développeurs de logiciels embarqués lors du lancement de 2021.

Résolution n°1 – Tirez parti d’un faisceau de test unitaire

Que cela nous plaise ou non, le test des logiciels embarqués est un élément essentiel de chaque cycle de développement de produits. J’ai constaté qu’en général, les développeurs de logiciels embarqués vérifient leurs logiciels de manière ponctuelle, mais n’ont généralement pas de harnais de test en place pour aider aux tests de régression automatisés. (Évidemment, cela varie d’une organisation à l’autre et peut même dépendre du type de produit en cours de développement).

Au cours des dernières années, les outils de processus de développement logiciel ont fait d’énormes progrès au point où même les plus petites équipes de logiciels embarqués peuvent en bénéficier. Les harnais de test et même l’intégration continue ne font pas exception. Les harnais de test offrent aux développeurs la possibilité d’effectuer des tests de régression automatisés pour s’assurer que le code fonctionne comme prévu et qu’aucun nouvel ajout n’interagit avec le code existant.

J’ai personnellement constaté des avantages majeurs dans mon propre développement de logiciels en utilisant des harnais de test et en suivant un type de processus de développement de développement plus axé sur les tests (TDD). Si vous ou votre équipe n’utilisez pas de harnais de test, tirer parti des harnais de test pourrait être une bonne résolution pour vous cette année.

Résolution n°2 – Passez moins de temps à déboguer

Je sais qu’il y a beaucoup d’ingénieurs en logiciels embarqués qui aiment relever le défi du débogage de logiciels. Pour eux, c’est stimulant et gratifiant, et cela les motive. Pour moi, je trouve que le débogage est le fléau de l’existence d’un développeur de logiciels embarqués ! Compte tenu de la complexité des systèmes embarqués d’aujourd’hui, le débogage est nécessaire, mais le temps passé au débogage doit être minimisé autant que possible. Le débogage est par nature un travail d’échec. Le code est écrit qui devrait fonctionner, mais ce n’est pas le cas, les développeurs ont alors passé un temps considérable à le réécrire et à le réécrire jusqu’à ce qu’il fasse ce qu’il est censé faire (du moins pour autant qu’ils puissent le dire).

Il existe de nombreuses enquêtes et j’ai également vérifié via mes propres abonnés à la newsletter et lors de conférences lors de conférences que le développeur moyen passe environ 40% de son temps à déboguer. Cela équivaut à près de 4,8 mois de travail par an consacrés au débogage ! Diminuer ce nombre de 10 % de 40 % à 30 % permettrait d’économiser 1,2 mois de travail par développeur et par an ! La récupération du temps de débogage peut avoir l’avantage de réduire les coûts du projet, d’aider les équipes à respecter les délais, de réduire le stress ainsi qu’une myriade d’autres avantages.

Si vous trouvez que vous ou votre équipe passez beaucoup de temps à déboguer, c’est l’année pour apprendre à l’éviter et acquérir les bonnes compétences pour minimiser le temps passé à déboguer lorsqu’il doit être fait.

Résolution n°3 – Révisez et améliorez vos processus

C’est peut-être la résolution la plus controversée que l’on puisse faire cette année. Je dis cela parce que je rencontre généralement deux types d’équipes. Le premier a trop peu de processus, ce qui entrave sa capacité à fournir des résultats cohérents et de qualité. Le second a trop de processus, ce qui diminue sa vitesse et sa flexibilité et peut rendre presque impossible tout accomplissement. La clé d’un succès durable est d’avoir toujours une approche équilibrée qui permet la répétabilité tout en maintenant la flexibilité et l’adaptabilité de l’équipe de développement.

Au cours de la nouvelle année, prenez le temps de réfléchir aux processus existants et de savoir s’ils doivent être modifiés ou non. Y a-t-il encore des processus d’il y a 10 ou 15 ans qui sont suivis aveuglément et qui ne s’appliquent peut-être plus? Pourraient-ils être rationalisés pour améliorer la vitesse tout en conservant leur intention d’origine ? Peut-être y a-t-il trop peu de processus. Où serait-il judicieux d’ajouter des processus en place pour s’assurer que les étapes clés du développement ne sont pas négligées ? Quels domaines sont systématiquement insuffisants et causent des maux de tête récurrents, des retards de planification et une perte de productivité ?

Autant que nous pourrions vouloir qualifier les processus de mal, ils sont en fait un mal nécessaire et devraient être périodiquement ajustés pour répondre aux besoins de l’entreprise.

Réfléchissez à ce qui a fonctionné dans le passé

La nouvelle année est un moment fantastique pour réfléchir sur ce qui a fonctionné dans le passé et ce qui n’a pas fonctionné et pour tracer une nouvelle voie. D’année en année, nous avons souvent tendance à accumuler des bagages sur la façon dont nous construisons des systèmes. Parfois, ces bagages donnent lieu à de bonnes pratiques qui sont suivies, tandis que d’autres fois, ce sont des réactions instinctives à se brûler sur un projet. Dans l’article d’aujourd’hui, nous avons examiné plusieurs résolutions courantes que les développeurs peuvent adopter pour améliorer leur environnement de développement logiciel cette année. Je me suis concentré sur les trois domaines clés que je considère souvent comme des problèmes avec les entreprises : les tests, le débogage et la gestion des processus.

Quelles choses spécifiques voudriez-vous changer cette année pour améliorer la façon dont vous développez des logiciels ?