3 stratégies pour gérer les erreurs dans les logiciels embarqués

Il est très tentant de supposer qu’un système se comportera aussi parfaitement sur le terrain que sur le banc d’ingénierie. Lors du développement, le logiciel embarqué est écrit dans les meilleures conditions. Le développeur sait comment le système est censé fonctionner et le développement se déroule généralement sans heurts. Cependant, alors que des milliers d’appareils commencent à tomber entre les mains des utilisateurs, les chances que l’inattendu se produise deviennent statistiquement plus probables. Dans l’article d’aujourd’hui, explorons les stratégies dont les développeurs ont besoin pour écrire des logiciels capables de gérer les erreurs inattendues.

Stratégie #1 – Considérez constamment ce qui peut mal tourner

La première stratégie que les développeurs doivent adopter pour gérer les erreurs consiste à se demander activement ce qui peut mal tourner lorsqu’ils écrivent chaque ligne de code. Par exemple, au moment où j’écris l’implémentation d’une fonction comme :

void Dio_WriteChannel (DioChannel_t Channel, état booléen)

Les développeurs devraient considérer ces questions :

• Que se passe-t-il si le paramètre Channel sort de la plage ?
• La fonction doit-elle renvoyer un code d’erreur ou un indicateur de réussite ?
• Comment puis-je valider que l’état du canal souhaité a changé ?
• Que dois-je faire si l’état a essayé de changer mais n’y parvient pas ?
• La mémoire peut-elle être corrompue de telle sorte que ma variable d’état bool soit autre chose que vrai ou faux ? Si oui, comment gérer cette condition ?
• Une assertion est-elle suffisante pour vérifier les conditions aux limites au moment du développement ou devrait-il également y avoir des vérifications en temps réel sur les paramètres ?

Cela fait beaucoup de questions pour un bloc de code aussi simple et commun et nous n’avons même pas commencé à remplir les détails ! Si vous voulez gérer les erreurs avec succès, vous devez constamment remettre en question le code et ce qui pourrait mal tourner.

Stratégie #2 – Documentez vos préoccupations et vos questions en utilisant TODO

Au fur et à mesure que le logiciel est développé, il y a parfois plus de questions auxquelles on peut répondre immédiatement. Dans l’exemple ci-dessus, il n’y a peut-être pas encore de réponse sur la façon dont les erreurs de retour seront gérées. Il serait facile d’ignorer ce problème pour le moment, car d’autres problèmes de codage s’accumulent et oublient le problème dans le processus.

Une façon de capturer les problèmes tels qu’ils apparaissent consiste à saupoudrer les préoccupations ou les questions dans les commentaires du code. La plupart des environnements de développement intégré (IDE) modernes auront des balises personnalisables qui peuvent être extraites du code pour créer une liste telle que l’utilisation de balises TODO. Ceux-ci apparaîtront sous forme de messages d’information.

S’il y a une erreur à gérer mais que je ne sais pas comment le faire, j’utiliserai la balise TODO. S’il existe une implémentation, mais que je souhaite l’examiner, j’utiliserai probablement un TODO ou peut-être un autre mot clé facilement consultable. Les développeurs doivent veiller à ne pas abuser du message d’information TODO, mais cela reste un moyen simple et efficace de suivre les questions ou les problèmes à la volée. Il est vrai que des trackers externes peuvent être utilisés, mais je trouve qu’il est beaucoup plus facile de le garder dans le code afin qu’il puisse être facilement vu par les développeurs dans les réviseurs de code.

Stratégie n°3 – Perdre l’attitude « j’y retournerai plus tard »

Plusieurs fois, on m’a dit; « Nous savons que ce n’est pas la bonne façon de procéder, mais nous y retournerons plus tard et le réparerons ! » J’ai entendu cela d’ingénieurs débutants et expérimentés qui devraient mieux connaître. Il n’y a pas de moment comme aujourd’hui pour réparer quelque chose, le documenter ou mettre en œuvre la vérification des erreurs. Il y aura toujours un incendie ou un problème qui se bat pour attirer l’attention du développeur. Bien que nous ayons l’intention de revenir en arrière et d’ajouter cette gestion des erreurs plus tard, cela arrive rarement !

Dès que quelque chose semble fonctionner pour la direction, il est temps de passer au prochain problème urgent. Si cela fonctionne, pourquoi y investiriez-vous plus de temps pour des rendements décroissants ? La direction ne se rend pas compte que vous n’avez pas inclus la vérification des erreurs ou qu’il y a des trous béants dans la mise en œuvre ! Si le produit a besoin de robustesse, n’essayez pas de l’ajouter plus tard ou pensez que vous pouvez revenir en arrière et le réparer plus tard. Faites ce qui doit être fait pendant que vous écrivez le code et vous dormirez mieux la nuit en sachant qu’il n’y a pas d’erreur cachée attendant de gâcher votre semaine.

Conclusion

La façon dont un développeur aborde l’écriture de son logiciel est ce qui détermine si son système se remettra des erreurs avec élégance ou s’il explosera métaphoriquement au visage de l’utilisateur. La clé est d’avoir la bonne attitude de développement qui considère ce qui peut mal tourner et de mettre en œuvre le mécanisme de récupération pendant l’écriture du logiciel. J’entends souvent des équipes dire qu’elles y retourneront plus tard pour corriger et gérer les erreurs. Cela arrive rarement, ce qui signifie déployer une catastrophe qui n’attend que de se produire. Afin de mieux gérer les erreurs, traitez ce qui peut mal tourner au moment où cela se produit. Si vous ne le faites pas, il ne sera probablement jamais traité.