Combien d'efforts sont consacrés à la maintenance d'un système de génération?


9

Dans le podcast StackExchange # 09, il est indiqué :

Une autre étude a récemment examiné combien d'efforts sont consacrés à la maintenance du système de build: 5 à 30% de tous les efforts de développement sont consacrés à la maintenance du système de build. Avec des variations énormes même lorsque l'on travaille sur des projets similaires.

Quel est le nom de l'étude référencée et où la trouver? L'audio du podcast ne contient aucun autre détail.

De plus, quelqu'un a-t-il des liens vers d'autres études couvrant le même sujet.


3
Sensationnel. Je n'ai jamais pensé qu'un magasin pouvait passer autant de temps sur un système de construction. Nous avons un système de construction fait à la main et sur mesure qui crée toutes les nuits toutes les (20 certaines) versions et (50 certaines) branches de développement (si des modifications ont été validées), démarre les tests unitaires et arrête et démarre les serveurs de test (un ou plus par version et une ou plusieurs pour de nombreuses branches de développement), envoyer des résultats, etc. Pourtant, depuis 4 ans que je travaille chez cet employeur, je ne pense pas que nous ayons dépensé beaucoup plus que quelques semaines de travail dessus et que comprend l'extension des fonctionnalités de notre solution sur mesure!
Marjan Venema

C'est ce qui arrive quand les gens font référence à quelque chose / quelqu'un et oublient d'ajouter les références ...
wleao

Je ne connais pas l'étude, mais les résultats peuvent différer selon ce que vous définissez par «maintenir le système de build». "L'ajout ou la modification de fichiers" en fait-il partie? La configuration d'un programme d'installation fait-elle partie de la "maintenance du système de génération"?
Doc Brown

Réponses:


1

Je n'ai pas entendu le podcast, mais l'étude est probablement un article du plus récent ICSE , intitulé "An Empirical Study of Build Maintenance Effort" par Shane McIntosh et al. Vérifiez le lien direct (ou la page officielle DOI si vous voulez des métadonnées).

Leur étude se concentre principalement sur la fréquence à laquelle les modifications du code source ont un impact sur la génération et sur le nombre de développeurs d'une équipe qui sont généralement concernés par la maintenance de la génération. Je me souviens que c'est une étude intéressante, mais j'ai trouvé les chiffres un peu difficiles à interpréter, comme c'est souvent le cas avec des études empiriques essayant de trouver des liens entre les choses :)


2

Je n'ai pas de lien pour vous, mais parlant d'expérience personnelle, ce pourcentage varie selon 2 points principaux: 1) la conception et la complexité du système 2) et l'organisation personnelle

Un système bien conçu nécessitera un minimum d'efforts à maintenir, même s'il est assez complexe. Mais si votre personnel n'est pas correctement formé et organisé pour gérer le code, vous passerez probablement beaucoup de temps à corriger les mauvaises versions ou les mauvais commits et autres ...

Cependant, lorsque vous avez un environnement de développement, Q & A, RC et Production ... Tout cela pèse lourd sur le processus de passage du développement à la production réelle.

Je dirais que les pourcentages sont corrects, se penchant plus près de la barre des 30% que de 5%. Si tout ce que vous investissez est de 5%, vous faites du bon travail. (Cela inclut les erreurs trouvées lors des Q&R ou des RC ou même de la production en raison d'une mauvaise gestion du système de construction, ce qui peut entraîner des retards énormes)


Si tout ce que vous investissez est de 5%, je dirais que vous ne mesurez pas tout ou avec précision.
mattnz

pas mat. Vous utilisez une définition différente. La plupart des entreprises pour lesquelles j'ai travaillé n'ont AUCUN système de build en place, comme dans aucun serveur de build automatisé, intégration VCS (souvent pas de VCS du tout, sauf les projets eux-mêmes qui peuvent être mis en place par eux-mêmes, qui finissent sous le radar), etc. Dans toute "étude" du pourcentage de ressources utilisées pour maintenir le "système de construction", ils finiraient par figurer comme dépensant presque rien, à moins qu'il ne soit ventilé pour inclure l'effort consacré à la maintenance de tous les scripts ANT et Maven, quelque chose rarement fait.
2011
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.