Point de complexité sans retour. Comment tu appelles ça?


13

En tant que développeur de logiciels, l'une de mes tâches principales est de garder la complexité sous contrôle.

Cependant, dans certains projets, il y a un moment où le niveau de complexité augmente si haut qu'il atteint une sorte de point de "non retour". Passé ce moment, vous ne pouvez jamais ramener le projet à un niveau de complexité acceptable en moins de temps que nécessaire pour tout réécrire à partir de zéro.

Ce moment particulier a-t-il un nom dans le dialecte des programmeurs (quelque chose de similaire à la loi de Godwin pour les trolls)?

--Éditer--

Désolé si je ne suis pas clair. Je ne pense pas que ce "moment" ait un nom officiel ou une métrique sérieuse. Je pensais à quelque chose dans l'esprit du "Ballmer peak" dans xkcd .


1
Je vois une controverse dans votre définition du point en question: ... en moins de temps que vous auriez besoin de tout réécrire à partir de zéro , ce qui implique que ceux qui vont réécrire le projet sont assez bons, ou du moins meilleurs que ceux qui créé le désordre en premier lieu;)
mojuba

1
Je pense qu'une des raisons pour lesquelles il n'y a pas de nom convenu est que cela dépend de qui regarde le code. Ce qui semble désespérément complexe ou irréalisable pour un développeur peut sembler assez raisonnable pour un autre. Dans les cas graves, je compile simplement dans une DLL avec un préfixe "ms" et dis que cela vient de Microsoft.
Kevin Hsu

1
Peut-être que cela ferait l'affaire: Événement sur la dette technique Horizon
PeterAllenWebb

Réponses:


20

C'est plus une question de maintenabilité que de complexité.

Le phénomène est appelé «dette technique» et une fois qu'il atteint un niveau critique, le projet est sur le point de faire faillite.

C'est ce que vous vouliez dire?


Merci pour votre réponse. Je connais le concept de "département technique". Chaque projet a une sorte de dette technique. Ce que je veux dire, c'est: comment appelez-vous le moment où cette dette devient si élevée que vous préféreriez jeter le projet aux ordures et recommencer?
Thibault J

3
J'aime votre terme de «faillite technique». Cela suggère que, tout comme dans une véritable faillite, vous devez regarder attentivement quelles parties sont récupérables et lesquelles doivent être laissées. Et peut-être qu'une restructuration de la dette est tout ce qui est vraiment nécessaire :)
Jaap

2
@Thibault J: Je ne pense pas qu'il y ait un terme spécifique pour ce moment. Il s'agit plutôt de savoir si vous êtes toujours heureux avant cette date ou si vous êtes malheureusement passé au-delà.

1
@ Developer Art: ... réalisant que si vous êtes toujours heureux avant cette date ou si vous êtes malheureusement passé au-delà - je pense que c'est la clé pour donner une bonne définition du point: un projet qui a dépassé le point est un projet qu'aucun ingénieur ne voudrait reprendre volontairement.
mojuba

3
Je vais opter pour le terme "faillite technique", j'aime bien. Et je vais également utiliser votre définition.
Thibault J

16

Le «point de complexité excessive» est désigné en anglais comme:

OH MON DIEU QU'EST-CE QUE CE CRAP.

Le problème est que cela peut s'appliquer à quelque chose qui est en fait simple, mais qui est mis en œuvre d'une manière si horrible que vous avez la même réaction.

Il peut donc être difficile de distinguer quelque chose de très complexe de quelque chose de très horrible.

CEPENDANT: Ce qui a tendance à arriver à tous les logiciels est un processus un peu comme ceci:

Étape 1: Avoir une belle spécification, faire une belle conception, mettre en œuvre de belles choses. Tout le monde est content.

À la fin de l'étape 1: les développeurs se félicitent de la merveilleuse élégance de leur conception et s'en vont heureux en pensant "J'ai un héritage merveilleux ici pour que d'autres ajoutent des choses à l'avenir, ce sera merveilleux et le monde sera un meilleur endroit."

Étape 2: Certaines modifications sont apportées, des choses sont ajoutées, de nouvelles fonctions sont incluses. L'architecture et la structure de l'étape 1 ont rendu ce processus assez indolore. [Mais oups, le "facteur de cruauté" a juste augmenté un peu.]

