Complexité accidentelle

En développement logiciel le terme complexité accidentelle désigne la complexité introduite dans des programmes informatiques non en raison de la complexité du problème, mais de manière accidentelle en raison de choix de développement non pertinents. Il a été inventé par Frederick Brooks dans son article No Silver Bullet ^[1]. Ce terme est réutilisé dans différentes études proposant des outils pour lutter contre ce phénomène ^[2]^,^[3].

Description[modifier | modifier le code]

Le terme de complexité accidentelle est lié au problème créé par une implantation ou un langage donné. Ce terme s'oppose à celui de complexité essentielle qui lui décrit la complexité propre à un problème.

Les causes sont diverses :

le développeur n'est pas familier avec les capacités de la technologie utilisée ;
le souhait de généraliser le travail en prévision de fonctionnalités futures ;
le développeur ne prend pas le temps d'optimiser et de réusiner son code : il en résulte une complexité croissante.

Solution[modifier | modifier le code]

Les solutions pour contrer ces causes sont :

prendre le temps de se former aux technologies afin d'appréhender plus finement leurs possibilités ;
éviter de généraliser les fonctionnalités et ainsi tout surcoût en complexité ;
prendre soin de réusiner son code.

Dans un monde utopique, il existerait un programme capable de simplifier n'importe quel code afin d'en éliminer sa complexité accidentelle.

Exemple[modifier | modifier le code]

Afin d'illustrer cet anti-patron, nous allons essayer de répondre au problème de la somme des $n$ premiers nombres impairs.

Dans une première implantation du problème, nous utilisons une variable somme_impairs comme compteur sommant les nombres impairs et impair_suivant pour déterminer le prochain nombre impair à sommer. Il s'ensuit une boucle allant de 0 à $n$ (exclu) permettant de sommer la suite des n premiers impairs :

unsigned int somme_n_impairs(unsigned int n) {
	unsigned int somme_impairs = 0;
	unsigned int impair_suivant = 1;

	for (int i = 0; i < n; n++) {
		somme_impairs = somme_impairs + impair_suivant;
		impair_suivant = impair_suivant + 2
	}

	return somme_impairs;
}

Cet algorithme possède une complexité temporelle en $O(n)$ . Comme attendu, il existe une solution algorithmique répondant à ce problème en une complexité temporelle restreinte ( $O(1)$ ) :

unsigned int somme_n_impairs(unsigned int n) {
	return n * n;
}

Pour répondre à ce problème, il suffit de monter au carré le paramètre $n$ : $S_{n}=1+3+5+\cdots +(2n-1)=\sum _{i=1}^{n}(2i-1)=n^{2}$ .

Articles connexes[modifier | modifier le code]

Notes et références[modifier | modifier le code]

↑ Brooks, « No Silver Bullet Essence and Accidents of Software Engineering », Computer, vol. 20, n^o 4,‎ avril 1987, p. 10–19 (ISSN 0018-9162, DOI 10.1109/mc.1987.1663532, lire en ligne, consulté le 18 avril 2020)
↑ (en) Colin Atkinson et Thomas Kühne, « Reducing accidental complexity in domain models », Software & Systems Modeling, vol. 7, n^o 3,‎ 1^er juillet 2008, p. 345–359 (ISSN 1619-1374, DOI 10.1007/s10270-007-0061-0, lire en ligne, consulté le 20 avril 2020)
↑ Haslum, P. (2007, January). Reducing Accidental Complexity in Planning Problems. In IJCAI (pp. 1898-1903).

Portail de l’informatique

[1] Brooks, « No Silver Bullet Essence and Accidents of Software Engineering », Computer, vol. 20, n^o 4,‎ avril 1987, p. 10–19 (ISSN 0018-9162, DOI 10.1109/mc.1987.1663532, lire en ligne, consulté le 18 avril 2020)

[2] (en) Colin Atkinson et Thomas Kühne, « Reducing accidental complexity in domain models », Software & Systems Modeling, vol. 7, n^o 3,‎ 1^er juillet 2008, p. 345–359 (ISSN 1619-1374, DOI 10.1007/s10270-007-0061-0, lire en ligne, consulté le 20 avril 2020)

[3] Haslum, P. (2007, January). Reducing Accidental Complexity in Planning Problems. In IJCAI (pp. 1898-1903).

[1]

[2]

[3]