Existe-t-il une corrélation entre la complexité du code et la productivité des développeurs?

10

Le temps passé à refactoriser une base de code en vaut-il la peine à long terme, en termes de productivité des développeurs?

Il me semble assez clair que modifier un système propre et bien conçu est beaucoup plus simple et plus rapide que de travailler sur un système mal conçu, mais je recherche des preuves solides. Existe-t-il des études sur ce sujet?

productivity complexity

— Benny Hallett
source

Voir RECONSTRUCTION

— hakre

1

Commencez à maintenir un gâchis vous-même et soyez le juge.

— Tulains Córdova

16

Empiriquement, les logiciels avec des métriques de complexité plus élevée, comme la complexité cyclomatique, sont plus difficiles à maintenir. Il existe des recherches à l'appui de cela remontant aux années 1970 ("Program Complexity and Programmer Productivity", ET Chen) . Des travaux suggèrent également que la densité de complexité, qui est la complexité cyclomatique sur la taille du système, se rapporte également au temps de maintenance ("Densité de complexité cyclomatique et productivité de la maintenance logicielle", GK Gill, CF Kemerer) , qui est également disponible gratuitement ici . Malheureusement, un abonnement IEEE est nécessaire pour le document de Chen, mais vous pouvez essayer de le rechercher sur d'autres sources si vous êtes intéressé.

Du point de vue de la qualité, il vaut souvent la peine de passer du temps à refactoriser, en supposant que vous disposez d'un cadre de test pour empêcher l'introduction de nouveaux défauts. Cela vous permettra d'implémenter plus facilement de nouvelles fonctionnalités sur votre système, d'ajouter des tests supplémentaires et de former de nouveaux développeurs au travail.

En fin de compte, cependant, la pression est de fournir de nouvelles fonctionnalités et une valeur ajoutée. Vous devez équilibrer le refactoring avec la mise en œuvre de nouvelles fonctionnalités et la réparation des défauts.

— Thomas Owens
source

2

un autre point à ajouter est que lorsque vous refactorisez, vous implémentez également probablement des fonctionnalités d'une manière meilleure / plus efficace / plus propre. Il y a un adage que j'ai entendu une myriade de fois selon lequel "dans 5 ans, vous grincerez des dents que vous pensiez que votre code était" bon ""

— warren

1

@hakre J'ai vérifié quand j'ai posté ceci et encore maintenant, en utilisant à la fois une recherche sur Google et Google Scholar. Au moment où j'ai écrit cet article à l'origine, aucun papier n'était disponible sans achat. Cependant, depuis lors, un article a été publié sur un domaine de l'Université de Pittsburgh qui semble appartenir à l'un des auteurs et j'ai ajouté un lien vers celui-ci. L'autre papier n'est pas disponible gratuitement. J'ai ajouté les titres au corps du message pour faciliter leur recherche. Si vous ne voulez pas lire les articles, vous devrez accepter mon analyse, couplée à mes connaissances et mon expérience.

— Thomas Owens

0

Je cherche des preuves solides

Alors arrêtez de perdre votre temps ici.

Trouvez du code dont la maintenance est coûteuse. C'est facile. Regardez les tickets d'incident de votre organisation.
Trouvez du code bon marché à maintenir. Recherchez le code qui s'exécute fréquemment, mais qui a peu ou pas de tickets d'incident.
Mesurez la complexité avec l'un des outils de complexité largement disponibles.
Imprégnez-vous des preuves.

Vous avez maintenant fourni des chiffres pour confirmer l'évidence.

— S.Lott
source

5

Pas vraiment. la complexité de la tâche effectuée par le logiciel doit être distinguée de la complexité supplémentaire provoquée par l'implémentation choisie.

— reinierpost

4

-1 pas une réponse

— Dave Hillier