À la fin de l'étape 2: les développeurs se félicitent de la merveilleuse élégance de leur conception et s'en vont heureux en pensant "Gee, je suis tellement intelligent d'avoir fait toutes ces indemnités à l'étape 1. Cela s'est si bien passé. J'ai un merveilleux héritage ici pour que d'autres ajoutent des choses à l'avenir, ce sera merveilleux et le monde sera un meilleur endroit. "

Étape 3: Plus de modifications sont apportées, plus de choses sont ajoutées, plus de nouvelles fonctions, un tas de choses sont modifiées, les commentaires des utilisateurs sont réellement écoutés.

À la fin de l'étape 3: les développeurs se félicitent de la merveilleuse élégance de leur conception, et s'en vont assez heureux en pensant "Gee cette architecture est assez bonne pour permettre à tant de changements de s'insérer facilement. Mais je suis un peu mécontent à propos de X et Y et Z. Ils pourraient être nettoyés un peu maintenant. Mais !!! Ahhh !!! Je suis si intelligent d'avoir fait toutes ces allocations à l'étape 1. Cela s'est si bien passé. J'ai un merveilleux héritage ici pour d'autres à ajouter des choses à l'avenir, ce sera merveilleux et le monde sera un meilleur endroit. "

Étape 4: tout comme l'étape 3. Sauf:

À la fin de l'étape 4: les développeurs pensent: "Ce truc qui était si bon devient UGLY à entretenir. Il a vraiment besoin de changements sérieux. Je n'aime pas vraiment travailler là-dessus. Il a besoin de refactoring. Je me demande ce que le patron dira quand je lui dirai qu'il a besoin de 6 semaines et qu'il n'y aura rien à voir pour les utilisateurs à la fin de cela ... mais j'aurai encore 5 ans de portée de modification future délicieuse en faisant cela .... hmmm .. . le temps d'aller au pub pour un peu de bière. "

Étape 5: Un tas de modifications doivent être apportées.

Et PENDANT l'étape 5, les développeurs se disent: "Ce code est nul. Qui a écrit cela? Ils devraient être abattus. C'est horrible. Nous devons le RÉÉCRIRE."

L'étape 5 est fatale. C'est là que le facteur de cruauté est devenu si mauvais que le code ne peut pas simplement avoir quelques changements de plus, il doit avoir de gros changements.

Le problème à l'étape 5 est le désir de le jeter et de recommencer. La raison pour laquelle cela est fatal est "The Netscape Factor". Allez sur Google. Les entreprises meurent à ce stade, car recommencer signifie que vous commencez avec environ 50% d'hypothèses au lieu de faits, 150% d'enthousiasme au lieu de connaissances, 200% d'arrogance au lieu d'humilité ("Ces gars-là étaient tellement stupides!"). Et vous introduisez un tas de nouveaux bugs.

La meilleure chose à faire est de refactoriser. Changez un peu à la fois. Si l'architecture se fatigue un peu, corrigez-la. Ajoutez, étendez, améliorez. Progressivement. À chaque étape du parcours, testez, testez et testez encore plus. Des changements incrémentiels comme celui-ci signifient que 10 ans plus tard, le code actuel et original est comme une hache de grand-père ("il avait 10 nouvelles têtes et 3 nouvelles poignées mais c'est toujours une hache de grand-père"). En d'autres termes, il ne reste pas grand-chose en commun. Mais vous êtes passé de l'ancien au nouveau progressivement et avec soin. Cela réduit les risques, et pour les clients, cela réduit le facteur d'énervement.


Je parie que vous obtiendrez plus de votes si vous raccourcissez vos pas.
Codisme

Je dois ajouter que la plupart des entreprises ne prévoient pas de budget pour cela, donc le refactoring est toujours trop peu trop tard. Pour gérer l'entropie croissante des systèmes, il faut mettre en place, qu'à partir du jour 1, un budget (10% -20%) soit alloué à chaque tâche pour l'entretien ménager. Ce n'est pas un budget de correction de bugs. Les dépenses budgétaires sont décidées par l'ingénierie et non par la direction, le marketing ou les ventes. Il est uniquement utilisé pour prendre en compte l'entropie créée par le développement et les dépenses réduites à mesure que le produit approche de la fin de vie.
mattnz

D'accord. La direction veut toujours couper ce genre de chose. Parfois, vous pouvez vous en sortir en le masquant (ajoutez environ 20% à l'estimation du développement pour faire quoi que ce soit et quand une refactorisation est nécessaire - FAITES-LE).
vite_maintenant

