La Scout Rule : une bonne pratique de développement

Si vous êtes développeur et que vous ne voyez pas le rapport entre une bande de joyeux compagnons faisant des feux de camp 🔥 et votre métier, c’est que vous êtes au bon endroit ! La Scout Rule (anciennement Boy Scout Rule) établie par Robert C.Martin (“Clean Code”) concerne un principe de développement fondamental qui permet une amélioration continue du code d’une application 📈. Une fois ce concept compris et maitrisé, voyez-le comme un atout de plus dans votre métier, qui vous permettra d’avoir une ligne directrice lorsque vous serez en cours de développement d’une nouvelle fonctionnalité.

L’action des Scouts dont nous devons nous inspirer

Une règle des Scouts consiste à faire en sorte que l’endroit où ils établissent un camp pendant la nuit doit être plus propre à leur départ qu’à leur arrivée. La première chose à faire avant de camper, c’est déjà de ne pas détériorer l’endroit qui servira à passer la nuit. Une fois le campement installé et tout le travail réalisé, les Scouts vont se coucher. Quand ils se réveillent le lendemain, avant de se remettre en route, ils enlèvent leur matériel et nettoient le camp. Cette action, réalisée dans un certain respect de l’environnement qui les a accueilli, permet même de s’assurer que l’endroit sera plus propre la prochaine fois qu’ils établiront un campement dessus.

Quel rapport avec le développement de mon US ?

Tout peut se résumer en une phrase, très proche du concept que nous venons d’évoquer :

Laissez le code dans un meilleur état que celui dans lequel vous l’avez trouvé.

Le but, lors du développement d’une fonctionnalité, ne doit pas être seulement d’arriver à passer la tâche en DONE ✅ le plus rapidement possible. Lors de la phase de développement, notre attention va se porter sur certaines portions du code, dans lesquelles nous allons certainement repérer quelques incohérences, bugs potentiels ou anomalies. Lorsque ces derniers sont simples et rapides à corriger, la Scout Rule stipule que c’est justement l’occasion de le faire. Corriger ces erreurs permettra d’améliorer continuellement votre code et de réduire progressivement la dette technique.

Si cela est fait de façon continue, vous pourrez toujours vous concentrez sur les fonctionnalités importantes et intéressantes de votre application, car les problèmes ne se seront jamais accumulés au sein de celle-ci. Cela évite, à terme, de devoir se focaliser sur des tâches techniques inintéressantes et parfois aberrantes, qui n’apportent aucune valeur à votre client mais qui existent seulement pour réduire la dette technique et éviter à votre application de s’écrouler. On est alors très loin de l’écriture d’un beau code simple et maintenable.

Quand s’arrêter ?

Il ne faut pas non plus entrer dans l’extrême de la refactorisation ⚠️. Si l’application de la Scout Rule prend trop de temps, d’énergie ou amène à modifier de trop grandes portions de code que celles initialement prévues, cela devient une autre tâche qu’il est nécessaire de qualifier et de quantifier. En effet, le but n’est pas de vous créer une autre tâche, mais plutôt d’améliorer continuellement les portions de code sur lesquels vous travaillez. Modifier des parties de code non prévues par la tâche originale ou s’attaquer à des fonctions structurelles par excès de perfectionnisme n’entrent pas dans le cadre de la Scout Rule.

Exemples d’anomalies rentrant dans le cadre de la Scout Rule

• Renommage de variables/fonctions incohérentes
• Extraction d’actions dans des variables ou des fonctions plus petites
• Création d’objet pour encapsuler de multiples paramètres à injecter en tant que dépendances
• Simplification de fonctions
• Optimisation et nettoyage des imports
• Nettoyage de portions de code inutilisées
• …

J’espère que cet article sur un principe fondamental du Clean Code vous aura plu, je vous dis à bientôt !👋