WOUM : Principe, en développement informatique, de ne jamais se répéter. Idem « DRY » (« Don't Repeat Yourself » - « Ne vous répétez pas »), plus répandu.

cr  01.04.2012      r+  22.10.2024      r-  22.10.2024      Pierre Pinard.         (Alertes et avis de sécurité au jour le jour)

WOUM (Write Once Use Many)

Principe de développement, en écriture de programmes informatique, consistant à ne pas réécrire 36 fois la même chose mais à en faire un bout de code (un composant) réutilisable. C'est une expression et un acronyme inventé par l'auteur de cet article au début des années 70, pour un usage personnel (pour les fouineurs et archéologue, utilisation de la clause « copy », en Cobol, pour du code natif, ou de la clause « include » pour du code précompilé).

Comme il s'agit de développer plus vite, WOUM se rapprochait aussi de l'onomatopée Vroum ! Vroum !

WOUM n'a pas fait école et est identitique à un terme plus tardif et plus répandu : DRY (« Don't Repeat Yourself » - « Ne vous répétez pas »).

Dans Microsoft Windows, l'idée conceptuelle fondatrice des DLLs et des Frameworks (par exemple les Microsoft .Net Framework) est le principe, en programmation informatique, du WOUM, ou DRY (« Don't Repeat Yourself » - « Ne vous répétez pas »). Ce principe est né de manière concomitante aux très grands projets informatiques, nécessitant des millions de lignes de code par application. Ce principe était déjà largement utilisé, bien que non formalisé, au début des années 1970.

On réécrit les mêmes « routines » (les mêmes séquences d'instructions), de très nombreuses fois, au sein d'une unique application et, plus encore, à travers toutes les applications d'un projet. Le principe de développer des briques logiciels, des bibliothèques de fonctions et services, vient de cette observation, dopée aux fantasmes des informaticiens :

• Ne pas réécrire 36 fois la même chose (éviter la redondance de code à travers tout un projet, voire toute la production logicielle d'un éditeur) de manière à gagner du temps et de la place en mémoire, d'autant que dans les années 1970, la mémoire coûtait une fortune.

• Écrire un segment de code une bonne fois pour toutes, de manière parfaite et universelle (documenté, non ambigüe, optimisé...)

• Gagner en vitesse de développement

• Gagner en fiabilité et stabilité (s'appuyer sur des fondations éprouvées)

• Gagner en vitesse de débogage et tests (élever son point de vue et se concentrer sur la conception et l'architecture de l'application)

• Gagner en maintenance et évolution (documentation, universalité, portabilité...).