Principe KISS
KISS, keep it simple, stupid (en français, garde ça simple, idiot !) est une ligne directrice de conception qui préconise la simplicité et que toute complexité non indispensable devrait être évitée. Ce principe est appliqué dans un grand nombre de disciplines.
Il est très compliqué de faire simple en vérité . Dans chaque nouvelle idée de design logiciel, il ne faut pas chercher à réinventer la roue mais s'appuyer sur des programmes/utilitaires qui fonctionnent et qui sont maîtrisés.
La philosophie UNIX veut qu'une fonction logicielle doit être assurée par un programme qui ne gère que celle-ci. Autrement dit ne faire qu'une chose et bien. Cela participe aussi à la rapidité de la courbe d'apprentissage !
Selon Eric S. Raymond , la philosophie d'Unix se résume à ce principe.
Sous un système d'exploitation de ce type, l'interface système propose beaucoup de petits utilitaires faisant des choses simples (ls, grep, find, cut, wc…) et un moyen de les combiner, le pipe (|).
Il y a deux façons de concevoir un logiciel. L'une consiste à la rendre si simple qu'elle ne présente manifestement aucune lacune, aucun bug ; l'autre, consiste à la rendre si compliquée qu'elle ne présente aucune lacune manifeste (ou détectée). La première méthode est beaucoup plus difficile.
La tradition qui consiste à faire attention à la modularité et à accorder une attention particulière à des questions telles que l'orthogonalité et la compacité est encore bien plus ancrée chez les programmeurs Unix.
(Tiré de "The Art of Unix Programming" de Eric S. Raymond )
Exemple
Dans mon système de gestion de connaissances Nemo, j'ai dû trouver un mécanisme pour savoir s'il fallait reconstruire le code HTML5 d'une page ou non... Avec l'idée de faire vite.
Au début, j'avais pensé créer un référentiel des pages (fichier texte avec les noms des pages, des hashages de contrôle MD5 etc...).
En définitive, après avoir cherché le minimum de traitement, j'ai fini par inscrire un fichier texte vide de nom DONE dans le dossier de la connaissance, lors de la création du code HTML5 de la page afin que l'automate ne la reconstruise pas après !
Si la connaissance change, il suffit juste d'effacer ce fichier DONE. On ne peut pas faire plus simple...
Vitesse d'exécution
Le shell n'est pas toujours adapté en terme de rapidité, tout dépend du nombre de traitements à effectuer sur les données. Il est parfois judicieux de coder une fonction chronophage dans un autre langage compilé ou non (Perl, Python).
Dans Nemo, le référentiel des connaissances KB, est un fichier texte avec une ligne par connaissance/record, incluant les rédactionnels, les noms des fichiers associés etc...
Pour 900 connaissances à ce jour, le script shell prenait 30 secondes de traitement et donc la qualité perçue était faible. Après réécriture de la fonction en langage Perl, le temps de traitement tombe à 1 seconde, autrement dit une amélioration d'un facteur 30, et là, l'expérience utilisateur UX est bien meilleure !
Expérience
C'est une suite d'essais/erreurs et rien d'autre. Il faut pratiquer et encore pratiquer son art.
Il faut savoir démarrer petit, sur une idée, pour la coder facilement après analyse puis tester, re-tester, simplifier toujours jusqu'à qu'il n'y ai plus que le minimum... C'est un art comme toute création de l'esprit.
J'ai toujours privilégié l'approche bottom-up. On part des fonctions de bas niveau pour construire des briques logicielles qui finiront par former un édifice solide (l'application). Ces briques de fonctions seront réutilisables dans d'autres design...
Par contre, imaginer un système commence par une approche top-bottom, d'abord les grandes lignes puis, petit à petit, les détails d'implémentation (en développant les "briques" pour voir si l'idée est jouable, où s'il y a moyen, dès le départ, de simplifier). C'est toujours un processus d'allers et retours intellectuels.