Pour cette semaine, j’avais des idées d’articles sur des composants ou des problématiques informatiques mais finalement je parlerai de la réalité. En théorie, l’informatique, c’est simple. Nous cherchons à fournir la bonne information à la bonne personne au bon moment. Nous sommes nous même capables d’appliquer cela dans notre activité. En théorie seulement.
En pratique, les difficultés rencontrées sont nombreuses. Maîtriser un langage, un framework (cadre de développement), une technologie, une plateforme technique cela prend du temps. Les compétences ne sont pas une simple liste que l’on égrène sur un CV. C’est à l’usage que la connaissance s’acquiert réellement. Sans cela, les connaissances régressent. Alors en maîtriser des dizaines, cela paraît utopique.
De même, comprendre le domaine que l’on doit informatiser aussi ne se fait pas en un claquement de doigt. S’il nous est possible de créer des outils informatiques pour faciliter notre métier, automatiser celui des autres nécessite une ouverture d’esprit. Et ce travail est à recommencer à chaque nouveau client. Certes, des automatismes peuvent apparaître. Mais cela ne fait pas tout.
Les erreurs d’inattention
Alors, il arrive de commettre des erreurs, de bloquer sur des problèmes que nous avons résolu par le passé. Pourtant, nous regardons, les programmes, les ressources, les fichiers de configuration. Et tout nous parait conforme. Et pourtant les tests unitaires et d’intégration nous indiquent que ce n’est pas le cas. Pourquoi ?
Alors, nous recommençons, nous revenons même sur des ressources qui n’ont pas bougé depuis des lustres. Mais l’erreur persiste. Nous modifions les programmes pour que chaque mécanisme écrit se détaille lui-même en espérant qu’une anomalie ressorte. Et surprise, l’incohérence apparaît. Nichés parmi des milliers de lignes de code, un test a été inversé, une affectation a été réalisée à tort, une variable a été mal nommée, …
Cette erreur, stupide je le reconnais, nous a tenu en haleine parfois pendant plusieurs heures. Finalement, la correction est apportée et le retard se rattrape. Le stress retombe et la fin de journée n’en est que plus agréable. Fin de l’histoire …
Les erreurs technologiques
Mais il peut arriver que l’erreur ne soit pas de notre fait. Il est loin le temps où le programmeur écrivait son application de A à Z en s’adressant directement au micro-processeur. Les architectures se sont complexifiées pour faciliter le travail des développeurs. Pourquoi réinventer la roue à chaque nouveau programme alors que la copie d’un modèle existant et performant ne coûte presque rien ?
Les différentes problématiques techniques sont réparties dans différents niveaux, accessibles plus ou moins directement par le développeur. Suivant la situation, on peut aussi parler de cadres ou de couches. Le seul inconvénient est que nous ne connaissons pas toujours les limites des programmes sur lesquels nous nous appuyons. Et l’erreur peut apparaître à ce moment-là.
Deux solutions se présentent alors. La première est de demander au créateur du programme en cause de corriger. S’il s’agit d’un collègue, cela peut aller vite. Sinon, tout dépend de la relation commerciale entretenue. Et dans ce cas, cela peut prendre quelques mois voir plus.
Impossible d’attendre aussi longtemps. Vos utilisateurs veulent leur outil à la fin de la semaine. Donc deuxième solution, le contournement. Il faut adapter votre code pour ne jamais tomber dans cette situation. Aucun développeur n’apprécie cela. Surtout que dans ce cas, le temps perdu ne se compte déjà plus en heure mais en jour. Mais à défaut de mieux.
Les erreurs de conception
Malgré tous les efforts, l’objectif ne semble toujours pas atteint. Pourtant, les entrées sont correctes, le traitement aussi. Mais le résultat ne convient toujours pas. En tout cas, c’est ce que l’analyste nous explique. Alors, nous reprenons tout le programme. Nous plaçons des traces partout. Mais rien n’y fait. Le problème se répète.
Et si l’erreur n’était pas le programme mais le besoin exprimé. Comprendre le métier d’un client n’est pas chose aisée. Dans tous les métiers, il existe des subtilités que seuls les initiés peuvent comprendre. Alors qu’une situation ait été oubliée, cela peut arriver. Un nouvel entretien avec le client doit être envisagé. Pour autant, le travail effectué n’est pas à jeter.
La parole populaire explique que seul celui qui ne fait rien ne se trompe jamais. Certes. Il ne faut pas non plus répéter les erreurs. Mais si on peut s’en passer, ce sera toujours mieux. Il vaut mieux prendre un peu de recul avant de se lancer dans la bataille du code.