1
Il y a un point où vous ne pouvez vraiment pas refactoriser. Si vous avez plusieurs applications commerciales disparates qui dépendent de la même interface ou base de données moche, vous ne pouvez pas très bien réparer les choses sous-jacentes sans casser toutes les autres applications qui dépendent de la fondation de merde. À ce stade, vous êtes vraiment foutu.
John Cromartie

2

Je suis d'accord que le moment est difficile à reconnaître et peut être évité par des processus appropriés. Cependant, la question était de savoir comment l'appeler. En économie réelle, il y a le concept de «rendements décroissants»: le point auquel l'augmentation des intrants pour une ressource dans un processus diminue votre profit global par unité. Cela s'applique certainement au codage, et même de bonnes choses comme l'abstraction, la réutilisation, etc. ont un tel point de rendements décroissants. Le terme général spécifique à la programmation est "ingénierie excessive". Pour quelqu'un qui est enclin à faire cela, j'aime le terme de Joel " astronaute d'architecture ".


1

Trop souvent, un bon code est jeté sous la fausse impression que la nouvelle équipe avec de nouveaux outils peut le faire moins cher, plus rapidement avec plus de fiabilité, pour constater que

  • La complexité réside dans les exigences de non-documentation
  • Les nouveaux outils sont plus difficiles à utiliser que le site flash promis
  • La nouvelle équipe n'est pas aussi «chaude» qu'elle le pensait

Peut-être que le temps que vous avez décrit arrive avec des bases de code (je le pensais auparavant). Je n'ai jamais personnellement expérimenté un cas d'ancien code provoquant un projet de ventre ou de code réécrit en enregistrant un projet.

Je n'inclus pas dans ce cas où des mesures ont été utilisées pour identifier des modules ou des conceptions problématiques spécifiques, qui ont ensuite été éliminés et remplacés.


Eh bien, j'ai vu un projet tellement f ** ed que leur budget de maintenance était trois ou quatre fois le budget de développement initial. Quoi qu'il en soit, le terme que je recherche n'est pas une chose "officielle" et sérieuse, mais plutôt quelque chose comme le "pic Ballmer" dans xkcd. Désolé si je ne suis pas très clair.
Thibault J

Mais comment est-il devenu si f ** ed? Si c'est à cause des exigences complexes, de la mauvaise gestion, des ingénieurs optimistes, pourquoi une réécriture le corrigerait-elle?
mattnz

Parce que l'équipe qui le réécrit n'est pas la même que celle qui l'a écrit au début?
Thibault J

1

Le vrai problème avec ce "moment" théorique est qu'il n'est reconnu qu'après coup. À moins que vos collègues ne soient des psychopathes, chaque engagement dans la base de code se fait avec la conviction que c'est une amélioration de cette base de code. C'est seulement en regardant le désordre qui s'ensuit que vous pouvez voir que vous avez passé ce "moment".

Mais j'aime qu'on puisse lui donner un nom. "Messieurs", pourriez-vous dire, en attirant vos collègues développeurs autour de vous, "Nous avons traversé la maintenabilité Hellespont. Envoyez un SMS à votre femme et dites-lui que vous ne la verrez pas avant un moment."


"chaque commit dans la base de code se fait avec la conviction que c'est une amélioration de cette base de code." Il semble que nous n'ayons jamais travaillé dans les mêmes entreprises :)
Thibault J

@ThibaultJ - Peut-être que vos collègues étaient psychopathes?
Dan Ray

@Thibault J: Je crois que chaque commit est fait avec la conviction que c'est une amélioration de cette base de code. La croyance est parfois mal documentée et sans fondement, bien sûr.
David Thornley

Lors de mon dernier travail, je ne pense pas qu'il y ait d'engagement de maintenance que quiconque ait jamais fait avec la conviction que c'était une amélioration de la base de code.
Bobby Tables

Parfois, les exigences d'un projet peuvent changer suffisamment pour forcer le remplacement par une nouvelle conception, mais il peut néanmoins être nécessaire d'apporter des modifications à l'ancienne version. Si la plupart des anciens utilisateurs de l'ancienne version utiliseront le nouveau système et n'auront plus besoin de l'ancien, il peut être parfaitement raisonnable de produire une version qui réponde aux besoins de quelques-uns pour qui le nouveau système ne convient pas, même s'il le serait rendre le système moins utilisable pour les personnes qui n'en ont plus besoin de toute façon.
supercat

-1

Je ne sais pas s'il y a un nom mais s'il n'y en a pas je proposerais de l'appeler "point de fusion"


