Fantomas’side

Weblog open-source

Qualité et complexité

Contexte

Dans le cadre de mon travail actuel, j'ai développé une chaîne de production programmable distribuée sur réseau.

C'est à dire qu'il est possible de décrire des flux de travaux en représentant toutes les étapes successives de la réalisation dudit travail, ainsi que son paramétrage.

Le coté distribué sur le réseau ajoute le fait que l'exécution des tâches va être faite par diverses machines indépendamment du flux de travail appelé.

Maintenant que la chaîne de production programmable est fonctionnelle, il reste pour l'utiliser à l'alimenter avec des descriptions de flux.

Ces flux peuvent être rédigés par différents types de profil, du plus expert au plus débutant, et comme nous pouvons l'imaginer avec des degrés de complexité plus ou moins variable.

Un exemple pour être plus clair, décrire une addition est plus simple que de décrire un flux qui copie un fichier pour le mettre au bon endroit qui
lui même est forcément plus simple que de décrire un flux qui fera un transcodage vidéo, suivi d'une livraison avec notifications personnalisées par emails.

Un flux simple

Le problème est le suivant : avec le temps, le nombre de flux augmentant, les maintenances évolutives et correctives s'accroissent, et les créateurs des flux en fonction de leur compétence et temps ne sont pas toujours capables de faire ce travail de maintenance.

Ajoutons à cela qu'en fonction du style et de la logique utilisés par le créateur du flux, la maintenance peut être vite laborieuse et rebutante.

Comment régler cela à moindre frais ?

Standardisation

La première étape afin de ne pas alimenter la chaîne de production avec n'importe quoi ou des flux cassés est d'introduire une notion d'avertissement bloquant.

Lors de création du flux ou de sa mise à jour, une analyse statique sera effectuée afin de vérifier l'intégrité du flux, sans l’exécuter.

Si une des vérifications échoue, le flux ne peut pas être importé et un message d'erreur informe le créateur de la raison de son erreur.

A partir de cette première étape, la maintenance est fortement réduite car il n'y aura pas d'erreurs flagrantes ou de flux cassés qui seront mis dans la chaîne de production.

Notion de qualité

A partir de cette analyse statique, on peut enrichir les vérifications mais cette fois-ci en non bloquante.

Cela permet par exemple de corriger des erreurs de style, d'afficher des fonctionnalités dépréciées et d'inciter le créateur à faire le flux le plus qualitatif possible et la maintenance associée, car toutes les informations lui sont fournies.

On pourrait comparer cela à des outils comme PEP8, pyflakes.

On peut bien sûr imaginer des programmes de migration automatiques pour tout ce qui déprécié ou non pertinent, mais cela atteint rapidement ses limites.

Un avertissement intéressant est l'incitation à écrire des procédures de tests pour les parties les plus sensibles, afin de faire des phases de maintenance sans régression et donc plus rapide.

Pour information, cette notion de tests est incluse nativement dans la description du flux, ce qui est un avantage non négligeable pour la maintenance.

Notion de complexité

Bon jusque là nous avons des flux valides et rédigés avec des bonnes pratiques, mais cela ne nous informe pas en tant que mainteneur sur le contenu du flux ou ce qu'il fait en pratique.

Par contre si je regarde plusieurs représentations textuelle ou graphique de flux, notre cerveau par un processus "magique" est capable de trier d'instinct les flux du plus simple au plus ardu.

L'idée serait donc d'établir un score de complexité sur chacun des flux, ce score permettant donc de trier, d'aider le mainteneur à prendre des décisions et aussi de comparer l'évolution de la complexité d'un flux.

Un flux plus complexe

On pourrait comparer cette notion de score à des outils comme Yuka, qui aide le consommateur à faire des choix éclairés pour l'achat de produits alimentaires selon une règle de score définie.

A partir de ce score, en cas de problèmes sur le flux, on peut imaginer plusieurs politiques de maintenance.

Par exemple, si le flux X a un score inférieur à 100 points, on assigne la maintenance au support de niveau 1. Si plus de 100 points, on passe au support de niveau 2, etc...

Etablissement du score

Pour établir le score de complexité, la première étape est d'établir naïvement les critères du flux qui ajoutent de la complexité aux flux et d'y associer une valeur et d’additionner le tout.

  • Type de tâches
  • Nombres de paramètres
  • Types des paramètres
  • Utilisation de conditions
  • Utilisation de boucles
  • ...

