Grosse boule de boue - Big ball of mud

Une grosse boule de boue est un système logiciel qui n'a pas d'architecture perceptible. Bien que indésirables du point de vue de l'ingénierie logicielle, ces systèmes sont courants dans la pratique en raison des pressions commerciales, du roulement des développeurs et de l' entropie du code . Ils sont un type d' anti-motif de conception .

Dans les programmes informatiques

Le terme a été popularisé dans l'article de Brian Foote et Joseph Yoder de 1997 du même nom, qui définit le terme:

A Big Ball of Mud est une jungle de code spaghetti structurée au hasard, tentaculaire, bâclée, avec du ruban adhésif et du fil de mise en balles . Ces systèmes montrent des signes indéniables de croissance non régulée et de réparations répétées et opportunes. Les informations sont partagées de manière promiscue entre les éléments distants du système, souvent au point où presque toutes les informations importantes deviennent globales ou dupliquées.

La structure globale du système n'a peut-être jamais été bien définie.

Si c'était le cas, il s'est peut-être érodé au-delà de toute reconnaissance. Les programmeurs avec une once de sensibilité architecturale évitent ces bourbiers. Seuls ceux qui ne se soucient pas de l'architecture et, peut-être, sont à l'aise avec l'inertie de la corvée quotidienne de colmatage des trous dans ces digues défaillantes, se contentent de travailler sur de tels systèmes.

-  Brian Foote et Joseph Yoder, Big Ball of Mud. Quatrième conférence sur les langages de modèles de programmes (PLoP '97 / EuroPLoP '97) Monticello, Illinois, septembre 1997

Foote et Yoder ont crédité Brian Marick comme l'initiateur du terme «grande boule de boue» pour ce type d'architecture.

Les programmeurs qui contrôlent un grand projet de boule de boue sont fortement encouragés à l'étudier et à comprendre ce qu'il accomplit, et à l'utiliser comme une base lâche pour un ensemble formel d'exigences pour un système bien conçu qui pourrait le remplacer. Les changements technologiques, tels que le client-serveur vers le Web ou les fichiers vers les bases de données, peuvent fournir de bonnes raisons de recommencer à zéro.

Par rapport à Lisp

Dans la discussion du langage de programmation Lisp, le terme big ball of mud est utilisé différemment, dans ce cas pour décrire la malléabilité d'un système Lisp. En Lisp, il est généralement possible de:

  • Écrivez facilement des macros qui donnent le contrôle sur la syntaxe du langage , de sorte que la notation se rapproche du domaine du problème
  • Utilisez un style de programmation orienté données
  • Exécuter des parties d'un programme au moment de la compilation plutôt qu'au moment de l'exécution
  • Enregistrer une image système d'une implémentation Lisp modifiée pour une utilisation future

En raison de la confluence de ces fonctionnalités, Lisp est extraordinairement flexible, même à un point tel que l'implémentation du langage elle-même peut être complètement réécrite pendant l'exécution (c'est-à-dire une métaprogrammation réfléchissante ), ce qui peut entraîner des systèmes Lisp devenant «confus» au fil du temps. à la fluidité et à la facilité avec lesquelles ils peuvent être étendus et évoluer grâce à une utilisation simple. L'abstraction métalinguistique , une caractéristique importante de Lisp, permet également aux programmeurs de développer des vocabulaires conceptuels entièrement nouveaux et idiosyncratiques pour décrire les processus et les fonctions que leurs programmes traversent pour s'attaquer à un domaine problématique, et peuvent, s'ils sont combinés avec une documentation logicielle médiocre, aboutir à des systèmes Lisp qui fonctionnent très bien et sont en effet assez bien structurés du point de vue de la conception, mais ne sont compréhensibles que pour les codeurs d'origine, ou pour toute autre personne désireuse d'investir le temps de passer au crible des couches de code hautement récursif .

Joel Moses a été crédité d'avoir inventé l'expression dans les années 1970:

APL est comme un beau diamant - impeccable, magnifiquement symétrique. Mais vous ne pouvez rien y ajouter. Si vous essayez de coller un autre diamant, vous n'obtenez pas un diamant plus gros. Lisp est comme une boule de boue. Ajoutez-en plus et c'est toujours une boule de boue - cela ressemble toujours à Lisp.

Moses nie fermement cela, affirmant qu'il a plutôt appelé Lisp un pouf parce qu'il reprend toujours sa forme d'origine.

Voir également

Remarques

  1. ^ Foote, Brian; Yoder, Joseph (26 juin 1999). "Grande Boule de Boue" . laputan.org . Récupéré le 14 avril 2019 . CS1 maint: paramètre découragé ( lien )
  2. ^ Richard P. Gabriel et Guy L. Steele (1996). "L'évolution de Lisp" . ACM Histoire des langages de programmation — II . 28 (3): 233–330. doi : 10.1145 / 155360.155373 .
  3. ^ Thomas J. Bergin et Richard J. Gibson (1996). "Matériel supplémentaire de HOPL II" . Avis ACM SIGPLAN . 31 (11): 9–20. doi : 10.1145 / 240964.1198155 .

Les références

  • Guy L. Steele, Jr. & Richard P. Gabriel L'évolution de Lisp [1] , note sur la référence 128
  • Brian Foote et Joseph Yoder, Big Ball of Mud Quatrième conférence sur les modèles langages de programmes (PLoP '97 / EuroPLoP '97) Monticello, Illinois, septembre 1997