Existe-t-il un anti-modèle formel pour décrire le scénario?

Du code est écrit pour générer des feuilles de calcul Excel (Office Interop).

• Le code fonctionne très mal.
  
  • Un sous-système est conçu pour générer les fichiers la nuit. La performance n'est pas un problème la nuit.
    • Une fonction est créée pour sélectionner le fichier correct parmi les 100 fichiers différents disponibles en fonction d'un ensemble de paramètres choisi.
    • Étant donné qu'il existe des fichiers physiques, un système d'archivage est ajouté pour sauvegarder ces fichiers (il n'y a aucune raison d'archiver. Ces fichiers doivent être générés à la volée).
    • Ce système n'inclut pas de fichier de configuration, au lieu de cela il a une fonction codée en dur "sélecteur de serveur" qui réfléchit simplement sur le serveur sur lequel le code est exécuté.
    • Une tâche planifiée est nécessaire pour prendre en charge et exécuter ce service.

Cela se résume à un seul problème. Le code d'origine fonctionne beaucoup trop mal pour fonctionner dans un environnement de production.

Si le problème de performances avait été résolu, le sous-système et le système d'archivage subséquent, la «fonction d'usine du sélecteur de fichiers», le point de défaillance codé en dur et la maintenance de la tâche planifiée et son point de défaillance supplémentaire n'ont pas besoin d'exister.

C'est un "échec en cascade" si vous voulez. Le problème d'origine a entraîné plus de mauvais code, plus de mauvaises solutions et des frais généraux inutiles. Existe-t-il un anti-modèle formel ou un terme général pour le décrire?

Coulée de lave?

Dans le jargon de programmation informatique, la coulée de lave est un problème dans lequel du code informatique écrit dans des conditions sous-optimales est mis en production et ajouté tout en étant dans un état de développement.

Du Perl Design Wiki: Lava Flow est "quand le code ... jaillit et devient permanent, il devient une caractéristique architecturale de la variété archéologique. Les choses sont construites au-dessus de la structure sans question et sans espoir de changer ce qui est en dessous. le code existant est considéré comme une curiosité historique. "

Souvent, la mise en production du système entraîne le besoin de maintenir une compatibilité descendante (car de nombreux composants supplémentaires en dépendent désormais) avec la conception originale et incomplète.

Les flux de lave sont souvent exacerbés par les changements dans l'équipe de développement travaillant sur un projet. Au fur et à mesure que les travailleurs entrent et sortent du projet, la connaissance de l'objectif des aspects du système peut être perdue, et plutôt que de nettoyer ces éléments, ils sont contournés, augmentant la complexité et le désordre du système.

La coulée de lave est considérée comme un anti-modèle, un phénomène couramment rencontré conduisant à une mauvaise conception.

Je ne suis pas sûr que ce soit un anti-modèle. Comme pour tous les anti-modèles, nous devons croire que quiconque pensait que c'était une bonne idée s'était trompé, mais dans ce cas, cela semble plausible et je vais vous croire sur parole, donc ce n'est pas le problème.

Le problème est que pour être utile, un anti-modèle doit décrire une sorte d'écueil général et comment l'éviter. Dans ce cas, je suppose que ce serait trouver une solution de contournement pour le code qui fonctionne mal alors que vous auriez pu simplement le faire mieux.

Le problème avec cela en tant qu'anti-modèle, à mon humble avis, c'est que le savoir semble peu susceptible d'avoir beaucoup de valeur. Quiconque a fait cela a probablement déjà compris qu'il serait bien de savoir comment le rendre plus performant, donc ils ne devaient pas savoir comment le faire. Donc, avoir entendu parler de la situation générale en tant qu'anti-modèle n'aurait pas vraiment aidé.

En ce qui concerne un terme général pour le décrire, "l'échec en cascade", comme vous l'avez suggéré, fonctionne plutôt bien. Le terme que j'aime pour les personnes non qualifiées partant pour une mission qui n'avait pas de sens en premier lieu est la chasse au snark , mais cela semble trop dur pour cette situation. (Mais je vais quand même jeter un peu gratuitement le lien, car c'est la meilleure représentation d'une entreprise condamnée que je connaisse).

Je ne sais pas si cela aide, mais la bureautique est souvent un cas spécial:

La bureautique est généralement effectuée de cette façon si elle doit être automatisée à partir d'un bureau utilisateur (en particulier pour les sites Web .net car les documents de bureautique vous avertissent correctement qu'il y aura de mauvaises fuites dans les outils d'interopérabilité de bureau s'ils sont exécutés sans tête. forcé d'écrire des processus sans tête pour générer des documents de bureau avec cette boîte à outils, nous avons appelé les services sacrificiels parce que vous deviez les assassiner périodiquement pour récupérer la mémoire.

Outre l'archivage, ce que vous décrivez est malheureusement une meilleure pratique dans certains cas.

Lien: http://support.microsoft.com/kb/257757