Combien de programmeurs faut-il pour conserver le code précédemment écrit ?

Il y a quelque temps, une conversation a eu lieu entre moi et un de mes bons amis au cours de laquelle les phrases suivantes ont été entendues :

— Le nombre de programmeurs augmentera constamment - parce que la quantité de code augmente et que de plus en plus de développeurs doivent constamment le prendre en charge.
— Mais le code vieillit, une partie n'est plus supportée. Il est même possible qu’il existe une sorte d’équilibre.

En m'en souvenant quelques jours plus tard, je me suis demandé si le maintien du code, exigeant de plus en plus de ressources au fil du temps, pourrait à terme paralyser le développement de nouvelles fonctionnalités, ou nécessiterait-il une augmentation illimitée du nombre de programmeurs ? L'analyse mathématique et les équations différentielles ont permis d'évaluer qualitativement la dépendance du montant de l'aide au développement et de trouver des réponses aux questions.

Question une. Le support peut-il « consommer » toutes les ressources de développement ?

Considérons une équipe de programmeurs dans laquelle le nombre de participants est constant. Part de leur temps de travail () est consacré au développement d'un nouveau code et le temps restant va au soutien. Dans les hypothèses du modèle, nous supposons que le premier type d'activité vise à augmenter le volume de code, et le second vise à le modifier (correction des erreurs) et n'a pas d'impact significatif sur le volume de code.

Dénoter la quantité totale de code écrit jusqu'à ce moment-là . En supposant que la vitesse d'écriture du code est proportionnelle , on a:

Il est naturel de supposer que les coûts de main-d'œuvre nécessaires à la maintenance du code sont proportionnels à son volume :

ou

D'où

On obtient une équation différentielle facilement intégrable. Si au moment initial la quantité de code est nulle, alors

à fonction Et . Et cela signifie une réduction progressive au fil du temps du développement de nouvelles fonctionnalités à zéro et le transfert de toutes les ressources vers le support.

Cependant, si pendant le temps le code devient obsolète et cesse d'être pris en charge, puis la quantité de code nécessitant une prise en charge à la fois est déjà égal Puis

а est une solution d'une équation différentielle avec un argument retardé [1] :

La solution d'une telle équation est uniquement déterminée en spécifiant les valeurs "avant le début des temps" . Puisque le code n’avait pas encore été écrit avant le moment initial, dans notre cas à .

Regardons quelques exemples. Nous mesurerons le temps en années et la quantité de code en milliers de lignes. Puis pour des valeurs de l'ordre des dizaines sont acceptables, nous en prendrons 50 et 100. Autrement dit, en un an, l'équipe de développement écrira respectivement cinquante et cent mille lignes de code. Pour les valeurs acceptables peuvent être : , , . Cela signifie qu'une équipe de développement peut prendre en charge la quantité de code qu'elle écrit au cours d'une année, que ce soit un trimestre, une moitié ou un temps plein. Comme durée de vie moyenne du code, nous fixerons les valeurs suivantes : 1, 2 et 4 ans. En résolvant l'équation numériquement, nous obtenons des exemples du comportement de la fonction pour certaines combinaisons de paramètres .

Comportement de la fonction à mesure que le code vieillit, il a changé. La fonction n'est plus monotone, mais les fluctuations « se calment » avec le temps, et il y a une tendance à à une valeur constante. Les graphiques montrent : plus , и , c'est-à-dire que plus le code vieillit lentement, plus le développement d'un nouveau code est rapide et plus la qualité du code est faible, moins il restera de ressources pour le développement de nouvelles fonctionnalités. On souhaitait donner au moins un exemple dans lequel « blotti » proche de zéro. Mais cela a nécessité la sélection d'indicateurs de très mauvaise qualité de développement et d'un code qui ne vieillit pas longtemps. Même dans le graphique en bas à gauche, il reste une quantité importante de ressources pour la nouvelle fonctionnalité. Par conséquent, la bonne réponse à la première question est plutôt celle-ci : théoriquement - oui, c'est possible ; pratiquement - à peine.

Questions auxquelles il n'a pas été possible de répondre :

1. Est-il vrai que tend vers une certaine limite à pour tous ? Si ce n’est pas pour tout le monde, alors pour lesquels ?
2. Si une limite existe, comment sa valeur dépend-elle de ?

Deuxième question. La maintenance du code pourrait-elle entraîner une croissance illimitée du nombre de programmeurs ?

Dénoter le nombre de programmeurs impliqués dans le développement d’un nouveau code. Comme ci-dessus, — la quantité de code écrit jusqu'à un moment donné . puis

Gardez le support du code occupé programmeurs. Compte tenu du code du vieillissement,

D'où

si puis

Ainsi, la réponse à la deuxième question est négative : si le nombre de développeurs de nouveau code est limité, alors dans des conditions de code vieillissant, le support ne peut pas provoquer une augmentation illimitée du nombre de programmeurs.

Conclusion

Les modèles considérés sont des modèles mathématiques « mous » [2]. Ils sont très simples. Néanmoins, la dépendance des résultats de simulation sur les valeurs des paramètres correspond à ce qui est attendu pour les systèmes réels, cela plaide en faveur de l'adéquation des modèles et d'une précision suffisante pour obtenir des estimations de haute qualité.

Références

1. Elsgolts L.E., Norkin S.B. Introduction à la théorie des équations différentielles avec argument déviant. Moscou. Maison d'édition "Science". 1971.
2. Arnold V.I. Modèles mathématiques « durs » et « mous ». Moscou. Maison d'édition MCNMO. 2004.

Source: habr.com