- Grande boule de boue
-
En programmation informatique, une grande boule de boue est un terme utilisé pour décrire un système ou logiciel informatique n'ayant pas d'architecture évidente.
En génie informatique
Le terme a été popularisé par Brian Foote et Joseph Yoder dans leur article de 1999 « Big Ball of Mud », avec la définition suivante :
« Une grande boule de boue est une vaste jungle de code mal structuré, programmé en spaghetti, peu soigné et souvent rafistolé. Ces systèmes témoignent clairement des traces d'une expansion incontrôlée, ainsi que de fréquentes réparations opportunes et improvisées. Les informations sont partagées sans distinction parmi les éléments distants du système, souvent jusqu'au point où presque toutes les informations importantes deviennent globales ou dupliquées. La structure du système dans son ensemble n'a peut être jamais été bien définie. Si elle l'a été, le système a tellement détérioré qu'il est impossible de la reconnaitre. Les programmeurs avec un brin de sensibilité architecturale fuient ces bourbiers. Seuls ceux qui ne se concernent pas avec l'architecture, et qui, peut être, sont confortables dans l'inertie d'une corvée quotidienne consistant à coller des rustines sur ces digues défaillantes, sont heureux de travailler sur de tels systèmes. »
Des systèmes en « grande boule de boue » ont normalement suivi un long processus de développement, avec des individus différents travaillant sur diverses parties. Souvent, des systèmes développés par des personnes sans formation d'architecture informatique ou de programmation peuvent tomber dans cet antipattern.
Néanmoins, Foote et Yoder ne condamnent pas universellement la programmation en « grande boule de boue », notant que cet antipattern est courant parce que le système qui s'ensuit fonctionne – du moins initialement. Par contre, les logiciels de ce type deviennent extrêmement difficiles à maintenir et à améliorer.
Les développeurs ou mainteneurs ayant pour charge un projet en grande boule de boue sont fortement encouragés à l'étudier et à comprendre ses fonctionnalités afin de créer les spécifications d'un système bien architecturé ayant pour but de le remplacer. Des changements de technologies, par exemple d'un système client-serveur vers une plateforme web ou l'utilisation d'une base de données au lieu de fichiers, peuvent motiver la décision de tout reprendre depuis le début.
Notes et références
- Big Ball of Mud Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997 Brian Foote and Joseph Yoder,
Wikimedia Foundation. 2010.