Est-il possible de trop scripter ?

Un bon développeur est une grosse feignasse. Si si, je vous assure ! Il va laisser l’ordinateur travailler à sa place pendant qu’il ira manger sa pizza avec du Coca. D’ailleurs certains ont poussé le vice jusqu’à avoir des programmes qui envoyaient automatiquement des messages à leur compagne. 😀

Débloque les + belles offres tech en 10 mins

Les scripts ont plusieurs avantages :

• Ils sont répétables
• Ils sont traçables

Ces deux points permettent de prédire ce qu’ils vont faire, à condition qu’ils ne soient pas trop complexes. En effet des programmes écrits notamment en shell ont vite faits de devenir très compliqués à déboguer, d’autant qu’il n’y a que peu d’outillage pour le faire.

Les scripts sont des programmes…

Cela semble évident, mais bon il convient de le rappeler : les scripts sont des programmes. Par conséquent comme n’importe quel programme ils se doivent d’être mis dans un gestionnaire de sources, versionnés et testés. Certes ce n’est pas du code de production, mais un script qui servirait souvent notamment dans un processus de build doit être traité avec le même soin qu’un code qui irait en production.

… mais avec leurs spécificités

De nombreux scripts sont écrits dans des langages tels que bash, command.com ou autres. Aussi ces langages ne sont pas les plus sympathiques à déboguer et l’outillage disponible pour eux se résume bien souvent à vim pour les utilisateurs de vrais systèmes ou Notepad++ pour les autres. Aussi ils doivent rester aussi courts que possible.

Par ailleurs ils sont généralement très sensibles aux variables d’environnement, autrement dit des éléments de configuration relativement cachés qui peuvent faire varier du tout au tout leur comportement.

C’est pourquoi un script ne devrait pas dépasser le millier de lignes, et encore dans ce cas utiliser de nombreuses petites fonctions faciles à tracer et réutilisable. Dans la même veine on évitera absolument de faire un script qui en inclut un autre, voire pire : une bibliothèque de scripts prête à l’emploi. En effet avec de tels extrêmes le code devient encore plus difficile à tracer et analyser. Ne riez pas : j’ai déjà vu un programme de 40000 lignes écrit intégralement en ksh, qui dépendait d’une bibliothèque écrite elle-même en ksh avec notamment des algorithmes d’accès à la base de données. L’ensemble était très sensible aux variables d’environnement notamment et avait tendance à fonctionner par coïncidence…

Eviter les traitements complexes

Il m’est également arrivé de me battre avec des scripts faisant des traitements algorithmiques complexes (OK c’était les mêmes que ci-dessus 😀 ). Soyons clairs : les langages de script ne sont pas adaptés pour ça, enfin du moins ceux du type bash. D’une part parce qu’ils sont très pauvres en terme de structures de données, d’autre part parce l’outillage est pauvre rendant compliqué le débogage.

Si vous devez faire des traitements complexes, passez par des langages plus adaptés comme C ou Java voire Perl, à condition d’écrire un programme lisible dans ce dernier langage et pas ceci.

Idéaux pour le texte et le système de fichiers

Cette section concerne avant tout les vrais systèmes bien qu’avec Powershell W—–s semble rattraper son retard. Enfin bref il faut reconnaître que les langages de shell donnent bien plus simplement accès que d’autres langages à toutes les commandes du système telles que sed ou encore curl. Ca fait que pour manipuler des fichiers avec des traitements simples, ou modifier du texte, ce sont de très bons candidats. Par contre n’essayez pas d’interroger une base de données avec. (cf. plus haut)

On veillera néanmoins à ce que la complexité des programmes ne soit pas trop importante, il faut en effet penser à celui qui passe derrière.

En bref…

Pour être honnête, tout ce qui est automatisable à faible coût doit être automatisé. Je dirais même plus si la tâche est complexe à automatiser mais demande beaucoup de travail manuel et doit être refaite fréquemment alors il vaut mieux la scripter.

Par contre pensez à utiliser les technos adaptées et à combiner les langages s’il le faut. Il m’est ainsi arrivé d’écrire des scripts ant qui appelaient des programmes Java. De même pour des substitutions de texte j’aurais tendance à utiliser du Perl.

Toutes les technos ne sont pas adaptées à tous les usages et c’est particulièrement vrai dans le cas des scripts ! Et si vous devez réimplémenter une API dans un autre langage pour faire du script c’est que vous n’avez pas choisi une techno adaptée !

Débloque les + belles offres tech en 10 mins

Cet article vous a plu ? Vous aimerez sûrement aussi :

• #AstuceDeCode 3 : voir l’occupation disque d’un dossier en shell
• Un java-iste espère vous faire aimer son langage fétiche…
• Se sortir de situations difficiles

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.

Son Twitter – Son LinkedIn