“si le contenu d’une cellule ressemble à une date alors c’est probablement une date”

et le langage machine compris par votre ordinateur est :

“1001010 100111 1100001 1101001 1101101 1100101 100000 1101100 1100101 1110011 100000 1110000 1100001 1110100 1100101 1110011”

Ainsi, comme vous pouvez le deviner, un humain aurait bien du mal à créer un logiciel en utilisant uniquement des 0 et des 1.  Tout comme une machine sera difficilement capable de comprendre une phrase avec un sujet un verbe et un complément. [Les plus malins d’entre vous me feront peut-être remarquer qu’avec les progrès de l’intelligence artificielle, c’est tout à fait possible. Mais je pense que vous avez bien compris qu’ici, on ne parle pas de ça. Donc si – à l’avenir – vous voulez éviter les apartés de 4 lignes entre parenthèses veuillez cesser de m’interrompre s’il vous plait].

C’est donc pour pallier ce problème que le code informatique existe. Dans notre exemple de date et de cellule, cela pourrait ressembler à quelque chose comme ça :

“if (cellule.content().match(/d/d\/\d\d\/\d\d\d\d)) then

   cellule.type = “dateTime”

En effet, cette “phrase” à mi-chemin entre deux mondes peut être comprise par un développeur et interprétée rapidement par une machine.

Mais alors, quel est le problème et pourquoi avoir besoin des bonnes pratiques d’automatisation ?

Et pourquoi passer mon introduction à vous parler du B-A-BA de l’informatique alors que vous hésitez encore à cliquer sur cet autre article qui vous propose 10 photos de chiens rigolos [surtout qu’il parait que la 3e va vous étonner].

Par ailleurs, le problème, c’est qu’il existe de nombreuses façons d’écrire une même instruction en langage informatique et malheureusement toutes ne se valent pas.

En effet, je pourrais écrire :

“j’aime les nouilles au fromage”

ou

“les nouilles au fromage sont un plat que j’aime”

ou encore

“il existe une liste de plats que j’aime et les nouilles au fromage en font partie”.

Et je pourrais coder :

“NouilleAuFromage.aimer = Vrai”

Ou :

“Plat NouilleAuFromage = nouveau NouilleAuFromage()

NouilleAuFromage.cast(NouilleAuFromage).aimer = Vrai”

Ou encore :

“List<Plat> platsQueJaime = nouveau List<Plat>()

Plat NouilleAuFromage = nouveau NouilleAuFromage()

platsQueJaime.add(NouilleAuFromage)”

Ces trois codes font plus ou moins la même chose mais vous conviendrez, que certains ont l’air plus laborieux que d’autres.

Pourquoi un code est mieux qu’un autre ?

Un code peut être évalués selon plusieurs critères :

1. 1. Il est facilement lisible et compréhensible ?

1. 1. Il utilise la mémoire de la machine à bon escient ?

1. 1. Il a des failles de sécurité ?

1. 1. Il est facilement modifiable ?

1. 1. Il permet d’accéder au catalogue Netflix américain ?

1. 1. etc.

Ainsi, on peut imaginer tout un tas de bonnes pratiques d’automatisation qu’un code devrait respecter pour être considéré comme “bon”.

Mais quel est le lien entre le RPA , Robotic Process Automation et les bonnes pratiques d’automatisation ?

L’analyseur de scripts ou Workflow Analyser sur UiPath :

À l’instar de certains outils de développement plus bas niveau (Clion, Eclipse, Dev-C++ … ). A présent, le studio de UiPath permet de vérifier que le code de son robot est “bon” . Mais également, qu’il respecte bien les bonnes pratiques d’automatisation mises en place dans votre équipe.

Si toute cette histoire de bonnes pratiques peut vous sembler futile, sachez qu’il n’en est rien et que cette étape de “vérification” du code est (trop) souvent ignorée par les développeurs. Ce qui créé ensuite des programmes (ou dans notre cas des robots) difficilement maintenables par le reste de l’équipe.

Permettez-moi de prendre un exemple basique.

Il est commun dans une équipe de définir des règles de nommage pour les variables. Il en existe déjà tout un tas, par exemple :

le lower camel case:

“nouilleAuFromage”

le Upper camel case

“NouilleAuFromage”

le kebab case (vous pouvez googler)

“nouille-au-fromage”

le rareBirdCase (vous ne pouvez pas googler)

“v_nouilleAuFromage”

et bien d’autres…

Les avantages de la convention de nommage :

L’avantage de respecter une convention de nommage est que, si l’un de vos collègues lit votre code, il pourra rapidement différencier une variable, d’un argument, d’une classe, etc.

Prenons un autre exemple de bonne pratique courante plus spécifique aux robots cette fois.

Il est généralement bien vu de renommer les activités utilisées par un robot, plutôt que de leur laisser leur nom par défaut.

En effet, supposez que vous développiez un robot et que ce dernier ne soit pas parfait. (Faites un effort d’imagination). Un jour, le robot plante et votre seule piste pour régler le problème est un message d’erreur qui dit :

“Erreur dans l’activité ‘Clic’ “

Il y a fort à parier que vous regretterez amèrement de ne pas avoir modifié les noms de chaque activité pour avoir plutôt quelque chose comme :

“Erreur dans l’activité ‘Clic sur la cloche’ “

Ce qui vous aurez permis de facilement identifier l’emplacement du problème dans votre code.

Les versions actuelles de UiPath studio vous permettent de gérer ce genre de règles. En effet, en utilisant l’analyseur de script, vous pourrez :

• • Activer ou désactiver des règles

• • Forcer ou non un robot à respecter certaines règles pour pouvoir être publié.

• • Modifier le détail de certaines règles

Si je reprends l’exemple des règles de nommage des variables, voici à quoi elles ressemblent dans l’outil :

ST-NMG-01 est le nom de la règle, il peut se comprendre comme suis :

ST : STudio

NMG : règle de NoMaGe

01 : c’est la première règle de nommage du studio

Si l’on souhaite désactiver la règle (et donc permettre aux développeurs de nommer leurs variables avec toute la fantaisie dont ils savent faire preuve) il est possible de simplement le faire en décochant la case concernée.

(J’ose espérer que vous avez compris que ce n’est pas bien de faire ça.)

Définir sa propre convention de nommage

Bien plus intéressant, sous UiPath studio il est possible de définir sa propre convention de nommage en utilisant des expressions régulières.

Le lower camel case se définit comme ceci :

[a-z]([a-z]|[A-Z]|[0-9])*

Le upper camel case comme ceci :

[A-Z]([a-z]|[A-Z]|[0-9])*

le kebab case comme ceci

([a-z]|[0-9])([a-z]|[0-9]|\-)+

Le rareBird case comme ceci :

v_[a-z]([a-z]|[A-Z]|[0-9])+

En modifiant simplement la valeur de l’expression dans l’outil de paramétrage des règles, vous pourrez, définir votre règle de nommage.

En utilisant l’outil, vous pourrez observer les nombreuses règles de base que UiPath met à votre disposition tel que :

• • Pas de chargement de paquets non utilisés

• • Il n’y a pas de doublons dans le nom des activités

• • Pas de boucles infinies

• • Il n’y a pas d’arguments d’activité codés “en dur”

          etc….

Sachez aussi qu’il est possible de coder ses propres règles pour les injecter dans l’outil mais que ceci dépasse largement le sujet de ce billet et que vous êtes déjà bien assez gentils d’être restés jusque-là.