La liste des critères peut être sans fin du moment qu'on a l'imagination nécessaire, ou les mesures.

A partir de cette première fonction de score, il est nécessaire de comparer un peu au "doigt mouillé" si l'ordonnancement des flux par complexité semble correct, indépendamment de la valeur absolue du score. Dans le cas contraire c'est qu'il manquera des critères à prendre en compte dans le score ou une pondération à appliquer quelque part.

Une fois cette première étape réalisée, il faut idéalement calibrer les scores pour avoir des valeurs non extravagantes et surtout cohérentes entre elles, afin d'éviter d'avoir le score le plus faible à 1, et le plus fort à un million.

Distribution de la complexcité

Notre liste de score étant une distribution normalisée, on peut s'aider de plusieurs indicateurs comme l'écart type pour établir une cohérence des valeurs de score.

Pour cela, Python offre pas mal d'outils de base comme le module statistics. Pour mon cas, l'utilisation complémentaire de Seaborn pour les représentations graphiques fut adéquate.

Correction du score

Désormais nous avons un score de complexité, nous pouvons le personnaliser encore un petit peu pour représenter les bonnes ou les mauvaises pratiques.

Car dans les faits, si à deux flux égaux en terme de complexité l'un comporte des tests et pas l'autre, il faudrait appliquer un bonus sur le score du flux testé car les tests vont aider à la maintenance et enlèvent réellement de la complexité en fournissant des données réelles ou non, avec des résultats reproductibles.

Pour la partie malus, on peut imaginer appliquer des valeurs fortes au score si on détecte quelque chose de potentiellement dangereux.

Par exemple, si je demande à supprimer un fichier durant un flux, je peux majorer fortement le score, car je sais que supprimer un fichier est quelque chose de très délicat et doit être fait avec précautions.

Finalement, nous avons à la fin plus qu'un score de complexité, mais un score implémentant la complexité du flux ainsi qu'une partie son contenu.

Cela permet de mettre en avant les flux qui peuvent être en apparence simples, mais qui sont potentiellement dangereux.

Aller plus loin

L'analyse statique des flux permet bien des choses comme :

  • Anticiper les erreurs de typographie
  • Détecter les erreurs de conception
  • Promouvoir les bonnes pratiques
  • Organiser la maintenance

et au final de faire gagner du temps aux créateurs et aux mainteneurs des flux, mais cela reste sans "âme", car cela ne peut juger que de la forme et non du fond.

Comment savoir que le flux que j'ai demandé fait ce que je veux d'un seul coup d'œil ?

Je veux dire par là, comme pour la complexité si on est capable de transcrire par calcul une mesure faite par instinct, on serait bon non ?

J'ai longtemps pensé que le travail de "création intellectuelle" serait toujours réservé aux humains, surtout dans des domaines comme la programmation ou les arts, mais en y réfléchissant plus longuement je vois que j'avais tort.

Imaginons désormais que je sois capable de transcrire textuellement en langage naturel le contenu de mon flux, rien ne m'empêcherait de le comparer à sa spécification écrite et d'établir un score de correspondance.

La création du flux pourrait donc être laissée à "une machine qui secouerait une boîte" jusqu'à ce que le bon résultat ou approchant soit donné.

Avec les connaissances actuelles dans le NLP, les algorithmes génétiques et l'intelligence artificielle, il est déjà faisable à mon avis que la création de flux dans la chaîne de production puisse se résumer à un simple document texte décrivant la spécification sans formalisme informatique.

Conclusion

En rédigeant ces lignes, l'envie de réaliser le dernier concept me tente fort, mais ne signerais-je pas la fin de mon travail de développeur ?

La réponse est non, mais un peu fataliste, je me dis que forcément quelque part quelqu'un à déjà eu la même idée, et l'a déjà mise en œuvre, que je ne fais que réinventer la roue.
Mais qu'à défaut d'ouvrir la boîte de Pandore, je peux au moins jeter un coup d'œil dedans, pour tenter de comprendre comment elle fonctionne.

Mais cela répond aussi peut être à une question que je me pose depuis longtemps, d'où viennent les idées nouvelles ?
Certainement pas du néant. Mais est ce que toutes ces idées ne seraient que le résultat d'une boite à secouer ?

D'où l'importance de mettre pleins de bonnes choses dans la tête pour nourrir notre imagination et secouer efficacement la boîte.