Tu parles beaucoup de KISS mais je n'ai pas le sentiment que ce soit une métrique objective.
Le KISS est une philosophie. Ce n'est pas une méthode, ni une
métrique, mais un principe de conception ou d'approche, à usage
général. Quelques humains sympas du passé, proche ou lointain, en
parlent bien.
- La simplicité est la sophistication suprême (Léonard de Vinci).
- La perfection est atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher (Antoine de Saint-Exupéry).
- Tout devrait être fait de manière simple mais non simpliste
(Albert Einstein).
Ayant créé quelques trucs complexes (hardware ou software), de
(rarement) seul à des équipes resserrées (10 collabs. max), j'en
ai déduit certaines choses.
La recherche de la simplicité impose de sélectionner les vrais
besoins, pour se limiter aux fonctionnalités suffisantes.
Il n’y a pas une seule solution pour un problème et plus on simplifie, plus l’éventail des solutions s’affine.
Les « génies » font des trucs d'une complexité géniale, qui marchent plus ou moins mal, mais juste assez pour qu’on mette beaucoup trop de temps à admettre qu’en fait, « c’était de la merde ». Dans le domaine de l’informatique, la pire peste qui soit sont les « génies ». Les « artisans » font laborieusement, et silencieusement, des trucs qui marchent. Il faut réfléchir longtemps, patiemment, en artisan, et discuter beaucoup avec l'équipe, pour arriver réellement à faire KISS.
Quelques classiques KISS : Un logiciel ou un système devrait être construit comme on construit un pont, avec une démarche d'ingénierie. Utiliser le langage adapté au problème à résoudre. Moins t'as de code, moins t'as de bug. Le code est d'abord lisible et ensuite, seulement si c'est nécessaire, optimisé. Pas confondre sûreté et fiabilité (un avion bimoteur est moins fiable mais plus sûr qu'un monomoteur). Le mieux est l'ennemi du bien. De la discussion jaillit la lumière. On documente en même temps qu'on code. Sur un projet, doubler le nombre d'intervenants ne fait généralement que... doubler le délai.
Le KISS est la voie du juste milieu.
Des exemples orientés sysadmin : ne plus avoir d'instance routeur,
remplacée par un utilitaire qui va gérer la configuration des
interfaces, des routes et du firewalling directement sur le Linux
de l'hyperviseur, à partir d'un référentiel dans la supervision
(en l'occurrence une DB SQLite). La check-list est bien,
l'automatisation est mieux, la décision humaine (éclairée par la
signalisation des automatismes) doit primer.
Quelques contre exemples en dev logiciel : l'absence de méthode,
l'architecture en micro-services, le développement
systématiquement objet¹, le MVC et autres patterns à toutes les
sauces, les frameworks bouffis, l'enfer des dépendances, etc.
Une image explicite du juste milieu (the features curve) :
Tu as plein de références sur le net autour du KISS. Une bonne synthèse : https://fr.wikipedia.org/wiki/Principe_KISS
¹ La plupart des développements objets ne devraient pas l'être,
les DB devraient toutes être objet et la plupart des développeurs
ignorent la différence entre les méthodes objet par composition ou
par classification. Pour être équitable, la possibilité à se
"poser au bord du chemin" pour réfléchir à sa "condition de
développeur" est un /putain de luxe/ qui n'est quasiment jamais
offert aux développeurs : ingénierie, méthode de conception,
d'implémentation (langages, DB, OS, etc.), que des domaines où le
temps de faire des choix n'est jamais laissé à ces acteurs
essentiels. On pourrait en dire autant des sysadmins ou devops qui
sont des architectes également essentiels de la réussite d'un
projet.
-- Stéphane Rivière Ile d'Oléron - France