KISS ? quésaco?
KISS : Keep It Simple Stupid
L’idée derrière le principe KISS est que lorsqu’un programme / code est simple à comprendre alors il sera plus simple à maintenir. Cette méthode encourage les développeurs à éviter les fonctionnalités inutiles et les processus compliqués qui pourraient alourdir le projet et le rendre difficile à comprendre et à maintenir. La méthode recommande plutôt de se concentrer sur les besoins réels du projet et de trouver des solutions simples et élégantes pour les satisfaire.
En règle général la réalisation du code de première intention, celui qui répondra au besoin et permettra au développeur de s’imprégner du sujet n’est pas KISS friendly.Ex de code pas KISS :
Pour rendre un code plus simple, il est souvent nécessaire d’itérer plusieurs fois dessus.
Ton code tu douteras
Une fois le code réalisé, il sera important de bien couvrir de test les différentes fonctionnalités et règles métier. Cela permettra d’identifier un code trop compliqué à tester (à refactorer), ou trop compliqué à comprendre (et donc qu’il faudra découper).
La pratique du TDD peut également être appliquée, dans ce cas, dans un premier temps, il est nécessaire d’écrire les tests correspondants aux critères d’acceptations puis de revenir sur son code pour faire fonctionner les tests. Cette approche permet de se concentrer sur l’essentiel métier pour avoir une couverture pertinente de test.
Ton code tu refactoreras
Pour arriver à écrire du code simple, une passe de refactoring est nécessaire pour :
- éliminer le code superflu : càd tout code qui n’a pas prouvé son utilité (exemple : un traitement sur une valeur d’Enumeration qui n’existe pas encore dans le SI)
- découper en fonctionnalités simples, répondant a une problématique précise et ayant un comportement simple à comprendre
- garder des méthodes courtes et simples, chaque méthode ne doit pas dépasser 30/40 lignes et résoudre un problème simple, pas plusieurs
- si une méthode possède trop de conditions, alors il faut créer plusieurs sous méthodes
- dans le cadre du TDD, après un 1er succès d’exécution des tests, il sera nécessaire de réécrire le code pour le rendre plus “agréable”
- les variables et méthodes devront être compréhensibles et décrire clairement ce qu’elles font
Les tests écrits précédemment permettront de s’assurer que le besoin initial est toujours couvert et qu’aucune régression n’arrive lors du refactoring.
L’overengineering tu eviteras
L’overengineering (ou over-kill) consiste à coder plus de fonctionnalités que nécessaire en se disant que « peut être on en aurait besoin plus tard ». En tant que développeur, il est souvent préférable d’anticiper les évolutions futures en rendant notre code adaptable, une dérive est souvent de coder des fonctionnalités non désirées par le métier dans l’hypothèse qu’elles soient demandés à l’avenir, cela rend le code plus complexe, moins maintenable et induit une perte de temps.
D’autres symptômes, tels que trop de généricité, d’abstraction, trop de tests unitaires non pertinents, la création d’un « beau code » compréhensible uniquement par celui qui l’a créé, …, conduisent à l’overengineering.
Boy-scout
La philosophie du boy-scout à savoir « de pusher du code plus propre que celui que vous pullez » consiste à développer en plus de la feature demandé à refactorer/améliorer/nettoyer du code autours. Cela est une bonne pratique si le refacto est modéré, dans le cas contraire, la revue de code sera plus compliqué et nécessitera de la non regression/recette = coût supplémentaire.
Du pair revue tu feras
Faire relire son code par ses pairs, (plus ou moins expérimentés) permet d’avoir un retour critique. Si le code n’est pas compris par des développeurs moins expérimentés alors c’est qu’il n’est pas maintenable.
En ayant des nœuds simples, le code sera plus facile à dérouler !
Guillaume BRESSON
Développeur enthousiaste depuis plus de 10 ans, j’affectionne particulièrement les sujets backend.
Issu d’une formation d’ingénieur, j’ai commencé ma carrière en intégrant des portails intranet / internet puis je me suis spécialisé sur le développement backend autour de Java/Groovy/Spring.
Mes sujets de prédilection vont de la conception d’api REST à la mise en place de tuyauterie back to back. Je considère que le métier de développeur actuel réside principalement dans l’écriture de tests pertinents.
Mon expérience me permet aujourd’hui de partager les bonnes pratiques autour du développement, des tests (Junit / Mockito /MockMvc) et de l’architecture applicative type DDD (Domain Driven Design).