Le comment et le pourquoi du principe “KISS”

KISS : Keep It Simple, Stupid….

 

Ces mots résonnent dans ma tête comme une vérité absolue, empreinte d’une sagesse peu commune : Usez, abusez de la simplicité dans vos applications !

 

Le kiss dans le domaine du web c’est tout simplement aller à l’essentiel, abandonner les surplus de fonctionnalités inutiles qui alourdiront graphiquement et mécaniquement vos applications…

 

Le petit menu ajax ultra animé, les requêtes dans tous les sens pour avoir 10 affichages différentes de vos informations, les pages, profils, modules sociaux, etc… : On s’en fous !! 

 

 

Vous devez garder à l’esprit lorsque vous développez une application que vous allez d’un point A à un point B, restez plus proche du besoin primaire de l’utilisateur que de votre nombril de développeur fou. 

 

Si vous parvenez à respecter ce simple principe du KISS, dans vos applications perso comme pro, vous aurez, à mon sens, compris l’un des fondements de votre métier et serez à même de développer rapidement une application utile et 100% fonctionnelle :

  1. Les utilisateurs ne seront plus paumé devant vos 10 000 options superflues
  2. Le programme gagnera énormément en performances et en rapidité
  3. Le temps que vous gagnerez à ne pas coder l’inutile sera parfaitement employé à renforcer vos modules essentiels
  4. Il sera plus facile de maintenir et reprendre votre code
  5. Votre solution répondra à un besoin précis et y répondra bien

 

Beaucoup de développeurs talentueux  ont ce très gros défaut : ils aiment se faire plaisir, tester de nouvelles techno à intégrer dans leurs scripts, explorer des terrains inconnus : ils aiment la branlette technique

…oui mais….

 

C’est ainsi que l’on se retrouve avec une application bourrée d’Ajax, de petites animations, de fonctions occasionnellement utiles etc.. qui met 10 min à charger, masque les options les plus importantes, gâche le capital visuel, la concentration et le temps de l’utilisateur à tel point qu’elle finit par ne plus être utilisée par personne. 

 

ex : Vous devez développer un gestionnaire de devis en PHP :

 

Pourquoi aller intégrer un chat en ajax a l’application ? (Ne riez pas, c’est du déjà vu)
Le client vous l’a t’il seulement demandé?

Pensez vous que votre choix ridicule se justifie parce que vous avez réussi à convaincre le client que cela lui était indispensable?  

Pensez vous vraiment que le temps que vous passez à développer/adapter/maintenir ce module merdique vaut les 10 minutes d’utilité ludique que vos utilisateurs en feront?

 

 

Vous ne me croyez pas, vous pensez que je délire?

Faites un simple tour sur le web, et matez donc tous les services qui ont percé : google = un champ texte + un bouton, twitter  = un champs texte limite + un bouton, facebook = … bon ok peut être pas plus facebook :)

Essayez juste une fois, ne codez que le minimum syndical, n’affichez que les bouton/contrôles ESSENTIELS, ne faites que les traitements vitaux et uniquement aux moments le plus indiqué, et lancez votre programme en tant que simple utilisateur, je peux vous assurer que votre expérience fonctionnelle sera inoubliable.

Codez au plus proche de l’utilisateur…

Codez simple…

Codez minimaliste

Codez KISS

 

Article rédigé par Idleman