Ou pour emprunter un autre terme nucléaire: masse critique.
John Cromartie

-2

Ce n'est pas une question très intéressante.

En effet, c'est trivial.

C'est tellement trivial que nous avons évolué de nombreuses façons de faire face.

  1. Méthodologies de cascade. Beaucoup de gens passent beaucoup de temps à examiner les exigences et à concevoir des documents pour être sûr que la complexité est gérée.

  2. Méthodologies Agiles. Moins de gens passent moins de temps à discuter de ce qui est immédiatement applicable pour résoudre le problème de quelqu'un et leur proposer un logiciel. La complexité est gérée parce que tout le monde se concentre sur la sortie de quelque chose.

La seule fois où quelqu'un se débat avec la «complexité», c'est parce qu'il n'a pas suivi la méthodologie et géré correctement son temps.

  • Pas de supervision détaillée dans une méthodologie de cascade. Ils ne sont pas obligés d'examiner les produits de travail intermédiaires au niveau des exigences, de l'architecture, de la conception de haut niveau ou des revues de conception détaillées.

  • Pas de délai de sprint ou de priorités de cas d'utilisation dans une méthodologie Agile. Ils ne se concentrent pas sur la diffusion de quelque chose à l'utilisateur le plus rapidement possible.

La complexité doit être limitée en fixant des objectifs.

Lutter contre la complexité signifie que les objectifs ne sont pas fixés ou ne sont pas récompensés correctement.

Il n'y a pas de "tournant". Si la gestion de la complexité est en quelque sorte un problème, quelque chose ne va déjà pas sur le plan organisationnel.


1
Je ne vois pas l'intérêt. Il est très peu probable qu'un projet bien géré atteigne le point de non-retour, mais tous les projets ne sont pas bien gérés. Certains projets mal exécutés réussiront de toute façon, et les autres échoueront pour diverses raisons, atteignant parfois le point de complexité du non-retour et parfois non.
David Thornley

@David Thornley: C'est mon point. Le «point de complexité sans retour» n'existe pas. C'est simplement une mauvaise gestion. Il n'y a pas besoin d'un nom sophistiqué ou d'une règle. La complexité n'est qu'un symptôme d'une mauvaise gestion. Pas vraiment très intéressant.
S.Lott

@ S.Lott: Je pense que cela existe, mais pas dans des projets bien gérés. Il existe une horde de projets mal gérés, et certains d'entre eux entreront dans l'horizon des événements de complexité et d'autres non. Je ne pense vraiment pas qu'il soit utile de regrouper toute mauvaise gestion ensemble.
David Thornley

@David Thornley: Je pense qu'il est très difficile de dissocier la mauvaise gestion (ce qui conduit à une complexité horrible) de la mauvaise gestion (ce qui conduit tout le monde à démissionner). Je ne vois pas comment dire si un projet deviendra trop complexe ou juste en retard ou tout simplement incompétent.
S.Lott

@ S.Lott: Cependant, il y a une distinction entre un projet où tout le monde quitte ou subit une panne de santé majeure et un projet où la complexité devient trop. Il existe différentes façons d'échouer, et il peut être intéressant, voire utile, de les classer.
David Thornley

-2

Il existe des méthodes pour visualiser et surveiller le risque d'augmenter la complexité des (gros) projets et du code. Quand ils sont appliqués avec un peu de chance, un nouveau nom pour le point de non-retour n'est pas nécessaire. (Il existe un MOOC associé sur openHPI: https://open.hpi.de/courses/softwareanalytics2015/ )

La complexité structurelle est un problème de conception général - pas seulement pour la conception de logiciels dans de grandes équipes. La visualisation est la première étape de la gestion de la complexité structurelle. Des matrices et des graphiques dirigés peuvent également être utilisés à cette fin.

Les quelques méthodes pour réduire la complexité structurelle sont http://www.buch.de/shop/home/suche/?fq=3540878890 :

  • modularisation
  • éviter les boucles de rétroaction
  • triangulation

En outre, il existe le concept de conception axiomatique: https: \ en.wikipedia.org \ wiki \ Axiomatic_design \ Avec ce concept, les problèmes de fiabilité dus à une complexité inutile peuvent être évités.

Il existe donc un tas de méthodes disponibles. En fin de compte, il s'agit toujours de la décision d'y penser parce qu'un projet devient suffisamment grand.


Cela ne répond pas à la question.
Hulk
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.