15 réflexions au sujet de « Le comment et le pourquoi du principe “KISS” »

  1. qwerty

    Le Kiss était à la base des logiciels unix. Un programme pour une tache point barre.

    Répondre
    1. Idleman Auteur de l’article

      Et c’était bien comme ça :), le soucis c’est que peu importe l’équipe de dev, et peu importe le projet, avec le temps le frénétique besoin du développeur fou de vouloir a tout prix sortir version sur version le contraint à ajouter des fonctions polluantes, je pense a firefox par exemple, je ne dois pas utiliser un 8 em de ses fonctions et je déplore chaques jours le temps que ces fonctions superficielles me font perdre en chargement.

      Google a bien compris et a su parfaitement utiliser cet esprit minimaliste, et, pour moi, c’est en grande partie pour ça qu’il en est la aujourd’hui.

      Répondre
      1. Poulet

        Et Unix comme Google ont complètement détourné cette philosophie aujourd’hui, ne nous voilons pas la face.

        D’un côté, Google est aujourd’hui extrêmement complexe : derrière cette petite boite de recherche, il y a des algorithmes très évolués pour comprendre ce que veut l’utilisateur, et pour détourner sa recherche. Admettons que je fasse la recherche « cocone exemple », parce que je veux comprendre le concept de “cocône” en mathématiques. Google ne me propos pas moins de 4 corrections différentes, et aucun résultat ne correspond à ma recherche (parce qu’il s’et permis de réinterpréter pour moi). Ok, en remplaçant par “example” ou “cocône” les résultats sont plus ciblés — je ne suis pas en train de critiquer Google.

        Mais il est clair que même Google a du évoluer pour être plus simple à utiliser (quand les utilisateurs ne connaissent pas exactement l’orthographe de ce qu’ils cherchent), et paradoxalement ça l’a rendu plus complexe, parce qu’il est moins prévisible désormais. Bien sûr, je ne parle pas de la recherche instantanée, des résultats « personnels » (liés au partage sur Twitter ou G+)…

        Unix a subi le même sort. Il suffit de constater la taille de certaines listes d’options pour les programmes : la commande ls, chez moi, peut accepter 38 options différentes. Sans déconner. La « philosophie Unix », de nos jours, c’est du flan.

        Dans l’idée, c’est pourtant un concept intéressant : c’est une question « d’orthogonalité » des rôles des programmes, et de composabilité. L’idée derrière cette philosophie était vraiment de proposer des programmes, accessibles via un shell, auxquels on pourrait facilement accéder, et qui manipuleraient tous le même type de données (du texte) pour communiquer et être composés, via des “pipes” |.

        Mais la complexité croissante des applications que l’on voulait réaliser a tué cette philosophie : d’abord, les outils sont devenus de plus en plus complexes (sed, awk, …) jusqu’à devenir de véritables langages de programmation (Perl, Python), plus ou moins inspirés d’Unix, mais de véritables langages quand même. Les langages de shell (bash, zsh) sont eux aussi devenus très compliqués, et vers la fin des années 80, pour prétendre savoir utiliser Unix, il fallait connaître un certain nombre de langages de programmation différents. La « philosophie Unix » était de toute façon morte.

        Et d’un autre côté, tant mieux. La grande majorité des utilisateurs de PC ne sont pas des Unixiens purs et durs, et ne sont certainement pas des programmeurs. Si je reprends l’exemple de ma commande ls, il y a plein d’options qui permettent de changer la façon dont ls affiche ses résultats, ou qui permettent de parcourir un répertoire de façon récursive, etc. Ce sont des choses que l’on devrait normalement faire avec d’autres programmes, combinés à ls (l’affichage, c’est de la composition, et le parcours, ben, c’est un parcours), mais il est ponctuellement plus simple, pour l’utilisateur, d’utiliser l’option qui va bien. Ça rend les choses moins génériques, ça rend les commandes shells plus difficiles à relire (parce qu’on est obligé de retenir le rôle de plein d’options, dont les noms ne sont pas toujours très clairs), mais c’est la vie.

        Le web, c’est pareil. Quoi que tu en dises, aujourd’hui pour comprendre un site web (en tant qu’objet technologique), il faut connaître 4 technologies différentes. Parce que les textes doivent être affichés de façon stylisée, parce qu’il faut faire de la mise en page, parce qu’il faut contrôler ce qui sort des formulaires, etc. Ça ne me plaît pas non plus d’utiliser des usines à gaz comme Gmail (c’est pour ça que j’utilise un client web), mais le web lui-même a définitivement abandonné le principe KISS.

        Un certain nombre de langages de programmation en eux-mêmes sont eux-aussi devenus tellement compliqués… PHP, par exemple, a tendance à encourager l’utilisation de classes. C’est-à-dire que les programmeurs sont maintenant invités à construire leur code comme assemblage de briques élémentaires, dont la taille peut parfois se mesurer en centaines de lignes de code. C’est tout sauf conceptuellement simple, c’est difficile à maintenir et à comprendre/résumer.

        Dans un sens, les langages fonctionnels continuent, eux, d’encourager la philosophie Unix, et des principes de conception simples et orthogonaux. Ce sont eux qui encouragent le plus la composition de fonctions simples et génériques. Et certains des concepts qu’ils utilisent, comme les fonctions d’ordre supérieur, correspondent exactement à la notion de parcours paramétré dont je parlais plus haut, pour la commande ls.

        Répondre
        1. Idleman Auteur de l’article

          Je ne suis pas entièrement d’accord,.

          En ce qui concerne Google je pense qu’ils ont élaboré une méthodologie héritée du kiss pour l’utilisateur et son besoin fonctionnel (comme tu le dis toi même, le petit champs de recherche reste très simple) mais bien plus complexe partie développeur/backoffice.

          En un sens la plupart de leurs logiciels restent KISS puisqu’ils proposent bien une fonctionnalité simple et proche du besoin de l’utilisateur, peut importe que l’algorithme en amont soit ultra complexe pourvu que l’utilisateur n’ai pas à en payer le prix.

          La ou je rejoins ton point de vue, c’est que comme toute géant technologique qui se respecte, google a tendance à vouloir peu a peu créer le besoin pour y répondre au lieu de répondre au besoin existant, c’est le prix de l’innovation.

          Je pense qu’il est encore tous à fait possible de faire du kiss sur le web, la simplicité n’est pas quelque chose de “figé”, ce qui pouvais paraitre monstrueusement compliqué il y a 30 ans pour un internaute est enfantin voir instinctif aujourd’hui, il est donc assez simple de mettre en place un méthode kiss côté utilisateur à partir du moment on l’on sait à quel type d’utilisateur on s’adresse.

          Pour la partie technique des applications,le kiss est à mon sens inapplicable en terme de développement à part peut être dans les AGL pour débutants type Windev qui se contentent de prendre une description algorithmique très simple pour gérer une conversion complexe en aval.

          Merci pour ton commentaire, c’est intéressant d’avoir ce genre de retours :D

          Répondre
          1. freem

            Rapport à l’orienté objet (les classes) qui n’est pas KISS, je ne suis pas d’accord.

            En fait, le mieux, c’est de comparer simplement une classe à une programme.
            _ les deux ont des fonctions qui ne s’appliquent qu’en interne
            _ les deux ont leurs états internes (qui, selon le design pattern GRASP – cf wikipedia – ne doivent pas être connus de l’extérieur)
            _ les deux ont une interface externe

            Avantages d’une classe contre un programme à part entière: polymorphisme, rapidité de chargement (oui, parce que lancer un processus qui affiche hello world 300 fois, c’est plus long qu’instancier 300 objets qui font la même chose), communication plus rapide (les communications inter-processus, c’est pas instantané), simplicité de combinaison. Et j’en oublie sûrement.

            POO != ennemi(KISS) au contraire même.

            Franchement, la moyenne de LoC de mes classes (et je fais du C++, réputé pour demander plus de LoC que d’autres langages) est de 150. Sucre syntaxique compris.

            Après, KISS, c’est bien, mais c’est loin d’être ultime: a force de vouloir faire simple tout le temps, on à des trucs inflexibles et gourmands. Un exemple?
            Voila du code C (qui devrait compiler, mais pas fait de C depuis longtemps ;) ):

            #include
            #include
            int main(int argc, char **argv)
            {
            char hello[50];
            strcpy(hello, argv[1]);
            puts(hello);
            return 0;
            }

            Ce code, c’est très fidèle au KISS: c’est simple, c’est stupide. Surtout stupide, d’ailleurs, et obligé de recompiler pour changer une taille, aussi…
            Accessoirement, on à aucun moyen de savoir si quelque chose à merdé.

            Une version non KISS donnerait plutôt ça (pourrait faire mieux avec des textes explicatifs pour les erreurs, mais la flemme):

            #include
            #include
            #include

            char *test;
            void clean(void)
            {
            free(test);
            }

            int main(int argc, char **argv)
            {
            if(argc!=1)
            return -1;
            char *hello=calloc(1+strlen(argv[1]),sizeof(char));
            if(!hello)
            return -2;
            if(atexit(clean))
            return -3;
            strncpy(hello, argv[1],strlen(argv));
            if(EOF==puts(hello))
            return -4;
            return 0;
            }

            A noter plusieurs détails:
            _ la version KISS est clairement boguée, pas sécurisée, consomme plus de mémoire (du moins quand elle ne merde pas, et excepté le cas où l’on passe un argument de 49 caractères exactement), pas flexible pour sou et n’indique jamais ce qui a merdé (parce qu’elle n’imagine même pas merder!), contrairement à la version évoluée, nettement plus complexe (5 chemins d’exécution contre 1 seul).
            _ la version complexe s’exécute plus lentement.
            _ une variable globale à été utilisée, car pour le coup, il s’agit du seul moyen (en C) d’éviter un trou de mémoire (memory leak). C’est contraire aux stupides recommandations absolues du “savoir coder proprement” que l’on voit partout.
            _ l’exemple est trivial (ok, même inutile, manque d’inspiration j’imagine), mais je peux démontrer la même chose pour des programmes plus complexes.
            _ il s’agit ici de gestion de la mémoire, gérée automatiquement par les “langages modernes” basés sur une machine virtuelle (je me retiens de troller malgré qu’on sois vendredi… mais sachez que j’aime le langage machine.) mais ce n’est pas limité à la gestion de la mémoire.

            Allez, pour le fun, je fais le même en C++ (et donc, avec ces fameuses classes contraires au principes de KISS selon le 1er commentaire de ce thread):

            #include
            #include
            #include

            int main(int argc, char **argv)
            {
            if(argc!=1)
            throw std::runtime_error(“-1”);
            std::string hello(argv[1]);
            std::cout < rootkit!) et rend les programmes rigides.
            Idem pour l’habitude de “ne pas utiliser de variables globales”. Il faut clairement éviter autant que faire se peut, mais pas se l’interdire. Même dans un logiciel orienté objet, il m’arrive très régulièrement d’en utiliser, par exemple pour une ressource qui ne doit être accédée que par une seule instance d’un objet.
            L’orienté objet est l’application de la philosophie UNIX, (qui n’est pas KISS d’ailleurs, mais: “un programme doit faire une seule chose, mais la faire bien”) mais au niveau du programme.
            Il est faux de penser qu’on peut séparer tout en programmes distincts, certains objets sont dépendants de certains autres.
            D’une certaine façon, on peut dire qu’une classe est à l’application ce qu’un programme est à un système: une classe dépend d’autres classes fournies par l’application (une application peut inclure des librairies, je n’ai volontairement pas parlé de programme) et le programme dépends de librairies voire de programmes fournis par le système.

            Idem pour les interfaces:
            Keep It Simple? Ok, on va mettre tout en ligne de commande alors ? :D
            Pas que je serais contre, mais je parie que nombreux seront les râleurs… Après tout, la calculatrice windows, en ligne de commande, ça ne serait pas dur à utiliser… mais moche pour les utilisateurs.

          2. Idleman Auteur de l’article

            Je ne crois pas que quiconque ici ai parlé de l’objet comme allant à l’encontre du principe KISS :), je suis d’ailleurs tout à fait en accord avec ce point de vue, raison pour laquelle l’intégralité de mes applications (excepté une :p) sont en POO.

            Après ce qui importe ici ce n’est pas tant la technologie et les moyens employés,mais d’avantage le résultat final pour l’utilisateur, j’ai même envie de dire qu’il est tout à fait possible d’adopter le KISS pour des discipline autres que l’informatique, ce qui a d’ailleurs déjà été fait et qui porte d’autres noms en fonction du domaine spécifié.

            nb: le fait de tout mettre en ligne de commande simplifierais certainement la vie au développeur (plus besoin de se fader une UI), mais certainement pas a l’utilisateur (donc pas kiss :p)

          3. freem

            Le principe de faire des outils en ligne de commande n’est peut-être pas immédiatement utile à l’utilisateur, mais il le devient par le fait qu’il est ensuite possible de créer facilement un frontend graphique.
            L’avantage de l’utilisateur deviens alors les suivants:
            _ moins de bugs, car ceux-ci sont plus simples à résoudre
            _ plus de choix d’interfaces. Un exemple est par exemple mpd (music player daemon, un lecteur de musique qui n’a aucune interface homme machine). Il existe de nombreux clients, aux fonctionnalités et interfaces différentes: ligne de commande (mpc), ncurses (ncmpcpp par exemple), graphique qui sont intégrées ou pas à un bureau officiel, et même des gadgets qui s’intègrent directement aux barres des tâches &co.

            Très honnêtement, je ne réfléchis généralement pas à faire une interface ligne de commande à mes outils, souvent je fais une bibliothèque qui fait le boulot, et je pond une interface utilisant cette lib ensuite: le premier jet est souvent type “scanf/printf”, voire codé en dur, parce que c’est plus rapide, mais le résultat final deviens souvent plus léché.

            Au passage: la ligne de commande implique de “se fader une UI” puisqu’une UI n’est pas nécessairement graphique ;)

            Quant à ma remarque sur l’orienté objet, je réagissait en fait à ce texte:
            [quote]
            Un certain nombre de langages de programmation en eux-mêmes sont eux-aussi devenus tellement compliqués… PHP, par exemple, a tendance à encourager l’utilisation de classes. C’est-à-dire que les programmeurs sont maintenant invités à construire leur code comme assemblage de briques élémentaires, dont la taille peut parfois se mesurer en centaines de lignes de code. C’est tout sauf conceptuellement simple, c’est difficile à maintenir et à comprendre/résumer.

            Dans un sens, les langages fonctionnels continuent, eux, d’encourager la philosophie Unix, et des principes de conception simples et orthogonaux. Ce sont eux qui encouragent le plus la composition de fonctions simples et génériques. Et certains des concepts qu’ils utilisent, comme les fonctions d’ordre supérieur, correspondent exactement à la notion de parcours paramétré dont je parlais plus haut, pour la commande ls.
            [/quote]
            Qui met en opposition les classes et KISS, et indique clairement que “les langages fonctionnel”, “ce sont eux encouragent […]”. (D’autant qu’une classe de plusieurs centaines de lignes, ça indique souvent un problème de conception, comme je crois l’avoir déjà dis. D’ailleurs, si on prend le principe KISS, il encourage indirectement à faire des centaines de lignes, puisqu’il faut garder les choses simples à coder, et la conception propre qui permet la réutilisation du code n’est pas toujours simple, pas toujours KISS en somme)
            Je ne connaît pas assez les langages fonctionnels pour leur retirer ce mérite, mais je tenais à indiquer que ça ne leur est pas réservé :)

  2. Baronsed

    Pareil :-)
    Mon dernier projet web, je l’ai présenté façon google : le minimum de champs textes et d’options, en groupant autant que possible (tant que ça reste intuitif ; exemple : un seul champ pour matcher ID et nom, puisqu’il y a une caractéristique imparable pour les différencier : il y a systématiquement un chiffre dans un ID, et jamais dans un nom ^^). Et encore, j’ai retiré les boutons quand c’était possible (on valide avec entrée).

    J’ai tenté le passage à Arch Linux (ça c’est du KISS !), il y a un moment, mais j’étais pas foutu de configurer un grub pour conserver le dual boot avec mon ubuntu. Maintenant, je me dis que j’essayerais bien Parabola (Arch sans proprio), histoire de tenter le tout libre, et tant qu’à faire avec un tiling wm : http://wmfs.info/ (über KISS !).

    Répondre
    1. Idleman Auteur de l’article

      En ce qui concerne les ditrib linux ultra light, je suis mitigé, la plupart de ces os poussent le minimalisme un peu trop loin au risque de propager des manques fonctionnels, l’os est peut être le seul contre exemple informatique que l’on puisse trouver au mouvement kiss puisqu’il tire sa force du fait qu’il est justement capable d’exécuter toutes les fonctions informatiques existantes et donc qu’il n’est pas réductible à une plage de fonctions.

      La encore une fois tous dépends du besoin de l’utilisateur, un os minimaliste conviendrait à ma mère qui n’utiliserait que la navigation, la rédaction de texte et deux trois autres fonctions courantes, en revanche mon frangin informaticien de choc péterait un câble avec un tel système :)

      En ce qui concerne ton projet, je ne peux que te féliciter :), j’espère que tes utilisateurs en seront comblés, tu développe quoi par curiosité?

      Répondre
      1. Baronsed

        Un gestionnaire de prêts (adapté pour une médiathèque). Mais ce n’est qu’un cas d’école (quoique je le reprendrai peut-être un jour pour son ergonomie).

        Répondre
  3. François Chaix

    Je suis bien d’accord avec ce que tu dis. Notre informatique serait en bien meilleur santé qi ’lon avait gardé un peu plus de cet esprit UNIX? Et en plus, on aurait moins de Kévin et de Muchu pour nous emm***. Par-ce que c’est ça, aussi : Kévin, il ne veut pas avoir à piper son ls. Il veut que ça s’affiche correctement dès le début, et à la limite il veut bien ajouter un -h à la fin pour que ce siot plus joli.
    Ensuite, c’est vrai qu’il y a des limites. Pour qu’un site web soit vraiment kiss-friendly, il faudrait par exemple aucun CSS pour laisser le client appliquer le sien. Le rôle unique originel de http et de html c’est de présenter des données structurées. Pas jolies. Le CSS est appliqué chez le client, c’est donc son problème.
    Du coup on voit bien la limite : Il faudrait ré-inventer toute notre informatique : Telle qu’on la connaît ajourd’hui, elle n’est pas capable de gérer facilement ce genre de philosophie. Si je présente mon blog sans CSS et que je dit à les visiteurs d’appliquer le leur, ils vont râler, et principalement par-ce que leur navigateur n’a pas prévu ça (pas facilement).

    Bref, assez tergiversé, bon article BTW.

    Répondre
    1. Idleman Auteur de l’article

      Merci, j’aime beaucoup le concept du “apportez votre propre CSS” c’est assez avant gardiste ^^, peut être que ce sera possible dans un futur proche, étant donné que les jeunes sont de plus en plus sensibilisés à l’informatique et que les mamies du cantales sont vouées à disparaitre, mais ça n’est pas pour tout de suite ^^.

      Répondre
  4. Ping : Quelques nouvelles & infos | IdleBlog

  5. P4d4b0U

    Pour commencer, un peu de pommade :
    Je découvre ce blog après des recherches sur la framboise et je ne suis pas deçu, c’est un peu comme wikipedia ton site : on cherche un article et on fait le tour du site !
    Bref ca suffit après tu vas prendre le melon idleman !

    Très bon article, c’est vrai que le techos de base veut souvent se faire plaisir avec des trucs derniers cri qui servent finalement à rien (presta chez un client que je ne nommerais pas par soucis de confidentialité j’ai sais qq chose, rien que l’esb qui sers juste de passe plat en est un bon exemple !)
    Tes arguments sont pas mal du tout il me reserviront pour expliquer à l’avenir que non ca sers à rien de monter une usine à gaz à la moindre occasion parce que le chef

    Répondre
    1. P4d4b0U

      *fin du message*
      a eu une idée lumineuse ce matin en ce levant (le fameux chef qui n’a jamais codé de sa vie mais qui a fait toutes les formations possibles)

      Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Xo ^_^ :siffle: :p :-( :evil: oO :) T_T <3 :D more »